Please see the disclaimer.
Epistemic Status: Ticked off, trying to calm down.
You don’t know me, unless you’ve had the pleasure or misfortune of coming across me on the Internet.
I’m not a cryptographer, so you shouldn’t listen to me.
However, I am studying to become a Level 3 cryptographer. I’m nowhere near close yet, but, I now have enough knowledge to be dangerous.
No, I’m not rolling my own implementations yet, so I’m not a danger to my users.
Get off my back.
So maybe you should listen to me. Just in case.
First, an apology: to make this easier, I’m going to use the word “crypto” instead of “cryptography.” I know that some people will read that as “cryptocurrency,” but I don’t deal with that trash. I mean real cryptography.
This letter is to you “real” cryptographers, and by that, I mean all Level 4 cryptographers, the ones who invent, research, and otherwise prove new crypto.
Now, I don’t know exactly what’s going on, but I do know that there are rumblings of disagreement.
Normally, I wouldn’t care, as disagreements on new things are to be expected.
“Well, that’s because you’re probably a fan of DJB and believe everything he says! You believe he’s doing the right thing in this crazy lawsuit, don’t you?!”
No, not at all.
The problem is that I do not know what to think!
And as I’m sure you know, not knowing what is true in crypto is perilous.
I’ve listened to you all over the years, and I’ve heard you say, over and over again, that crypto is not something you can guess with; you have to know.
You said that crypto should include proofs of security, and I believed you.
You said that programmers should not use crypto primitives like Legos, and I believed you.
You said that programmers should not roll their own crypto, and I believed you.
If fact, you said it enough that Argon2i was not independently re-implemented for two years! Or even if it was, the reference implementation and spec both had the same bug! 1
I agree with Loup Vaillant: this “don’t roll your own crypto” went too far.
You said that breaking crypto is how you learn it, and I believed you.
And then you said that, no, breaking crypto is not necessary to learn it anymore, and I didn’t know what to think anymore.
Now, this small disagreement probably doesn’t matter in practice.
But the failure to reimplement Argon2i? That is…disconcerting.
It gets worse, and Argon2 is still at stake.
It may not be the best password-based key derivation function, apparently.
Well, then, why is everyone recommending it?
This is where I sigh and adjust what I do to fix your mistakes.
For example, I use Argon2 where I can, but where I do use it, I make it run for at least 3 seconds, 3 times longer than the threshold where it supposedly becomes better than bcrypt. Just in case.
And on that note, I get that crypto is hard, but do you really need to make it so inaccessible?
When I started learning, I was bombarded with weird terms and math, and I had to slowly build my vocab and reasoning. That learning curve was steeper than sheer cliffs.
Making things more accessible is important because security will always be weak as long as two things are true:
- Crypto is hard to learn, and
- You need to learn crypto to roll your own.
Look, I get it; crypto is hard, maybe it will always be hard to learn. So perhaps programmers should do what you say and refuse to roll their own.
Ha! Fat chance! This is the real world, and the real world doesn’t care about that!
Sometimes, bad crypto is better than no crypto, so programmers will roll their own.
The only thing to do is make crypto easier to learn.
I think it’s possible. I don’t think crypto needs to be hard to learn in the lower levels. If it was much easier to learn Level 1 Crypto (“Using Crypto”) and Level 2 Crypto (“Choosing Crypto”), maybe rolling your own crypto would be much more possible.
“But Gavin, rolling your own is still Level 3 Crypto.”
And that brings up a question: why not?
“Uh, well, with crypto, the whole system matters, and uh…”
Yes, I believe you. But why is it that way when it doesn’t have to be?
“Oh, but it does!”
And this is the first time I just don’t believe you.
They are a nice idea; people use passwords to prove to an online service that they are who they say they are, without sharing the password!
Sounds great! Sounds wonderful!
Sounds like they could be used instead of passkeys, with all of their freedom problems!
SO WHY FOR THE LOVE OF ALL CUTE THINGS ON EARTH ARE YOU NOT RAISING CAIN AND PUSHING PAKE’S INSTEAD OF PASSKEYS?!
“Well, uh, because passwords in PAKE’s are still phishable…”
Implement OPAQUE in the browser, and it doesn’t matter what site is running a man-in-the-middle; that password never leaves the user’s machine!
So stop fooling around, get OPAQUE as an official RFC, and put it in the browser!
Yes, I’m really mad! Passkeys could be the chains the imprison me and my loved ones!
Okay, I get it, I could be misunderstanding the point of PAKE’s. I’m sure that if I am, you all can argue that fact effectively.
Instead, you all are arguing in circles about whether or not there was a math mistake in Kyber’s security level!
Yes, DJB, I tried to read your treatise. Ain’t nobody got time for that!
Make it short and punchy. And don’t spike the punch.
Anyway, I bet that part of the reason other cryptographers are still debating whether there was a mistake or not is because your post is too long to effectively read.
Make it accessible, and you might kill two birds with one stone.
As for the rest of you cryptographers, why is there still a debate about Kyber? Go over the math, figure it out; the rest of us can’t do anything until you do.
Which just means we’ll be vulnerable to quantum computers for longer.
Yes, your bickering is making us all less safe! That goes for you, DJB, and that goes for everyone else.
Focus on the truth! What algorithms are the cheapest, and easiest to implement, while being safe enough?
DJB, if that means your submission is not the best, you had better cool your ego and deal with it. Being actually correct is far more important than being thought correct.
Because again, not knowing what is true in crypto is perilous.
And for the rest of you, if that means his really is the best, well, we’re all just going to have to deal with the impending crypto monoculture, aren’t we?
Now, you all may say that you’re trying to understand DJB’s argument, and if you are, good. (Seriously, DJB, can you distill it down?)
But once you do understand it and help the rest of us to understand it, you all and DJB need to amicably shake hands, acknowledge that you hate each other but that you won’t let that get in the way of being professionals, and then crack each other’s algorithms like professionals because the best revenge would be to find that juicy break.
“Oh, we don’t hate each other.”
If that’s how you speak in public, I can only imagine the animosity in private.
And to speak on that last email specifically: DJB, sure, the NIST appears to be stonewalling you in that thread, but before that, they did say they wouldn’t engage any further.
Is that good? No, and I don’t like what they did there. I do lay part of the blame on them.
But I still lay some blame on you. Here’s why: did you have proof before you went forward with the accusations?
After all, not knowing what is true in crypto is perilous.
This may sound stupid, but I’m sure someone of your level could have implemented Kyber-512 and started measuring. After all, Linux has some great profilers, including ones which measure memory cost.
So take a deep breath, go back, and redo everything. If you were wrong, please do as suggested here and retract your accusation.
The rest of you, well, you should measure too. Quite frankly, as a programmer with a bit of experience, your numbers about memory access seem like they may have been pulled out of nowhere. Where is that justification coming from?
Okay, never mind, after reading this, those numbers make more sense.
And saying things like this:
“ML-KEM-512 is useful” is more important than “we can’t quite agree on how to count its bits of security”.
seems overly optimistic; we need to know the exact number, or at least a hard lower bound!
Anyway, please apologize to each other and start re-engaging as professionals. And do the math and the measuring.
That said, if DJB is wrong, and it turns out he started this drama without proof and solely because of ego, I think I tentatively support the proposal here, except that instead of a ban for life, DJB would have to show that he has capped his ego to acceptable levels.
Which DJB, please do, even if they don’t kick you out. As a fellow blunt speaker (hey, I’ll admit it), that’s part of why NIST is not engaging with you.
Because the funny thing about persuasive writing is that you do have to persuade. And the funny thing about people is that if you attack them, they get defensive and tend to reject logic; persuasion never works at that point.
Yes, I know I’m guilty of that here. I’m not a great writer, and this letter is hard because I have to walk a fine line between smacking you all hard enough that you’ll get my point, but also making it clear that I believe in you all.
And I do! I’ve trusted you this far, and if you all correct things, I’m willing to trust you going forward.
But until you do, this drama is making me nervous.
I agree with this user, who said:
So they have a terrible history but this time they’re playing it straight? Based on what? Gut feeling? I am sorry but that’s about as useful to the interested outsider as Dan’s claims. Seems to me the safe bet is to use crypto that’s been well-designed but far away from the NSA/NIST folks.
Cryptographers, you are right that DJB shouldn’t cry wolf when there’s no wolf, but having NSA people on the NIST competition team is a real wolf.
I understand that there’s a possibility that they could have done nothing nefarious, but dismissing the possibility by saying it’s “unlikely” is nigh negligent.
And that brings me to you, NSA. You are the reason this is a problem. Not DJB, not other cryptographers. You caused this.
Matthew Green is right when he says:
What’s so aggravating to me is that the NSA holds a vast amount of the US (and global) cryptanalytic knowledge. We need them to weigh in on these new algorithms, which will ultimately be used to secure US classified data and military secrets.
And yet, by interfering with and sabotaging cryptography in the past, the NSA has utterly destroyed its credibility with the scientific world. This is ultimately enabling the current campaign against NIST’s PQC standardization effort, and the result could be really harmful to global infosec.
I think the academic community could benefit from less cynical exploitation of this fact. But the NSA is still ultimately to blame for where we are.
Whatever benefits the agency got from its sabotage campaign in the past were short-term and ephemeral. But the damage is cumulative and lasting — like spending too much time in the sun.
So you done messed up, and you have to accept that fact. You have to act like it.
Unfortunately, Matthew Green is also right when he says:
The problem here is that NSA has a fabulous amount of our national cryptanalytic knowledge. Since what we’re debating here will ultimately be the algorithms used by NSA and the US DoD, it’s essential that they weigh in on these new algorithms.
And of course their opinions are based on classified knowledge so there has to be trust. And what’s so frustrating is that they destroyed that trust in the past. The result is what’s happening right now.
In other words, you, the NSA, need to weigh in, but you have also lost the trust to weigh in.
How do we square that circle?
I think the answer lies in crypto history, in a paper called “A Riddle Wrapped in an Enigma”:
The first time the NSA publicly and decisively gave support to ECC occurred at a meeting of the American National Standards Institute (ANSI) in December 1995. The backers of RSA at the meeting were casting doubt on the safety of ECC-based protocols; in the mid-1990s a page called “ECC Central” on the RSA website carried statements by leading personalities in cryptography that characterized ECC as untested and based on esoteric mathematics. The nontechnical industry representatives on the ANSI committee were impressed by the RSA argument. As the heated debate continued, the NSA representative left to make a phone call. When he returned, he announced that he was authorized to state that the NSA believed that ECC had sufficient security to be used for secure communications among all U.S. government agencies, including the Federal Reserve. People were stunned. In those days the NSA representatives at standards meetings would sit quietly and hardly say a word. No one had expected such a direct and unambiguous statement from the NSA. The ECC standards were approved.
So why does this work? The key is to remember that we only need one bit of information from you as the NSA: would you be willing to use a cryptosystem for your own stuff?
In this context, “your own stuff” also includes all communications of the US Federal Government.
If you are, then chances are we common folk can trust that answer because as much as you want to read our stuff, you don’t want others to read your stuff more.
That’s all you should give. Nothing else. Just one single bit of information.
And until then, you should go to your corner and play alone, quietly. You don’t have the right to play with the cool kids even though you’re more intelligent; trust is more important than intelligence.
Actually, NSA, that’s a good general lesson for you: you will better serve your mission if you did the hard work of earning trust back, not just from cryptographers, but from the average American, than you would by the extra intelligence gleaned from the shady and unconstitutional tactics you use now.
And the worst part is that when I was younger, I wanted to work in cryptanalysis for you, but I can never do that because I will never support your activities.
Er, ahem, I got a little sidetracked.
For the rest of you all, let’s figure out the math and ensure that the hard lower bounds are proven. I don’t care if Kyber has the most security as long as it has enough.
I want one with 256 bits, but I’ll accept one with a 128-bit hard lower bound. No fudging with “Oh, it’s almost as hard as AES-128.”
But I also wonder whether these primitives are okay. Because if you can’t figure out the math, maybe it’s too complex? If you all struggle, where’s the hope for mere mortals such as myself?
In my opinion, the best crypto primitives are, in order:
- Hard for classical and quantum computers.
- Simple to implement, including without side channels.
- Easy to understand.
If lattices are the best of what we’ve got, fine. But maybe there’s some notoriety to be found in finding a new crytposystem family?
Now, where was I? Oh, yeah, I was talking why I don’t believe that cryptosystems can’t be assembled like Legos.
My reason for this, and it might be shaky, is OPAQUE.
I’ve read the OPAQUE paper. I’ve read the RFC draft. I’ve read and studied A Graduate Course in Applied Cryptography far enough to almost convince myself that the OPAQUE security proof is sound.
And one thing that strikes me about OPAQUE: the security proof relied on properties of primitives, not primitives themselves.
This is excellent! This means that properties are more important than primitives.
But more importantly, it means that, in order to use a particular primitive with OPAQUE, you don’t need to prove the cryptosystem as a whole; you just need to prove the primitive.
This is what A Graduate Course in Applied Cryptography does; it builds up proofs using properties, and then it proves that some primitives have, or don’t have, those properties.
In other words, A Graduate Course in Applied Cryptography shows that treating primitives like Legos is possible, and OPAQUE is the first existing proof of that fact.
That I’ve seen.
That’s why I don’t believe you on this; you have already proven yourselves wrong!
Even better, this points the way to a better way to learn cryptography.
Let’s go back to Loup Vaillant’s levels of cryptography:
We want to make it as easy as possible to climb that ladder.
So how easy could it be to get someone to Level 1? I think it could be as easy as learning a list of protocols to use, such as Cryptographic Right Answers, with a few tweaks to focus on high-level protocols such as:
- The standard encryption protocol for encryption. (Use asymmetrical encryption to bootstrap symmetric encryption, authenticate, encrypt-then-MAC, don’t use ECB, etc.)
- OPAQUE for passwords.
- How to generate random numbers. (
This is only possible if these high-level protocols are implemented in an easy-to-use form.
But they do have to be implemented a lot; every language needs its own easy-to-use implementation. Sometimes that may mean FFI to a C library; sometimes, that may mean direct implementation like FiloSottile is doing for Go.
But those libraries have to be easy to get, easy to build/import, and impossible to misuse. I’m talking pits of success here.
When done right, that should be all required to get a programmer to Level 1, and the world would be far better for it because this would be all that’s necessary for the vast majority of programmers.
But getting to Level 2 should be just as easy: in order to “choose” crypto, all they should be required to learn are
- The kinds of primitives that exist, and
- The actual primitives that provide those properties.
Yes, that’s it! All they need to learn is what is important, what can provide that, and how those things fit together.
For you non-cryptographer programmers reading this, it is crucial that you still learn what kinds of primitives exist; some Legos can only be used for certain things, and the same applies here.
If you have built up protocols properly, relying only on proven properties rather than direct primitives, this should be the point at which a programmer can Lego cryptosystems together.
And on that note, why has not one of you taken the step of actually proving the “standard” encryption protocol like OPAQUE was?
Seriously, set up the standard protocol, prove it using properties and then people can just put in certain primitives in certain places.
Or have you, and I just don’t know? Do the proofs in A Graduate Course of Applied Cryptography count?
This does mean that we need fantastic implementations of various primitives in all languages, of course, along with protocol implementations that can plug in various primitives.
But if we had that, this would remove 99% of all other use cases; programmers with special requirements would be able to grab the primitives they need and Lego them together without fear.
And cryptographers, you all could sleep easy knowing that crypto stupidity the world over is fading.
Anyway, what about getting to Level 3? I think that that is where the difficulty should ramp up.
But I would also break Level 3 into two sublevels.
Level 3.1 would be about implementing protocols, and to do that, a programmer should learn:
- How to read and evaluate proofs (this is both for evaluating systems and for understanding the “why” of things like encrypt-then-MAC, for example),
- How to break cryptosystems,
- How to exactly implement a protocol from a spec (a skill that would serve them well elsewhere too!),
- How to thoroughly test cryptosystems, and
- Probably other things that real cryptographers are welcome to correct me on.
Once there, they could implement high-level protocols and leave the primitives for those at a higher level.
Level 3.2 would be about implementing primitives, and to do that, a programmer should learn:
- How to break primitives,
- How to test primitives,
- What side channels are and what kinds there are,
- How to avoid them, and
- Probably other things that real cryptographers are welcome to correct me on.
Once there, they could implement primitives.
And of course, Level 4 can stay where it is with all of you PhD’s and researchers. Have fun staring into randomness.
Heh, this letter went everywhere, didn’t it?
I meant to spark correction regarding the PQC Competition, but I guess I had a lot on my mind after studying cryptography for so long with little to show.
The ironic thing about this letter is that, despite it stemming from my desire to enter the crypto world, it will probably make me a pariah.
Oh well, and I understand. But it’s because I care about the security and safety of everyone’s information. And I care about reducing crypto stupidity.
I’ll be the first to admit that I am not immune to criticism! There are tons of things here that you cryptographers can condemn. Please do. I would love it if cryptographers everywhere jumped on a bandwagon to clarify the truth.
After all, not knowing what is true in crypto is perilous.
But there is one thing that you cannot criticize or correct, and that is my view of what’s happening. Sure, I may be wrong about what’s going on, but this letter is about what I see.
At least I didn’t immediately believe this, but it still looks bad from the outside.
…And now I’m guilty of writing a treatise, just like DJB! Four thousand words, one quarter of the size.
Sigh…I’m sorry. I revised as much as I could. I understand if you don’t read it.
…Maybe that’s a good thing for me; then I won’t be a pariah!
Er, ahem, so long, and thanks for all the crypto!
Truly. Thank you.
A email to myself from Loup Vaillant. ↩︎