Some people used to claim that you should never use your own crypto code because the libraries are designed by people infinitely smarter than you who thought of everything.
That is starting to ring hollow to me.
That is starting to ring hollow to me.
The sentiment behind that is to keep out those that don't know how to code. If everybody followed that advice there wouldn't be crypto code.
If you have the ability to create good code and are confident you can understand the maths of cryptography then by all means contribute to the community. If the past year has taught us anything it's that the crypto community needs more good engineers.
We can not just trust that these libraries are higher level esoteric magic that no mortal could understand. It is time to shine light on exactly what guarantees different libraries are providing, and how.
You're being pointed straight at the problems discovered by other people. Of course they're obvious to you now. The question is, can you just pick up some OpenSSH code, read it and run it, and find a new problem yourself when nobody is pointing you straight at it? Because I'm sure there's at least one in there for you to find.
(Note I did not ask you if you could find this problem. Too easy to imagine that you can now, too hard to realistically pretend you don't already know about it. I'm asking you about new problems that nobody currently knows about.)
a) I would not have thought of the issue of using a standard library call to load data. b) nobody would have checked my code and fixed it
so in the end, I'd still be vulnerable while openssh is now fixed.
In any case more organization than the number of orgs that would bother to check my code.
E.g. use VPN and password protection and encrypted volumes which are pretty standard. Add in a custom hardware switch that physically disconnects the power/network of a server containing sensitive data which is rarely needed and you will be protected against many exploits.
An easily exploitable buffer overflow or an extremely easily overlooked crypto blunder in a second layer can easily allow a way in.
I agree with the example given, but it's a rule that's wrong more often than it's right.