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.
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:
Where the
_seedvariants would expect theskparameter to have sizeKEYPAIRCOINBYTESinstead ofSECRETKEYBYTES. 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.