Rustls doesn't really have to deal with the timing attack issue, because those issues are handled by the underlying crypto library, ring. And, ring wasn't built from scratch. It builds upon all the constant-time crypto code in BoringSSL and OpenSSL. And, we've improved the constant-timedness of the code in several ways and contributed most of those improvements back to BoringSSL.
I hate so much this logic - it stops evolution. Humanity have enough programmers to write new libraries and patch existing code. Competition is better than stagnation.
It's also an argument against disruption in general. Great progress happens when people stop iterating and start rethinking stuff that hasn't been rethought for decades (and the "stuff" has seen only tiny improvements over the years following this strategy, too).
Don't get me wrong, I'm not against disruption at all. It's just there're cases where doing this doesn't make sense. Write a new text editor, invent a new programming language, sure. But writing a new cryptography library? You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small.
Making things even worse is that you can't really write a crypto library without using C/assembly. So why write a new crypto library?
"You are throwing away decades of effort that went into to harden and secure the existing library, and your gain is pretty small."
If that were true, then it would be a good counterpoint worthy of long thought. The reality of crypto libraries is that popular ones often had preventable errors due to bad coding and/or unsafe language that also took entirely too long to notice.
"you can't really write a crypto library without using C/assembly"
I'd argue you can't write a crypto library using C by default unless you're a really good coder. C is just an accident of two team's bad hardware:
Languages like Modula-3, Free Pascal, and even Fortran were easier to analyze to ascertain the program's properties. It's why Modula-3 had first, standard library verified free of specific types of errors. Also took years to make a certified compiler for C which had been done in other, simpler languages. Finally, the top performer in secure, systems code is SPARK as illustrated when re-implementing C crypto in it caught a problem.
> Writing a cryptography library from scratch because the old one has too many security holes? Your implementation is likely to have even more.
That's not a reason to never write another crypto library ever. It's a reason to get started on a new one as soon as possible so it can start the process of being vetted.
Writing a cryptography library from scratch because the old one has too many security holes? Your implementation is likely to have even more.
We should really concentrate on making one implementation secure, instead of creating more libraries.