Sorry, this tweet is nonsense. The implementation is in assembly because people complain about crypto performance and to avoid side channels. Code was written by competent people who should implement crypto. Language is not "safe", it's safe against some mistakes, not logic bugs.https://twitter.com/marcan42/status/946252676781748224 …
That's my point. The usual excuse for reinventing the wheel in your pet language (it's "safe"/native/whatever) is nonsense for crypto, because your biggest threat is implementation logic bugs like this one. Even competent people fuck up. Stick to well tested implementations.
-
-
The corollary is that languages with poor FFI/binding support and thus a culture of wheel reinvention (like Go) are at a higher risk of security issues when crypto is is inevitably reimplemented as a result, regardless of how competent the implementors are.
-
How does this play into the "crypto library monoculture is bad" theory? Clearly there's a market for things that aren't OpenSSL.
- Show replies
New conversation -
-
-
I'm not sure about that. There are much more buffer overflow or similar bugs than logic bugs.
-
Not in crypto code. Crypto code usually has very well defined input/output buffers with either completely fixed or completely arbitrary sizes.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.