Classic Mceliece status

[loganaden]

Description

Hi All,

I noticed that classic mceliece is no longer supported. The rosenpass project uses classic mceliece (pre-ISO).

Can I volunteer for classic mceliece ?

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Are you willing to help develop the solution?

No response

Use of generative AI

No response

[baentsch]

Thanks for volunteering @loganaden ! This then looks like an extension of #2485 , right? @RodriM11 @dstebila @xuganyu96 please chime in there (or let's discuss in the TSC how to resolve for good): As already noted, the PR backlog in liboqs seems to be growing way too long for a well-maintained project; also, please consider that long review cycles can be off-putting to contributors.

[xuganyu96]

Hi @loganaden, thank you for volunteering. An update to Classic McEliece is indeed sorely needed here. I believe libmceliece is published by the original author(s) and would be a great place to start. Feel free to tag me on this issue if you have questions.

edit: Rosenpass actually depends on liboqs for Kyber and Classic McEliece. This adds to the urgency of updating Classic McEliece in the next release.

[RodriM11]

I think a discussion of this is warranted: Classic McEliece was standardized by ISO a couple weeks ago, so I assume we would want to support the latest version, so we should check if changes have been made (I believe so) and if so to update the implementation to the latest (which seems libmceliece already has.

[baentsch]

As first part of such discussion, the question goes to Rosenpass which version of McEliece that project relies on: I have the hunch that it is the same story as with Kyber: The old code base without the possibility or intent to switch away from that, right @loganaden ?

As for the new ("standardized") version of McEliece: I personally am of the same opinion there as I consistently state for any other standardized PQ algorithm (ML-KEM, ML-DSA, etc): I think that they do not belong into OQS and should not take up any development or review cycles in the project: OQS IMO was meant to focus on (allowing evaluation of the value of) new algs, not standardized algs. The case is very clear-cut indeed if the original code source is (also) not interested in integrating this into OQS as seems to be the case with McEliece, right @dstebila ? Moreover, keeping McEliece is a pretty direct contradiction to https://github.com/open-quantum-safe/tsc/blob/main/guidelines/ci_usage.md as it is a resource-heavy algorithm causing many CI cycles (I may contribute a quantification of this in a separate issue/PR).

[dstebila]

I disagree about standardized algorithms: I think they do have a place in OQS. We went through a discussion several months ago about criteria for algorithm inclusion, the results of which were adopted in this TSC guidelines file, and my opinion remains aligned with that.

Standardization does not mean the end of experimentation. Among the many standardized and candidate algorithms, adopters still have to evaluate which one is right for their scenarios, and I think the OQS suite can support them in that.

For McEliece specifically, I would be in favour of incorporating the ISO-standardized version and sunsetting the previous version. For Kyber -> ML-KEM, the sunset process is very long. For Dilithium -> ML-DSA, if memory serves we did it with one version overlap. For other round n -> round n+1 updates, we just did an immediate replacement. For McEliece, I'd be inclined to do the replacement either immediately or with one version overlap. I would prefer not to get into a pattern where we have multiple indefinite sunsets like Kyber -> ML-KEM, both for the maintenance cost and noting as well Classic McEliece's high CI cost.

[RodriM11]

Standardization does not mean the end of experimentation. Among the many standardized and candidate algorithms, adopters still have to evaluate which one is right for their scenarios, and I think the OQS suite can support them in that.

In this case, I agree with this argument, although it is true that once standardized, it may start to appear in non-research, open-source libraries.

For McEliece, I'd be inclined to do the replacement either immediately or with one version overlap

Since I believe that no name-change has happened, I would strongly argue for immediate sunset, otherwise it could open the door to certain problems / rework that I do not believe are worth the trouble for an algorithm version that was never selected.

In any case, I believe ISO's Classic McEliece is a discussion for the next TSC meeting, and should not take priority over other 0.17.0 efforts, most notably round-3 algorithm inclusion.

[baentsch]

I disagree about standardized algorithms: I think they do have a place in OQS. We went through a discussion several months ago about criteria for algorithm inclusion, the results of which were adopted in this TSC guidelines file, and my opinion remains aligned with that.

Well, my position (of removing algorithms available in standard FOSS libraries) is strictly speaking not in contradiction to this guidelines file either: Those algs are no longer considered for standardization, so could well be dropped.

Word-splitting aside: If OQS wants to seriously keep following standards, wouldn't it need to change its modus operandi substantially? Shouldn't there be folks tracking the standards, ensuring interop with them, liaising with other FOSS packages delivering the same (and typically much more) functionality and explaining why OQS duplicates their work instead of contributing to them (OpenSSL being the most obvious example as liboqs uses it for classic but not for PQ algs)? I don't see that happening -- for a good reason: OQS doesn't have enough people with enough time to do that.

The guidelines file you mention, @dstebila was intentionally kept vague (by yourself) such as to revise algorithm-inclusion decisions pretty easily. My core argument is that we should do this in the light of what sensibly can be done by the small team of people working on OQS. It cannot be the "Swiss army knife" of PQ libs, its support base is (way) too small. It should focus on things no-one else does and not try to duplicate work. If one wants to do everything, the probability is high that nothing gets done well.

Standardization does not mean the end of experimentation. Among the many standardized and candidate algorithms, adopters still have to evaluate which one is right for their scenarios, and I think the OQS suite can support them in that.

It can -- as can a multitude of other FOSS libs focusing on standardized algs. If one posits that OQS benefit is that it allows a "one-stop-PQ-shop" experience (a unified API for all algs), then all discussions on different APIs for different algorithms were moot. Are they? external-mu: Special API -- for how many algs? Testing ext-mu: Fails. SLH-DSA: The by far biggest culprit of why OQS CI is ultra slow. The same holds for bespoke libjade use in CI -- again, testing potentially benefiting just two standardized algs makes the whole community suffer through ultra-long CI cycles; Introduction of sig_derand api: Also apparently not by design, but by first example that happens to work, waiting for future PRs that may or may not come.

In any case, I believe ISO's Classic McEliece is a discussion for the next TSC meeting, and should not take priority over other 0.17.0 efforts, most notably round-3 algorithm inclusion.

Thanks @RodriM11 for bringing us back to where this all started! I'm all in favour of dropping McEliece (and then some; first from consideration and then the code base) to focus on round 3 algs.

[loganaden]

Would it be possible to provide a VM for classic Mceliece ?

[Mullana]

edit: since rosenpass was mentioned, here is where rosenpass sources Classic McEliece. Sike! Rosenpass actually relies on liboqs for Classic McEliece.

I'm not sure what you meant to say with that meme. Do you see Rosenpass as a bad guy that has to be unmasked?

[xuganyu96]

I'm not sure what you meant to say with that meme. Do you see Rosenpass as a bad guy that has to be unmasked?

I did not intend to negatively portray Rosenpass in my comment. My intent was to make fun of ourselves for not keeping implementations updated for downstream projects.

That being said, I agree that this meme could be interpreted as casting Rosenpass in a negative light. I apologize for the insensitive wording and have removed it from the original comment.

[loganaden]

Can the rosenpass project provide resources such as a VM to support Classic McEliece for CI ?