[CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts

[John Mattsson <[e-mail]>]

Hi,

IETF has never limited itself to NIST-approved algorithms. A lot of IETF protocols specify use of MD5, ChaCha20, X25519, X448, Ed25519, Ed448, Camelia, Brainpool, GOST, SM, Seed, Aria. CFRG/IETF furthermore specifies OCB3, Argon, AES-SIV, AES-GCM-SIV etc. I expect the same to hold for post-quantum cryptography.

Hopefully NIST will standardize Classic McEliece. In that case I do not see any need for a CFRG specification. Two specifications are worse that one. While NIST reviews its specifications every 5 years, invite comments, publish the comments, and updates specification based on comments. RFC like RFC 3610 and RFC 4493 will likely never be updated.

Using non-standardized crypto from a single person does not seem like a good idea... And not trusting ML-KEM, ML-DSA, and SLH-DSA because they won the NIST competition does not seem rational. They were designed and analyzed by a huge number of cryptographers from all over the world. I think the ChaCha20, X25519, Ed25519, and Classic McEliece should be used because they have superior technical properties for some use cases, not because DJB designed them.

The lessons from several recent events should be that SIGINTs globally try to weaken security in implementations. That can be done through standards in any SDO, by paying persons or organizations, or by affecting implementations. ISO cryptographic specifications is much worse that NIST’s with a huge number of insecure options.

I don’t think the deployments should be the deciding factor. I think IETF/CFRG should use and specify algorithms based on technical merits. Existing deployments are often, but far from always, a sign that the algorithms have technical benefits in some applications. I am very much against the idea that IETF should have it as a goal to use non-NIST algorithms.

Cheers,
John

From: Harry Halpin <[e-mail]>
Date: Monday, 27 January 2025 at 13:32
To: [e-mail] <[e-mail]>
Subject: [CFRG] Re: Progressing NTRUPrime/Classic McEliece drafts
We are also working to deploy Classic McEliece in our VPN software: https://nym.com<https://nym.com/>.

The SimpleX chat protocol is using Classic McEliece:
https://simplex.chat<https://simplex.chat/>

At least my company, Nym, would be disappointed if IETF protocols and  algorithms were limited to NIST-approved post-quantum cryptography.

As an advisor of the Progressive International (https://progressive.international<https://progressive.international/>) various governments outside of the USA and Western Europe that we work with (mostly in Latin America, and I happen am in Middle East rn) would also be disappointed. Although everyone in the US (and many in Europe) have forgotten the Snowden revelations, including the problematic relationship between NIST and NSA, various governments and organizations in the Global South do tend to trust DJB-approved crypto more than NIST-approved crypto.

Of course, we want to avoid too many algorithmic options, but that is not the case with Classic McEliece. In general, support of NIST should not preclude other deployed non-NIST approved algorithms if there is reasonable evidence of deployment, although reasonable people may disagree on what is reasonable.

  Yours,
     Harry

On Mon 27 Jan 2025 at 2:40 PM, D. J. Bernstein <[e-mail]<mailto:[e-mail]>> wrote:
More data points regarding Classic McEliece deployment: https://mceliece.org<https://mceliece.org/>

Rationale for deployment: https://classic.mceliece.org/talks/20240917.pdf

---D. J. Bernstein

_______________________________________________
CFRG mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>