Bernstein's Blog

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

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

to post comments

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)