Add both variants of frodokem

[ode]

This PR updates the frodokem implementation to align with the current upstream; more specifically

• The existing (unsalted) FrodoKEM is renamed/refactored into "ephemeral" eFrodoKEM
• The salted version is added in as FrodoKEM

Resolves #2192

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)

Frodokem's ciphertext length (i.e. encaps output) changes due to the added salt

• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged. Also, make sure to update the list of algorithms in the continuous benchmarking files: .github/workflows/kem-bench.yml and sig-bench.yml)

6 additional variants in the frodokem family are added. CI and oqs-provider changes will follow

[RodriM11]

Hi @ode ! First, thank you very much for the PR. It was in my mental backlog of things to do but I simply have not had the time to get on with it as I wished.

A couple comments: first, documentation and test should also be updated, but I imagine since the PR is in Draft mode, that would get updated later. The other one is to continue @baentsch's discussion here regarding including the code via upstream from the original repository, such that future updates are somehow simpler. Would it be possible for you to undertake such modification?

[ode]

Hi! I've been meaning to do this for a while too, this was a good opportunity to get my feet wet without getting too deep into the actual crypto.

A couple comments: first, documentation and test should also be updated, but I imagine since the PR is in Draft mode, that would get updated later.

That's right; I'll be committing the documentation changes sometime this week. To my pleasant surprise, I found that test_kem already does test the correctness of the newly added variants without any modifications. Some doctests still fail, but they do detect the new variants. I suspect that once I update the docs I might not have to make any test updates at all

The other one is to continue @baentsch's discussion here regarding including the code via upstream from the original repository, such that future updates are somehow simpler. Would it be possible for you to undertake such modification?

My understanding of copy_from_upstream is that it depends on the upstream repositories themselves maintaining a metadata file - and since this is not the case for FrodoKEM, we would either have to get the files into the upstream through PR or fork the upstream.

In any case, there have not been any updates to the actual implementation in the upstream for three years now.

[ode]

Updated docs, KATs, benchmark workflow, CBOM, etc;
Marking the PR as ready for review to invite more discussion

[RodriM11]

Tests notwithstanding (I do not know why they have not been triggered), the PR LGTM! Thanks for the contribution @ode. Some comments:

My understanding of copy_from_upstream is that it depends on the upstream repositories themselves maintaining a metadata file - and since this is not the case for FrodoKEM, we would either have to get the files into the upstream through PR or fork the upstream.

1. I think it would not be a problem to create the structure in the original upstream repo to support upstream consumption. Tagging @dstebila as one of the code owners for comments.
2. This PR, as noted above, maintains the name "FrodoKEM" but now refers to a different algorithm (salted variant). This is an important change that should be appropriately documented in the release notes of the version in which the PR is included (which is targeted for 0.16.0 as of now)
3. This modification will naturally have to also be translated to oqsprovider and the behavior change also be documented, but that is a oqs-provider issue. @baentsch once this PR is ready to merge, I will create the corresponding issue in oqs-provider.

[dstebila]

Tests notwithstanding (I do not know why they have not been triggered)

For PRs from external contributors, a committer has to approve the workflow to run. I'll do so momentarily.

1. I think it would not be a problem to create the structure in the original upstream repo to support upstream consumption. Tagging @dstebila as one of the code owners for comments.

The upstream repository is maintained by Patrick Longa at Microsoft Research, so it would be up to him if he's amenable to having that supporting material in their repository. But it's worth a try.

2. This PR, as noted above, maintains the name "FrodoKEM" but now refers to a different algorithm (salted variant). This is an important change that should be appropriately documented in the release notes of the version in which the PR is included (which is targeted for 0.16.0 as of now)

Good point.

[dstebila]

Looks good to me, other than the small change to the spec version.

[ode]

Had to do a rebase for a clean merge on CBOM

@dstebila - I've addressed the review comment. The failing test earlier was due to incorrect alphabetical ordering on KATs. Hopefully everything works on a re-run

[coveralls]

coverage: 83.029% (+0.01%) from 83.015%
when pulling fe740f2 on ode:main
into f1e80d1 on open-quantum-safe:main.

[dstebila]

Thanks very much, @ode!

The only thing left is to resolve the conflict on the CBOM file. @bhess I screwed that up the last time I tried, would you be able to help with that?

[dstebila]

@bhess Would you be able to help with resolving the CBOM conflicts?

[bhess]

The integration looks good to me!

I resolved the CBOM conflict, which appears to have automatically dismissed some approvals. @dstebila @ashman-p can you please approve again?