ml-kem: Adds feature flag to use key or seed

[supinie]

Resolves#53

I saw that @bifurcation mentioned that the test vectors should work, but they appeared to be in the wrong format. For now I have disabled them in the same way that deterministic does.

I have tried to write it in such a way that the user always deals with a DecapsulationKey type no matter whether this is a true key or seed to maximise backwards compatibility.

[tarcieri]

Really seeds should be the "default" API, not something that's enabled by a feature.

I think it's OK to make breaking changes towards that end.

[supinie]

Really seeds should be the "default" API, not something that's enabled by a feature.

I think it's OK to make breaking changes towards that end.

I can easily swap this around - will put together a new commit now.

[supinie]

I just thought, since we now have two feature flags, is it also worth adding a short section on the docs homepage about them?

[tarcieri]

@supinie I would prefer a PR like this be purely additive, as opposed to changing things depending on if the feature is enabled by using cfg(not(...)) gates

[supinie]

@tarcieri in that case, would we rather that the DecapsulationKey object is the seed, and we then generate the "inner" key before use, or keep the DecapsulationKey as is, but with the addition of an extra B32 field to contain d?

[tarcieri]

That's a good question.

In ed25519-dalek, where Ed25519 uses a similar sort of seed-based expansion, the DecapsulationKey-alike type is based entirely on the seed (where the SecretKey type is an alias for the [u8; 32] seed), and there's a separate type for the expanded secret key which we conditionally export under the hazmat module when the hazmat feature is enabled.

As things are currently implemented, the seed is always expanded prior to use, and the expanded form is not cached but instead always computed on demand.

I think something similar could work here?

[supinie]

I've refactored it to fit this style, but am unable to get the KATs working (encap-decap.rs). Currently, the input is the bytes format of the inner key, which makes it trivial to recover the inner key, but going from the inner key to the seed is not possible. The d seed does not exist in the KAT input.

I have pushed these changes to https://github.com/supinie/KEMs/tree/additive so you can take a look if you'd like.

[supinie]

I've been thinking a little more about this problem recently, perhaps we could use an enum to hold either the key as a seed or the key as an inner.

The enum would ensure that only one can be set at a time, with a preference towards using the seed, but in some cases would allow us to carry around the old inner key instead?

[dignifiedquire]

The enum would ensure that only one can be set at a time, with a preference towards using the seed, but in some cases would allow us to carry around the old inner key instead?

I personally would like to be able to use both, especially without having feature flag usage.

[supinie]

The enum would ensure that only one can be set at a time, with a preference towards using the seed, but in some cases would allow us to carry around the old inner key instead?

I personally would like to be able to use both, especially without having feature flag usage.

When I'm saying "use both", I'm talking internally, an external user would just see a key object. We wouldn't want or need to store both internally as they just do the same thing.

Please correct me if I've misunderstood, but @tarcieri would also like it to be this way; the flag simply allows you to gain access to the old API

[tarcieri]

Closing in favor of #133