3 ms·
That holds not only for cryptography libraries, but generalizes to the entire computing stack. It's why, for example, coreboot exists, as well as various open s
by mrngm 1y ago
That holds not only for cryptography libraries, but generalizes to the entire computing stack. It's why, for example, coreboot exists, as well as various open source hardware projects. If it's fully open, you can inspect it yourself. Anywhere I see a branching statement within cryptography context, I'll know something's up.
The problems introduced in xz are still fresh, but Dual_EC_DRBG[0] also comes to mind within the cryptography context.
(Besides, getting cryptography right goes way beyond "just writing a library". As the parent commenter wrote, simple operations are the tip of the iceberg with regards to a correct implementation)
[0] https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
- deadbabe 1y agoIf you’re not aggressively vetting the crypto libraries you’re using, you’re more or less exposing yourself to the same probability of risk as rolling your own crypto.
- immibis 1y agoIf you're picking some random blob of code from Github, then yes. If you're picking OpenSSL or Bouncy Castle, then no. Despite Heartbleed.
- mrngm 1y agoI'll pick my battles, it's part risk appetite and part expected attacker model. It also depends on what I'm trying to protect. If it's in a standard library of an open source programming language, I'm less inclined to fully check the implementation.