Writing your own crypto is the only way to become good at it, or to understand more about crypto.

* DJB wrote NaCl

* Frank wrote libsodium / libHydrogen

* Brian wrote Ring

* Thai Duong and Bleichenbacher wrote Tink

* Eric Young wrote OpenSSL

* Jason Donenfeld wrote Wireguard

* Shoup wrote NTL

* Emily Stark, Mike Hamburg and Dan Boneh wrote SJCL

* Thomas Pornin wrote 6 SSL libraries and then BearSSL

* Adam Langley wrote everything else

* ...

This is a deeply misleading list.

Daniel Bernstein, Daniel Bleichenbacher, Dan Boneh and Thomas Pornin are professional cryptographers and world-renowned experts. Even I would feel comfortable writing crypto if Bleichenbacher was watching behind my back.

Frank "wrote" libsodium, but libsodium is effectively a port of NaCl. Frank had Daniel Bernstein watching behind his back.

Eric Young wrote OpenSSL. Look how that turned out! Has there been a class of cryptographic vulnerability that OpenSSL hasn't had?

And yet consider: for all the effort that people like Bernstein and Boneh put into writing strong, safe crypto, the entire world has blundered into vulnerability after vulnerability because the amateurish crypto in OpenSSL is the one every else ended up using.

It's as if you set out to prove my point.

Finally: you obviously know that "writing your own crypto" isn't the only way to become good at it. In fact, it's a terrible way to get good at it. The right way to get good at crypto is to learn how to break it. But that takes effort, and you can have a blog post crowing about your new crypto library just a few weeks after deciding to write one.

> are professional cryptographers and world-renowned experts

They were not in the beginning. And implementing crypto helped them get there. That's my point.

> Finally: you obviously know that "writing your own crypto" isn't the only way to become good at it. In fact, it's a terrible way to get good at it. The right way to get good at crypto is to learn how to break it.

I strongly disagree with you on this, but I'll add a twist: I'm mostly saying to become good in "applied" crypto you must roll your own. There are too many problems you can't understand until you actually write code and try to make it secure. If you want to become good in theoretical crypto, then don't roll your own obviously.

This works in any field btw. The best web pentesters are the people who have implemented websites on their own as well.

I would suggest that for each of them, a 10+ year career in academic cryptography, in each case accompanied by significant new research results, is what helped them get there. Implementing a library, not so much.

As for your second point: literally everyone can implement cryptography that appears secure to them. It's tautological.

> I would suggest that for each of them, a 10+ year career in academic cryptography, in each case accompanied by significant new research results, is what helped them get there. Implementing a library, not so much.

I believe that what made them exceptional (for most of them) is the combination of theoretical learning and hands-on programming. That's my entire point. I think we can agree to disagree. But that's an opinion I'll probably hold for the next years as this is the direction I want to take as well.

> As for your second point: literally everyone can implement cryptography that appears secure to them. It's tautological.

And the process of putting it out there and looking for ways to make it more secure is how you learn. Proof: he already learned a bunch about Frama-C and other C oddities and documented these via his blogpost. Plus he found a bug in the Argon2 implementation. That's a win.

Why don't you ask them? Most of these people aren't hard to get ahold of. One of them you even share a Slack with. I would be surprised to learn that any of them believed doing a library implementation of pre-existing crypto constructions was an important part of their education, but I like to be surprised.

I did ;) surprise

What did he say? Share with the class!

I can't share this kind of personnal information Thomas. I'm sure you understand! I guess you'll have to take my word for it.

Ok, I'll ask Thomas Pornin myself.

I indeed learned a lot, and still learn a lot, by doing implementations. Doing a proper implementation forces me to consider all aspects; when the code runs properly, I know that I have, by definition, been exposed to all the parts. You cannot get that kind of exhaustiveness from simply reading an article.

However, doing implementations is not at all the same thing as publishing implementations! The first one or two attempts are always flawed in some way; only the third one can hope to be reasonably good. I took care to properly kill and dispose of the corpses of all my learning code.

The trick (and it's a difficult one) is to decide in advance that the code you write to learn will have to be deleted -- and stick to it. Developers have trouble letting go of their creations, in general. If you can maintain that discipline, then there is no problem in "writing your own crypto". But that is a big "if".

I've found that a good motivation for writing learning-only "throwaway" crypto code is as models for writing attack code; you don't even have to throw the code away, just publish it with the exploit.

But then, I'm a believer that everyone should learn crypto by breaking it, and clearly not everyone agrees with me.

Thanks for the input! This reminds me of what Amelie Nothomb says: "unlike a lot of writers, I have the decency to toss most of what I write". I don't think it's necessarily bad to publish crypto code. Marketing it as secure is another thing. I've marked most of my implementations as "readable" implementations meaning that are only there for educational purposes.

(rereading this, I feel like I should add: 'baby works with Thomas Pornin now.)

"libsodium" is just NaCl with autoconf cruft added.

NaCl does not use autoconf nor even make.

It is not necessary but if someone really feels compelled to use it, why stop them?

I have never seen any author or end user comment that they dislike using autoconf, or write alternatives to it. Autoconf is loved by all, isn't it?

I think what you could say is that using NaCl in your own software is the only way to get good at using it. Maybe the existence of libsodium means that more developers will have a go at using NaCl? Is it easier to use than an SSL library? The only way to find out is to try both and compare.

There is no need to use autoconf to build libnacl.a. The original build system for NaCl is beautifully simple. But if someone misses autoconf and make, then libsodium has added in those dependencies.

More projects using NaCl:

http://ianix.com

As far as I can tell, the authors listed on the above site are not "rolling their own crypto" for their projects, they are using cryptography written by the author of NaCl.

Personal bias disclosure: I find NaCl easier to use than all the SSL libraries I have tried. If I am not mistaken, I believe this was a design goal by the author.

He wrote libhydrogen

oh man, making that list and leaving out the bear....

shame on me, I edited the list.

Another angle is that a compromised security protocol used by a 100,000 developers is far more fruitful than having to assign a human specialist to crack & reverse engineer 100,000 uniquely thought-out implementations.

This is the point people miss. Same as wordpress vs creating your own blog. The more popular the software the larger the interest and the bigger exploit if successful.

It is less likely, though, and more likely to get fixed everywhere fast.

100,000 easy to crack implementations with obvious errors isn't really more secure than 1 super difficult, super well optimized/secured implementation, is it?

It is more difficult to crack 100,000 different interfaces because the time required to learn each one is a fixed cost. Having one central implementation makes it much easier to expliot because if an issue is discovered it can be immediately used everywhere. Don't put all your eggs in one basket.

> more likely to get fixed everywhere fast openssl bugs were around for a very long time

exactly. a very shitty unique implementation is much less likely to be hacked than a near bulletproof implementation used by millions with a single flaw.