private key in seed format for ML-KEM, ML-DSA, and SLH-DSA ?

[falko-strenzke]

Are there any plans to add the seed format for serialization of ML-KEM, ML-DSA, and SLH-DSA private keys? The discussion on the LAMPS list regarding the decision is ongoing and doesn't seem to be decided yet.

[reneme]

There's some discussion in the ML-KEM PR: #3893 (comment)

Generally, I'm fine with adding the seed expansion to the public API as well as not exposing the reading of expanded keys, if there's a quorum in the community.

Obviously, @randombit get's to have the final say on that.

[mouse07410]

My vote:

1. Support using seed as a way to provide private key (maybe as the main way);
2. Still keep visible acres to expanded key.

[randombit]

No strong opinion here. Using the seed as the canonical secret key encoding does seem better overall. Main thing I’d like to avoid, if possible, is us ending up having to support several different key formats which are mutually unintelligable with other implementations. [This is probably inenvitable…]

[reneme]

For the record: I changed the ML-KEM pull request to use the seeds exclusively.

[reneme]

For the record: I changed the ML-DSA pull request to use the seed exclusively.

[reneme]

With #3893 and #4270 merged we're now supporting the seed-based encoding for the private keys exclusively. I wouldn't rule out that we introduce support for the expanded format in case the need arises. But for the time being the expanded format is explicitly not supported for ML-KEM and ML-DSA.