open-quantum-safe
Adding a DeriveEncapsulation functionality
Version 0.13.0 includes a DeriveKeyPair functionality. I was wondering whether the same functionality could be included for Encapsulation procedures. Every considerations explained in #1206 regarding the interest of this functionality apply here as well and IMO would also be interesting to have (and use it). Furthermore, I saw that as part of the merge to include the DeriveKeyPair functionality, @SWilson4 included similar modifications for Encapsulation, but was later deleted. So, hopefully, this inclusion would not be a lot of trouble. I could take a swing at including it if desired/necessary.
Hi @RodriM11, thanks for the feature request! Could you expand a little on your use case for derandomized encapsulation?
The main motivations for adding derandomized key generation for ML-KEM to the liboqs API were twofold:
- The DeriveKeyPair functionality is required by the Internet standard for HPKE and used in the MLS protocol, and derandomized keygen is the obvious way to do this for ML-KEM.
- ML-KEM keys are often being stored and passed around as "seeds," and derandomized keygen is the way to expand a seed into the full key.
I'm not aware yet of the same need to expose derandomized encapsulation as an API call. It would indeed be straightforward to add to the API (for ML-KEM, at least), but I think it would be good to have a practical use case before we make further API changes.
Hi @SWilson4 , thanks for the quick response. IMO, for example similar uses would be desirable under the inclusion of this feature:
- deterministic testing of Encaps procedures without toggling the DRBG (concurrence, shared use between different functionalities)
- For non-ephemeral encapsulation procedures or functionalities in which encapsulation procedures might need to be stored, the possibility to store just the seeds to generate such procedure, instead of the (expensive) storage of the encapsulation value (at the cost of having to deterministically generate it from the seeds once it is needed). I think the possibility of this situation alone (which is not at all an uncommon situation, I would like to use the feature if available) should warrant the ability to do so. (One could argue that I could also do that will the DRBG API, but as before, I might not always want to use deterministic generation or might have to concurrent uses of the same library with different requirements, etc...)
Hi @SWilson4 , thanks for the quick response. IMO, for example similar uses would be desirable under the inclusion of this feature:
* deterministic testing of Encaps procedures without toggling the DRBG (concurrence, shared use between different functionalities)
For the time being, we would only be able to support this feature for ML-KEM, which does have this sort of testing done with NIST ACVP vectors. Do you feel that additional testing is needed beyond the ACVP vectors? It would certainly be useful for non-standardized algorithms which don't have exhaustive official test vectors, but there's no standard derandomized encapsulation API for those.
* For non-ephemeral encapsulation procedures or functionalities in which encapsulation procedures might need to be stored, the possibility to store just the seeds to generate such procedure, instead of the (expensive) storage of the encapsulation value (at the cost of having to deterministically generate it from the seeds once it is needed). I think the possibility of this situation alone (which is not at all an uncommon situation, I would like to use the feature if available) should warrant the ability to do so. (One could argue that I could also do that will the DRBG API, but as before, I might not always want to use deterministic generation or might have to concurrent uses of the same library with different requirements, etc...)
I agree that using the DRBG API is not a good solution. If OQS users (including yourself!) are interested in experimenting with applications and protocols that require or would benefit from derandomized encapsulation, I would be happy to support that.
Section 3.3 of FIPS 203 does explicitly forbid exposing internal interfaces for ML-KEM except for testing purposes (though this guidance has since been softened for keygen), so we may have to be careful about how we add such an API. I'll talk to Douglas about this next week when he's back in the office and let you know about our plans at that point.
Do you feel that additional testing is needed beyond the ACVP vectors?
I feel that the ACVP vector testing is enough, although if such interface would be present, I would argue it be best to use it instead of toggling with the DRBG (as before).
It would certainly be useful for non-standardized algorithms which don't have exhaustive official test vectors, but there's no standard derandomized encapsulation API for those.
I agree that it would indeed be useful to propagate that separation to non-FIPS algorithms, in a similar fashion as how it was done for FIPS 203-205, but I understand that, without a standard, it certainly would be "muddy waters".
If OQS users (including yourself!) are interested in experimenting with applications and protocols that require or would benefit from derandomized encapsulation, I would be happy to support that.
Thank you very much for your help! Although IMO the changes needed to support this functionality are somehow straightforward (albeit the number of files to be changed), I could take a swing at adding it/helping if desired.
Thank you very much for your help! Although IMO the changes needed to support this functionality are somehow straightforward (albeit the number of files to be changed), I could take a swing at adding it/helping if desired.
That would be great. Tag me for review when you have a PR, and we'll get it merged. Here is a commit from my branch for #2070 that had the interface largely implemented, in case it helps you get started.