RustCrypto
ml-dsa: revisit key encoding
In the light of https://keymaterial.net/2025/02/19/how-not-to-format-a-private-key/ we might need to revisit the way we encode (or at least decode) the private keys.
https://github.com/RustCrypto/signatures/pull/891 https://github.com/RustCrypto/signatures/pull/892
For now, this implementation complies with the draft RFC: https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/, but that might change in the future?
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fxoRYGVmbRw/
That certainly is an obnoxious key format, I guess due to backwards compatibility with implementations who started using those encodings without first discussing how they should work.
Well, we should definitely support the seed-only format. The others seem like less of a priority (I really don't see the point of the "both" encoding if the expanded key can be deterministically derived from the seed).
I guess that would be to import a key exported by HSM or another very inflexible source.
I would go with deserialize from any of the format, and serialize to either seed or expanded (if we got expanded to begin with).
I don't think we should support serialization of the expanded format at all. IMO it was a mistake that it was ever included, which occurred because certain implementers of the draft shipped before it was finalized, and now they're asking for retroactive standardization
Even under an hazmat flag? The only use I can see is to interact with an HSM vendor who shipped a firmware using the extended encoding.
Traits like EncodePrivateKey aren't designed to support multiple serializations, and IMO it was a mistake to even include the expanded key whatsoever. Most implementations aren't supporting it at all.
Note that I’m slightly less opposed to being able to decode the other formats. I just don’t want to encourage their proliferation by serializing/encoding such schemes
I just had some kind of newtype in mind (around the privatekey) and for the newtype to serialize using the expanded version. But I guess it's easy enough for a downstream consumer to implement.