Post-quantum cryptography algorithms?

[vt-alt]

Do you plan to add support for quantum-resistant algorithms?

For example, OpenSSH 8.0 already have hybrid (X25519 with) post-quantum KEX algorithm Streamlined NTRU Prime sntrup4591761 since 2019, which is updated to sntrup761 in 2021.

While there is still NIST PQC competition going on, you seems to already tend to DJB's algorithms where NTRU Prime would perfectly fit.

ps. For the reference DJB-connected NIST PQC submissions in liboqs:

• https://openquantumsafe.org/liboqs/algorithms/kem/ntruprime KEM
• https://openquantumsafe.org/liboqs/algorithms/sig/sphincs Signature scheme

[fscoto]

I'd consider post-quantum cryptography to be out of scope for Monocypher, which provides only one algorithm for any category where possible (signatures and IETF ChaCha20 being the exceptions where it wasn't possible).

Additionally, an algorithm being a djb algorithm doesn't make it per se worth implementing. It just so happens to coincide that djb algorithms generally were the ones worth implementing due to good performance characteristics when implemented in software and easy correctness goals. For post-quantum cryptography, the NIST competition is still raging on with NIST making massive disclaimers such as “If new results emerge during the third round which undermine NIST’s confidence in some of the finalists, NIST may extend the timeline, or make changes to the process”. From where I stand, even the idea of choosing post-quantum algorithms for Monocypher is already questionable: Monocypher is designed and intended to be deploy-and-forget unless you have a reason to upgrade (e.g. need some of the performance improvements that get added later down the line). As far as I can tell, the cryptographic community still trying to get a handle on post-quantum algorithms and how to attack them.

This is not to say that quantum computers are not a threat. Personally, I am convinced that quantum computers with sufficient amounts of qubits are not a matter of “if” but rather “when”. However, the time to choose for Monocypher (or any follow-up project) is probably not before NIST has chosen candidates and they have been established a few years in the field and people have figured out how to live with them. Perhaps even a few years later when failings (like timing attacks for AES) become known and perhaps alternative algorithms gain more traction.

[LoupVaillant]

Well, for the reason @fscoto stated, quantum-resistant algorithms are indeed out of scope. Not only do I want to stick to stable, conservative choices, I don’t want to provide several ways of doing the same thing unless there’s a specific reason to. (For instance, the original reason Monocypher supports EdDSA with SHA-512 in addition to Blake2b, was to facilitate the tests.)

Won’t fix, sorry.

[vt-alt]

Thanks for the answer.

ps. I understand you choice and that it's final. Not to argue and convince you back, just want to add my opinion. Personally, I think modern cryptographic library already should provide some PQC support. (Which is even more important if you believe the threat is real.)

About problem of choice which would confuse users and weaken encryption — PQC is (and should be) implemented as hybrid cryptography, thus there is no choice between PQC vs. conservative algo — just always use PQC together with conservative algo, and if PQC algo is weakened there is still conservative one.

pps. JFYI: Interesting to read if you did not already:

• https://ntruprime.cr.yp.to/latticerisks-20211031.pdf
• https://cr.yp.to/papers/competitions-20211226.pdf

[LoupVaillant]

Thanks for the papers, I’ll take a look.

Though I do think of Monocypher as "modern", the documentation does not describe it that way. On the README, the only occurrence of "modern" describes processors, and on the home page it’s on the testimonial. My goal is not to make something modern, it’s to make something simple, stable, that works.

Also, some aspects of Monocypher are decidedly not modern at all: it’s written in a fairly old, extremely conservative subset of C, and lately it veers closer and closer to indefinite feature freeze, a.k.a "done". In addition, one major selling point of Monocypher is that it’s small and simple. Each feature we add will make it less small and simple, so its benefits will have to be weighted against that cost. See for instance #226, for which we have a genuine use case, and #218, which I’d like to add myself: for less conservative projects those would be no-brainers, but we’re hesitating on both.

[vt-alt]

JFYI https://www.ssi.gouv.fr/publication/anssi-views-on-the-post-quantum-cryptography-transition/ Interesting usage of word "today".

[samuel-lucas6]

Now that PQC has progressed, have you thought about making a separate, dedicated PQC library Loup? I'm just curious. I know it would take a lot of work and additional maintenance, although it could be kept to only certain standardised algorithms, for example.

[LoupVaillant]

PQC looks like it is starting to take shape, but from the look of it it's not settled yet. (I think most notably of DJB's dispute, though I haven't examined it properly — I probably couldn't.) To be honest I'd rather be a late adopter here, and wait for a clear de facto winner to emerge.

Once it does, I'll have to rethink a number of other things too. Apparently PQC doesn't do key exchange very well, so we'll have to use Key Encapsulation Mechanisms instead. This means we can't just port those algorithms to the Noise protocol framework, which is unfortunate.

[samuel-lucas6]

PQC looks like it is starting to take shape, but from the look of it it's not settled yet. (I think most notably of DJB's dispute, though I haven't examined it properly — I probably couldn't.) To be honest I'd rather be a late adopter here, and wait for a clear de facto winner to emerge.

That's fair. Looking forward to see what you produce.

Once it does, I'll have to rethink a number of other things too. Apparently PQC doesn't do key exchange very well, so we'll have to use Key Encapsulation Mechanisms instead. This means we can't just port those algorithms to the Noise protocol framework, which is unfortunate.

Yeah, the lack of NIKE is quite bad, although there is Swoosh and some isogeny-based algorithms. Hopefully it won't be forgotten in favour of just KEMs.

I'm sure there will be an official post-quantum Noise. There's already a paper on the idea. The PSK with current Noise can also be used like in Rosenpass and Mullvad in the meantime.

[vt-alt]

I'm sure there will be an official post-quantum Noise.

A slightly too old Feb 10, 2022 message: https://twitter.com/trevp__/status/1491532955826589698