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
Context: FIPS 203 introduces additional key validation during the encapsulation and decapsulation process. In the ML-KEM implementation from mlkem-native, this results in overhead of ~5% in encapsulation and ~30% in decapsulation.
Currently, with the 3-way liboqs KEM API (OQS_KEM_keypair, OQS_KEM_encaps, OQS_KEM_decaps) key validation checks need to be performed during each encapsulation and decapsulation operation, adding overhead for every operation.
An extended API that separates key import from encapsulation and decapsulation would allow the validation checks to occur only once during key import. This would eliminate the repeated overhead when performing multiple encapsulation or decapsulation operations on the same key.
This issue aims to track the investigation and potential development of such an extended API.
The text was updated successfully, but these errors were encountered:
Context: FIPS 203 introduces additional key validation during the encapsulation and decapsulation process. In the ML-KEM implementation from mlkem-native, this results in overhead of ~5% in encapsulation and ~30% in decapsulation.
Currently, with the 3-way liboqs KEM API (OQS_KEM_keypair, OQS_KEM_encaps, OQS_KEM_decaps) key validation checks need to be performed during each encapsulation and decapsulation operation, adding overhead for every operation.
An extended API that separates key import from encapsulation and decapsulation would allow the validation checks to occur only once during key import. This would eliminate the repeated overhead when performing multiple encapsulation or decapsulation operations on the same key.
This issue aims to track the investigation and potential development of such an extended API.
The text was updated successfully, but these errors were encountered: