Skip to content

Add ML-DSA private keys to table. #399

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
msporny wants to merge 4 commits into
base: master
Choose a base branch
from
+6 −0
Open

Add ML-DSA private keys to table. #399

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0452833
Add ML-DSA private keys to table.
msporny Apr 11, 2026
1ec792c
Clarify that mldsa entries are for the expanded key format.
msporny Apr 13, 2026
9528e51
Add entries for ML-DSA-* private key seed values
msporny Apr 14, 2026
d8957ce
Merge branch 'master' into patch-3
msporny Apr 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions table.csv
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -218,6 +218,9 @@ mlkem-512-priv, key, 0x1313, draft, ML-K
mlkem-768-priv, key, 0x1314, draft, ML-KEM 768 public key; as specified by FIPS 203
mlkem-1024-priv, key, 0x1315, draft, ML-KEM 1024 public key; as specified by FIPS 203
jwk_jcs-priv, key, 0x1316, draft, JSON object containing only the required members of a JWK (RFC 7518 and RFC 7517) representing the private key. Serialisation based on JCS (RFC 8785)
mldsa-44-priv, key, 0x1317, draft, ML-DSA 44 private key; as specified by FIPS 204
mldsa-65-priv, key, 0x1318, draft, ML-DSA 65 private key; as specified by FIPS 204
mldsa-87-priv, key, 0x1319, draft, ML-DSA 87 private key; as specified by FIPS 204
Copy link
Copy Markdown
Member

@lidel lidel Apr 13, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing worth noting: FIPS 204 and RFC 9881 define three distinct encodings for ML-DSA private keys:

32-byte seed (recommended, used by JOSE/COSE)
full expanded key
combined form with both

The -priv entries here don't specify which encoding they represent. Consistent with other private key codecs in this table, so not a blocker, but leaves room for implementation divergence.

@msporny did you have a specific encoding in mind? The W3C spec linked in this PR lists private key sizes of 2,560 / 4,032 / 4,896 bytes for ML-DSA-44/65/87, which matches the expanded key format, but doesn't say so explicitly. Worth making that explicit in your spec + why you use expanded and not the compact seed?

@vmx do you feel we should we should clarify here from the start?

If so, should we go with explanded or seed?

Suggested change
mldsa-44-priv, key, 0x1317, draft, ML-DSA 44 private key; as specified by FIPS 204
mldsa-65-priv, key, 0x1318, draft, ML-DSA 65 private key; as specified by FIPS 204
mldsa-87-priv, key, 0x1319, draft, ML-DSA 87 private key; as specified by FIPS 204
mldsa-44-priv, key, 0x1317, draft, ML-DSA 44 private key; expanded key format (2560 bytes) as specified by FIPS 204
mldsa-65-priv, key, 0x1318, draft, ML-DSA 65 private key; expanded key format (4032 bytes) as specified by FIPS 204
mldsa-87-priv, key, 0x1319, draft, ML-DSA 87 private key; expanded key format (4896 bytes) as specified by FIPS 204
Suggested change
mldsa-44-priv, key, 0x1317, draft, ML-DSA 44 private key; as specified by FIPS 204
mldsa-65-priv, key, 0x1318, draft, ML-DSA 65 private key; as specified by FIPS 204
mldsa-87-priv, key, 0x1319, draft, ML-DSA 87 private key; as specified by FIPS 204
mldsa-44-priv, key, 0x1317, draft, ML-DSA 44 private key; seed key format (32 bytes) as specified by FIPS 204
mldsa-65-priv, key, 0x1318, draft, ML-DSA 65 private key; seed key format (32 bytes) as specified by FIPS 204
mldsa-87-priv, key, 0x1319, draft, ML-DSA 87 private key; seed key format (32 bytes) as specified by FIPS 204

Copy link
Copy Markdown
Contributor Author

@msporny msporny Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agree with the changes. Thank you for the catch!

Copy link
Copy Markdown
Contributor

@Wind4Greg Wind4Greg Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @vmx, that makes sense to me if the purpose of this if for holding private keys, in, say, an HSM, for use in signing. Otherwise we could just have a single code point for the 32 byte seed.

Copy link
Copy Markdown
Contributor Author

@msporny msporny Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the seed 32 bytes for all security levels? I'm wondering if we need to provide a hint to the software wrt. what the expected security strength level should be in the generated key. For example, secretKeyMultibase doesn't tell you the security strength level of they expanded key, and it might be a good idea to do that since the information doesn't exist anywhere else. IOW, we might need three more entries:

mldsa-44-seed
mldsa-65-seed
mldsa-87-seed

Copy link
Copy Markdown
Contributor

@dlongley dlongley Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that the seed size is the same for all variants here. I think we should go with the "seed key format (32 bytes)" second suggested change above from @lidel.

I think it's clear that having the seed version of these is useful so we should certainly define that. I don't know that expanded format will be useful in the future, but it may be. Minimally, the seed version should be defined (for all 3, so 3 different entries in the table) -- and if we think the expanded version is necessary that would be 3 more (total of 6).

So, +1 for defining mldsa-44|65|87-priv as the seed version. IIRC, the ed25519 and x25519 private keys are also defined as their 32-byte seed variants here (and then those are expanded internally for use -- yes, it's a much simpler expansion, but the concept is similar).

Copy link
Copy Markdown
Member

@lidel lidel Apr 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be (also?) useful option to avoid the chore of registering every combination for every key and instead delegate as much is possible to existing RFCs.

For example, with codes proposed in:

we could represent both seed or expanded formats, or even both. https://www.rfc-editor.org/rfc/rfc9881#section-6 defines the ASN.1 encoding of ML-DSA private keys inside PKCS#8. For ML-DSA-44 its:

ML-DSA-44-PrivateKey ::= CHOICE {
  seed         [0] OCTET STRING (SIZE (32)),
  expandedKey      OCTET STRING (SIZE (2560)),
  both             SEQUENCE {
    seed         OCTET STRING (SIZE (32)),
    expandedKey  OCTET STRING (SIZE (2560))
  }
}

Fine to have both ways, but in practice, I find self-describing containers pretty interoperable (easy to find a library that knows how to read/write PKCS#8 etc)

Copy link
Copy Markdown
Contributor

@dlongley dlongley Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation burden is much higher if ASN.1/DER (PKCS#8) is added as a requirement.

Copy link
Copy Markdown
Contributor Author

@msporny msporny Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agreed, -1 to re-using the optionality in RFC 9881. We're trying to keep the header values simple so there is no confusion (or extra parsing) needed past the Multikey header. It's either seed bytes or an expandedKey. The "both" option in ASN.1 is not something we want to introduce because you then run the possibility of someone reading in a "both" as an expanded key (which would be an implementation bug, but one that we'd like to avoid).

Copy link
Copy Markdown
Contributor Author

@msporny msporny Apr 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the PR to include the seeds (and their expected expanded form) as well:

https://github.com/multiformats/multicodec/pull/399/changes#diff-bf5b449ed8c1850371f42808a186b5c5089edd0025700505a6b8f426cd54a6e4R224-R226

lamport-sha3-512-pub, key, 0x1a14, draft, Lamport public key based on SHA3-512
lamport-sha3-384-pub, key, 0x1a15, draft, Lamport public key based on SHA3-384
lamport-sha3-256-pub, key, 0x1a16, draft, Lamport public key based on SHA3-256
Expand Down
Loading