Who SHOULD write crypto code?

Question

I've seen a lot of questions and answers acknowledging the dangers of inventing your own crypto algorithms — and even of implementing proven algorithms yourself. And, I don't disagree. I might even argue most of us don't even know how to safely use the existing libraries!

But, who should do it? What education, experience, or environment warrants writing your own crypto?

We dogmatically tell everyone who asks "don't roll your own! Use an existing library" But, somebody writes cryptographically secure algorithms and code. Who?

Who wouldn't we scold for "not using an existing library"? (And why do we trust them?)

---

As an aside, is there any place for the "common" developer to learn and contribute in a safe and beneficial or non-destructive manner?

Answer 1

You noticed the unfulfillable requirement: you are never told that you are ready to write crypto code.

I think the reason the "never roll your own" recommendation is always advised is because one is seeking recommendations. As a lower bar, the point where you no longer rely on public opinion for advice is when you can start thinking about crypto.

And, at that point, you fully assume all responsibility for what you create. The social group of developers never told you you could do it. You just decided to do it. And you live with the consequences.

Now, more specific than that, several experts recommend first trying to break other's crypto libraries before trying to write your own. Once you can break what's out there, you are more likely to be aware of all of the nuanced pitfalls that come with writing your own library.

But myself, I think of it with a martial arts metaphor. Think of an art where the black belt test is notorious. It shreds egos like it was As Seen On TV. You only get to take the test once. So many ask "am I ready for the test?" And the answer is invariably "You are never ready for the test."

So when are you ready for the test? When you realize you don't need a test to let people know you're good enough to be a black belt. You know it. So you just put on a black belt, stare down the experts who were supposed to give you the test, and they nod as if to say "yep, that was the trick the whole time."

Answer 2

If you have to ask this question, you shouldn't write crypto code.

If you're talking about implementing an existing algorithm, all it takes is an experienced programmer with an understanding of side-channel attacks, secure program design, and a good understanding of cryptography. It's not easy, but it's not a high bar. These people can be hired to write the cryptographic libraries that everyone else should be pushed to use.

If you're talking about developing an entire new cryptographic algorithm, on the other hand, the answer is no one. Yes, really. No one. Not even the best cryptographer should be writing their own algorithm and using it without it undergoing serious review by other cryptographers. However, they are the people whose algorithms are most likely to withstand cryptanalysis. If you have a PhD in cryptography and have a well-known name in those circles, then you might be able to either assist with, or design an algorithm that has more than a snowball's chance in hell to withstand the barrage of attacks other cryptographers will subject your design to, assuming you can convince them that it's worth it.

Answer 3

First, note that I'm talking about implementing actual cryptography functions, i.e. encryption, signatures etc. This is different from just using existing cryptography functions (much easier, but still many errors possible) and different from designing cryptographic algorithms (much harder).

Also, while I write code in a security context and also use existing cryptographic functions I don't write crypto code. But I understand that many things can go wrong when writing such code because I've read enough examples about cases where things went wrong. And I also know that I don't understand enough of the topic yet to write secure crypto code. Specifically I know that it is not obvious even for most experienced programmers when crypto code behaves wrong in some edge-cases or has unintended side-effects which might leak parts of secrets.

Given that I better don't write such code myself it is hard to give good recommendation on who should write such code, but I try to extrapolate from my experience with writing non-crypto software in a security context.
So who should write crypto code then - at least crypto code which gets used in production?

If you have the feeling that you'll understood all of the problems with writing such code then you probably overestimated your knowledge - see Dunning–Kruger effect. If you have some coworkers who already have a more widely acknowledged reputation for writing good crypto code let them review your code. If they find nothing to complain you should better be suspicious since it is unlikely that your code does not have even a tiny risk which should at least be discussed. Thus you should better get another opinion.

After doing this for a while you probably get the necessary experience to write good crypto code. But even at this stage you likely feel more comfortable if you ask coworkers for review and discuss potential risks with them, even if these seem mostly theoretical to you.

Answer 4

Schneier's Law is relevant here: Any person can devise a code that he or she cannot imagine being breakable; the value comes when a bunch of other people try to break it and cannot.

According to that logic, we should never allow any given person to write his or her own crypto for use. But we can allow any person to write one, then put it out for review, then improve it, and if the community eventually agrees that it's a pretty good system, then it's okay for use. Don't trust a person; trust a community and a process.

Answer 5

The real question (as I see it) is not who can write it, it who gets to accept it as standard and actually use it. This is almost never a single person. But as has been stated this advice is not meant for large groups reviewing, refining, and attempting to break proposals. It was meant to stop a-guy-who-wants-some-crypto going all judge, jury and executioner and rolling their own, and accepting it themselves.

The acceptance thing isn't about the people that wrote it. You rarely need to eat your own dog food in cryptography. You try to convince your would-be users. How they decide is a different matter.