Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support keygen/decap with 64-byte seeds #91

Open
bifurcation opened this issue Nov 20, 2024 · 0 comments
Open

Support keygen/decap with 64-byte seeds #91

bifurcation opened this issue Nov 20, 2024 · 0 comments

Comments

@bifurcation
Copy link

bifurcation commented Nov 20, 2024

There is an increasing trend toward using the 64-byte "seed" form of ML-KEM decapsulation keys. See, for example, 1 2.

The Kyber implementation in this repo technically supports this use case, since you can call _keypair_derand() to generate a public key from a seed, and do the same thing to expand the secret key before calling _dec(). However, the different pattern of calls makes it difficult for libraries like libOQS to consume this capability.

If there was a desire to do this while also supporting expanded secret keys, we could add a couple of additional functions that would provide a parallel API using seeds, something like:

 int pqcrystals_kyber512_ref_keypair_derand(uint8_t *pk, uint8_t *sk, const uint8_t *coins);
 int pqcrystals_kyber512_ref_keypair(uint8_t *pk, uint8_t *sk);
+int pqcrystals_kyber512_ref_keypair_seed(uint8_t *pk, uint8_t *sk);
 int pqcrystals_kyber512_ref_enc_derand(uint8_t *ct, uint8_t *ss, const uint8_t *pk, const uint8_t *coins);
 int pqcrystals_kyber512_ref_enc(uint8_t *ct, uint8_t *ss, const uint8_t *pk);
 int pqcrystals_kyber512_ref_dec(uint8_t *ss, const uint8_t *ct, const uint8_t *sk);
+int pqcrystals_kyber512_ref_dec_seed(uint8_t *ss, const uint8_t *ct, const uint8_t *sk);

Where the _seed variants would expect the sk parameter to have size KEYPAIRCOINBYTES instead of SECRETKEYBYTES. And likewise for the other parameter sets / AVX. The implementation of the methods would be small, just a couple of extra lines to expand the key when necessary. I sort of already wrote it in a PR on libOQS, but given that libOQS tries to be a thin wrapper, it would be better to have it here.

If this approach looks acceptable to the maintainers, I would be happy to send a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant