But, yes I wouldn't start out on writing a crypto library, then again I wouldn't attempt to build an OS or a 3D stack or even an web server either. All cases where a security breach could have devastating effects as well.
* 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
* ...
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.
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.
As for your second point: literally everyone can implement cryptography that appears secure to them. It's tautological.
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.
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".
But then, I'm a believer that everyone should learn crypto by breaking it, and clearly not everyone agrees with me.
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:
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.
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?