Bernstein's Blog

Posted Dec 9, 2025 15:23 UTC (Tue) by geofft (subscriber, #59789)
In reply to: Bernstein's Blog by chris_se
Parent article: Disagreements over post-quantum encryption for TLS

I think I saw an argument on the mailing list that one large company wants to use TLS with a PQ-only algorithm internal to their data centers, and as I understand it this form of "standardization" would simply give it a constant identifier for use with TLS, so they could contribute such implementations to publicly-reviewed OSS libraries and expect interoperability between suitably configured libraries. From that perspective, it can be argued that it's hard to fathom why one would want to prohibit others from using this, as that is the only technical effect of refusing to advance this standard.

I do agree, broadly, that this is an unusual choice and people who do not have multiple qualified cryptographers available to advise them should generally not make this choice, and in particular it's not the right choice for anyone in a fiduciary position over someone else's communication security (e.g. web browsers, default configs of OSS libraries), only for people who can appropriately sign up for the consequences to their own communication security. So I think the decision to hold off on advancing the document until there's clear text to this effect is a wise one.

But at the same time, I think this argument is so obvious that anyone (you, me, etc.) could make it, and djb would better serve himself by understanding this, encouraging someone else to take up the cause of making the point, and disengaging personally. For that reason I am also sympathetic to what is being called the "pro-censorship" position - the IETF, unlike a government, has no power to restrict what djb or anyone else writes on a blog, posts on social media or in a comment section like this one, emails a colleague privately, publishes in a journal, etc. If a particular technical argument is sound, surely at least one other person can understand it and convey it, so unlike e.g. political debate, it doesn't seem to me there's a reason to act like every individual person has a fundamental right to participate. And it is easier for a technical point to be seen through to resolution if it is not drowned in what has clearly turned into interpersonal conflict.

The IETF also has no power to control what people think of it and the extent to which people trust it. News sites like this one will report on their decisions. Governments that have laws or regulations about IETF standards can change their laws or regulations. If the IETF decides to be so ruthless in "censorship" that this affects the technical quality of its work, people will see that and respond—just as people did see that Dual_EC_DRBG was bonkers despite coming from NIST and almost everyone responded appropriately.

to post comments

Bernstein's Blog

Posted Dec 9, 2025 18:52 UTC (Tue) by brunowolff (guest, #71160) [Link] (16 responses)

He isn't trying to prohibit stupid people from insisting on doing stupid things, he is trying to prevent people who don't know any better from doing stupid things. His argument is that people who see that a PQ only standard exists are going to think it is safe to use, because otherwise why would it be a standard.
It is way too early to be fully trusting PQ only algorithms. But because there are organizations recording all of the data now, hoping to be able to decrypt it later with PQ computers, it makes sense to use hybrids to try to do something about that, even though it might not work.

Bernstein's Blog

Posted Dec 10, 2025 0:01 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (15 responses)

> He isn't trying to prohibit stupid people from insisting on doing stupid things, he is trying to prevent people who don't know any better from doing stupid things. His argument is that people who see that a PQ only standard exists are going to think it is safe to use, because otherwise why would it be a standard.

This argument postulates that some people are clever enough to look for a standard and read it, but that the same people are way too stupid to understand what's written in the standard, and that those very same people will be misled. That argument sounds surprisingly like a religion which wants to prevent people from straying from the true path of enlightenment. It also reminds me of the "think of the children!" mind trick.

Bernstein's Blog

Posted Dec 10, 2025 0:49 UTC (Wed) by Wol (subscriber, #4433) [Link] (7 responses)

You're missing the fact that advertisers rarely have a clue about what they're advertising. They will quite happily advertise "Our crypto is stronger because we use a PQ algorithm", and the PHBs will insist on it because they believe the hype.

If the standard says that pure-PQ MUST be disabled by default, then the security regulators should have enough sense to wallop such PHBs with a clue-by-four.

Seriously. Don't underestimate the stupidity of your average PHB. What's that saying? "There's no-one harder to educate than someone who's livelihood depends on their not understanding ..."

(My biggest bug bear is those people who claim to be eco-friendly because normal farming activity (usually of crop trees) "mops up carbon dioxide". No it doesn't! It's just part of the normal carbon cycle and makes absolutely NO difference to global warming!)

Cheers,
Wol

Bernstein's Blog

Posted Dec 10, 2025 9:47 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

It's trivial for the algorithm to be named something like "experimental_insecure_pqc_algoname" (e.g. "experimental_insecure_NTRU_enc") in the standard, and to reserve a number for it. Then, if it's later determined to be secure, it can have the name "pqc_algoname" (e.g. "NTRU_encrypt"), with "experimental_insecure_pqc_algoname" as a deprecated alias for it.

If a PHB then says "our crypto is stronger because we use experimental_insecure_NTRU_enc", then they're likely to have regulators and other PHBs alike point out their error.

Bernstein's Blog

Posted Dec 10, 2025 16:07 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (5 responses)

Are you proposing labeling an algorithm as insecure on the basis that you don't feel comfortable with it? "Insecure" has a very specific meaning, and "not old/proven enough" is not it.
Algorithm IDs and names are descriptive of what the algorithm is, not assessments of its security.

Bernstein's Blog

Posted Dec 10, 2025 16:22 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

I'm asserting that it's possible for the standard to name an algorithm such that anyone using it without fully understanding the implications of that decision gets ridiculed by their peers and people they respect for doing so, even if none of them have an understanding of cryptography.

The precise name you choose to give it for now is a detail of that - but standing up and saying "we use experimental_possibly_insecure_enc_ntru1 cryptography for post-quantum security" will get you laughed at, in a way that "we use NTRUEncrypt for post-quantum security" will not. And that's enough to let the people who really understand what they're doing experiment with PQC in the open (thus getting us experience of practical gotchas as well as cryptographic faults), while stopping the clueless from using it because "obviously" pure PQC is better than hybrid PQC, right?

Bernstein's Blog

Posted Dec 10, 2025 23:19 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (3 responses)

But why do you want to label an algorithm that way? Why do you want people to (quoting you) "gets ridiculed by their peers"?
This obsession with labeling some algorithm as insecure or (alternatively) not having that algorithm in a standard is really extreme.

It's structurally similar to the fight against schools teaching undesirable topics.

However, if you think that labeling algorithms as "insecure" without proof of actual insecurity is okay, then anybody may request the same labeling for RSA and any elliptic curve algorithms. You know what? That's a great idea! Let's just label all the algorithms as insecure because there is at least one person per algorithm not trusting that algorithm. Sure, that defeats the purpose of labeling in the first place. However, the debate has long since shifted from debating actual merit to forcibly preventing the opponent from entering the playing field.

Bernstein's Blog

Posted Dec 11, 2025 0:12 UTC (Thu) by brunowolff (guest, #71160) [Link]

> This obsession with labeling some algorithm as insecure or (alternatively) not having that algorithm in a standard is really extreme.

You have a point about the silly name; but not including poor choices in standards isn't extreme, it is expected behavior.

Bernstein's Blog

Posted Dec 11, 2025 10:16 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

Because labelling it is a compromise position between "we should not include this algorithm because it might be insecure, and if we include it, people who don't understand cryptography " and "we should include this algorithm so that we can see how it works in the real world".

If everyone agreed on including it, then we wouldn't need to label it. But some people say it shouldn't be included because it's "not yet proven secure, so must be treated as insecure, but people who shouldn't use it will get attracted by the name".

If everyone agreed it should be excluded, then we wouldn't need to label it. But some people say it shouldn't be excluded because it's "not yet proven insecure, and is useful in our environment".

Labelling it is one way to compromise between the two; it addresses the attractive nuisance side, because the name makes it clear that it's not what you want and should be disabled, while still leaving it in the standard for people who want to use it despite the unknown risks.

Bernstein's Blog

Posted Jan 5, 2026 11:55 UTC (Mon) by sammythesnake (guest, #17693) [Link]

I feel like there ought to be a status dual to "deprecated" that the PQ-only option could be in, how about "probationary"? In 5 years or whatever, that status could be reviewed and either removed, or changed to deprecated (or left unchanged, if that makes more sense)

Bernstein's Blog

Posted Dec 10, 2025 1:26 UTC (Wed) by brunowolff (guest, #71160) [Link] (6 responses)

> This argument postulates that some people are clever enough to look for a standard and read it,

No it doesn't. It postulates someone knows that there is a PQ only standard and decides that they should use it. The person deciding this isn't necessarily even the person doing the implementation. They may be influnced by others to use it, similar to how RSA Security was bribed to include Dual EC and make it the default.

Bernstein's Blog

Posted Dec 10, 2025 15:37 UTC (Wed) by hailfinger (subscriber, #76962) [Link] (5 responses)

I fail to see why that would be a problem. We have the NULL cipher in so many standards and nobody raises a stink.
Yet for PQ algorithms there is an almost religious fight against using them standalone because some people feel that those algorithms are not proven enough.

Bernstein's Blog

Posted Dec 10, 2025 17:24 UTC (Wed) by brunowolff (guest, #71160) [Link] (4 responses)

People do make a stink about having NULL ciphers in protocols. They can make downgrade attacks easier and allow for people to think encryption is being used when it isn't.

Bernstein's Blog

Posted Jan 5, 2026 11:59 UTC (Mon) by sammythesnake (guest, #17693) [Link] (3 responses)

Additionally, and importantly, a PHB is a lot less likely to misunderstand "NULL encryption" as a GoodIdea™ than "Post Quantum Cryptography" *Something* to protect against that seems only sensible to me...

Bernstein's Blog

Posted Jan 5, 2026 12:58 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

Until someone decides to call it ROT-26 :-)

Cheers,
Wol

Bernstein's Blog

Posted Jan 5, 2026 15:08 UTC (Mon) by amacater (subscriber, #790) [Link] (1 responses)

ROT52 - it's the only way to be sure and with two additional encryption rounds it's bound to be more secure.

Bernstein's Blog

Posted Jan 5, 2026 16:01 UTC (Mon) by paulj (subscriber, #341) [Link]

I'd also add 2 rounds of XOR encryption, so that if one algorithm is broken you still have the protection of the other algorithm. Very unlikely 2 algorithms would be broken at once!

Bernstein's Blog

Posted Dec 9, 2025 20:06 UTC (Tue) by chris_se (subscriber, #99706) [Link]

> I think I saw an argument on the mailing list that one large company wants to use TLS with a PQ-only algorithm internal to their data centers, and as I understand it this form of "standardization" would simply give it a constant identifier for use with TLS, so they could contribute such implementations to publicly-reviewed OSS libraries and expect interoperability between suitably configured libraries. From that perspective, it can be argued that it's hard to fathom why one would want to prohibit others from using this, as that is the only technical effect of refusing to advance this standard.

If that was the sole reason they could have added some text to the standard like "The non-hybrid algorithm is optional and its use is discouraged. If implemented, it MUST be disabled by default and MUST require explicit configuration to enable it and documentation of the software regarding this algorithm MUST mention that the standard discourages its use". i.e. not just encouraging to use hybrid algorithms (which appears to be the current "consensus") but explicitly making it clear that this was added for some corner cases and nobody who doesn't know any better should use this.

Bernstein's Blog

Posted Dec 9, 2025 23:21 UTC (Tue) by mcatanzaro (subscriber, #93033) [Link]

TLS 1.2 was a mess of ciphersuites. We learned from that. TLS 1.3 has only a few options. Turns out, fewer is better.