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.
-
The problem with OpenSSL is that it's not (only) a crypto library, it's a kitchen sync of crap mixing low and high level code. Sure, we're better off implementing a PKI and TLS in a safe language, but there isn't a market for more than one or two *good* crypto primitive libs.
- Show replies
New conversation -
-
-
I don’t have data to back it up, but I think there were more bugs discovered in OpenSSL than in the Go crypto library that reimplemented everything.
-
Does the Go code implement all the junk that OpenSSL does, are those bugs mostly in low-level crypto primitive code or in high-level protocols and formats, and are the same number of people *looking* for bugs in both of those? Lots of questions before you can make that assertion.
- 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.