3 ms·

Actually, now that we have decent LLMs, rolling your own crypto is probably feasible.

immibis 1y ago
Any fool can write an encryption algorithm that he himself can't break. The NSA would greatly prefer that you did, too. Security is an arms race - you have to counter the latest generation of attackers. It's okay to write a compiler or a database if you only know the basic principles, but it's not okay to write an encryption algorithm, or even an implementation of one, using only basic principles, because someone who knows more than you will break it. For instance, were you aware that every time you write array[index], it leaks data to other threads in other processes on the same CPU, including JavaScript code running inside web browsers?
- deadbabe 1y ago
  Yes of course, but do you know exactly who wrote your encryption libraries and what their qualifications are and who they work for or what their conflicts of interest might be? I really doubt people give it even a second thought.
  - 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 ago
      If 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 ago
        If 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 ago
        I'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.
  - immibis 1y ago
    When you use OpenSSL, you can trust that if you're screwed, so is the whole internet. That actually happened once.

Any fool can write an encryption algorithm that he himself can't break. The NSA would greatly prefer that you did, too. Security is an arms race - you have to counter the latest generation of attackers. It's okay to write a compiler or a database if you only know the basic principles, but it's not okay to write an encryption algorithm, or even an implementation of one, using only basic principles, because someone who knows more than you will break it. For instance, were you aware that every time you write array[index], it leaks data to other threads in other processes on the same CPU, including JavaScript code running inside web browsers?

deadbabe 1y ago
Yes of course, but do you know exactly who wrote your encryption libraries and what their qualifications are and who they work for or what their conflicts of interest might be? I really doubt people give it even a second thought.
- 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 ago
    If 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 ago
      If 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 ago
      I'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.
- immibis 1y ago
  When you use OpenSSL, you can trust that if you're screwed, so is the whole internet. That actually happened once.