Bernstein's Blog

Posted Dec 10, 2025 0:01 UTC (Wed) by hailfinger (subscriber, #76962)
In reply to: Bernstein's Blog by brunowolff
Parent article: Disagreements over post-quantum encryption for TLS

> 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.

to post comments

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!