Bernstein's Blog

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

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.

to post comments

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)