ml-dsa: revisit key encoding

[baloo]

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.

#891
#892

[baloo]

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/

[tarcieri]

See also: RustCrypto/KEMs#53

[baloo]

lamps-wg/dilithium-certificates#87

[tarcieri]

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).

[baloo]

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).

[tarcieri]

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

[baloo]

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.

[tarcieri]

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.

[tarcieri]

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

[baloo]

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.