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