Separate functions to compute only one key from the seed

[gilles-peskine-arm]

In environments where memory is tight, sometimes, we would like to compute the expanded private key from the ML-DSA seed (expand-private), or to compute the public key from the ML-DSA seed (export-public), without spending memory on the key that we don't need.

mld_sign_keypair_internal() computes both pk and sk from the seed. It would be nice to have similar functions that compute only one of the keys. (Especially export-public — I'm not sure if it's possible to save memory or computation for expand-private, given the need for the public key hash.)

[hanno-becker]

Thank you @gilles-peskine-arm, and apologies for the slow reply.

It's great to get such feedback. We won't be able to take this into account for the upcoming v1, but are generally open to an API extension along the lines you envision.

Would you have time to draft a PR or spell out in more detail what would work for you?

[mkannwischer]

Thanks @gilles-peskine-arm! I also support this API extension, but won't have time to implement it prior to v1.

[gilles-peskine-arm]

I may be able to propose a draft with mldsa_native.h + implementation + some functional testing in August, subject to my own workload constraints. I'm unlikely to be able to adapt the proofs. I'm not sure what else would be needed.

[mkannwischer]

I may be able to propose a draft with mldsa_native.h + implementation + some functional testing in August, subject to my own workload constraints. I'm unlikely to be able to adapt the proofs. I'm not sure what else would be needed.

That would be great, thanks! I expect the proofs to be straightforward. We can help to complete those. Feel free to just open a PR without proofs.

[hanno-becker]

Would you prefer a separate API or simply allow the existing keyGen API to be called with pk/sk set to NULL if not required?

[gilles-peskine-arm]

Would you prefer a separate API or simply allow the existing keyGen API to be called with pk/sk set to NULL if not required?

On the one hand, nullable output pointers are a fairly common interface. On the other hand, they make static analysis harder. On the gripping hand, all cases will have the same stack consumption, and that's probably not a good thing. So I think they should be separate functions.

[hanno-becker]

all cases will have the same stack consumption, and that's probably not a good thing.

How much of a practical issue is this? Both encaps and decaps have a higher memory usage than keygen.

@mkannwischer What's your view?

I'll try out locally what it would look like to accept NULL pointers; to me it depends on how clean/messy the code would get.