You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an increasing trend toward using the 64-byte "seed" form of ML-KEM decapsulation keys. See, for example, 12.
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 _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.
The text was updated successfully, but these errors were encountered:
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
_seed
variants would expect thesk
parameter to have sizeKEYPAIRCOINBYTES
instead 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.
The text was updated successfully, but these errors were encountered: