Inclusion of both variants FrodoKEM

[RodriM11]

Hi! Current implementation of FrodoKEM present on liboqs is based on the proposal for the first NIST PQC Standardization Process. After the selections made by NIST at the end of this round, the FrodoKEM team made important modifications to the submission: the NIST specification became the one named as "ephemeral" in which a salt is not included (and was renamed to eFrodoKEM). A new variant called FrodoKEM was constructed, which is suitable for applications in which many ciphertexts might be produced relative to a single public key, and includes further changes to address IND-CCA concerns.

Since FrodoKEM is recommended by a number of standardization bodies beyond NIST (is on track to become an ISO standard, appears as an internet draft, is recommended by agencies such as BSI), I believe it would be interesting to include both variants as part of liboqs capabilities

[praveksharma]

@dstebila I believe liboqs' FrodoKEM implementation resided in the liboqs repo and is not pulled from upstream. Do you know if there is a suitable upstream to pull the new FrodoKEM variant from?

[dstebila]

Yes, it would be good to have both variants of FrodoKEM in liboqs, and we'd be happy to have an update to do that.

FrodoKEM is not automatically copied via the copy-from-upstream process, instead it was manually added by adapting the implementation in https://github.com/microsoft/PQCrypto-LWEKE. If memory serves, there were not too many changes needed to do so.

[RodriM11]

Thanks for both responses. By taking a look at the reference repository, it seems that indeed would not be a huge development.

[baentsch]

Looking at this from a distance, can I ask whether it may be sufficient to just replace the current Frodo code with the new variant? Do any of you know of folks depending on the old (err, OQS-current) Frodo variant? If so, it seems prudent as a first step to re-name the current variant to eFrodoKEM, right? This would also make adding another one (named FrodoKEM) easier. And ideally, this would work via copy_from_upstream such as to get an automated code upstream link that Frodo currently utterly lacks, in my eyes making it a "second class citizen" (wrt quick security upgrades, etc.).

[RodriM11]

Yes, I think that would be a sensible approach. I imagine, since both FrodoKEM variants are close to being standardized (AFAIW), that there will be folks employing the current OQS implementation (which is now eFrodoKEM), and folks that will like to use the now called FrodoKEM variant (the one with salts), so I believe liboqs should provide support for both.

But the approach you suggest I think would make the integration of both of them easier.