3 ms·

There is an AES secure mode of operation that is almost on the level of ECB in terms of performance: OCB[1]. OpenSSL has support for it and all patents have exp

There is an AES secure mode of operation that is almost on the level of ECB in terms of performance: OCB[1]. OpenSSL has support for it and all patents have expired. The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes AES-256-GCM 655193.56k 1747223.44k 3399072.36k 4490100.61k 5033129.30k 5108596.96k AES-256-OCB 631357.15k 2268916.74k 4794610.30k 6492985.36k 7174274.14k 7301540.60k AES-256-ECB 997960.96k 3972424.35k 8096120.70k 8105542.89k 8179659.94k 8188882.64k [1] <https://en.wikipedia.org/wiki/OCB_mode https://en.wikipedia.org/wiki/OCB_mode>, <https://competitions.cr.yp.to/round3/ocbv11.pdf https://competitions.cr.yp.to/round3/ocbv11.pdf>

tptacek 3y ago
In the main, people don't use ECB for performance; they use it because it doesn't require any library support and it doesn't require you to understand what a "cipher mode" is --- it's just the cipher applied directly to the plaintext, which, if you don't have any cryptography domain knowledge, seems like a totally sane thing to do. I'm an advocate for calling ECB "the default mode".
- Retr0id 3y ago
  Calling it the default mode sounds a bit risky, if one assumes that defaults are secure.
  - tptacek 3y ago
    The implication, of course, is that the defaults in cryptography are rarely secure.
    - Retr0id 3y ago
      That seems like something we should to try to fix, rather than lean into
      - tptacek 3y ago
        Good luck! The reality is that this was a lot more relevant 10 years ago; today, new code is much more likely to use GCM or Chapoly than to generically compose a cipher mode with (hopefully) an authenticator.
        Retr0id 3y ago
        Cryptography libraries etc. are moving towards exposing AEAD modes by default, so doesn't that make it even more weird to call ECB a default mode?
        tptacek 3y ago
        It does. I'm not saying it's not a weird me thing. It was a better rhetorical dunk back when people were rolling their own message encryption; then it served as a kind of warning that if you just took the library defaults and the simplest path to getting your code working, you'd end up with something totally insecure.
    - hinkley 3y ago
      Is there a legitimate reason to use it? Or is this a backward compatibility thing that nobody has made a fuss about? Sounds more like a foot gun to me.
  - magicalhippo 3y ago
    Perhaps call it the dumb mode, as in it's not doing anything more clever than straight application, and it's dumb to use it like that...
- jofla_net 3y ago
  naive mode
- trifurcate 3y ago
  "Insecure mode" sounds a lot better than "default mode". If I didn't know what any of the options meant, I'd feel safe using BlockCipherMode.Default, but I wouldn't feel safe using BlockCipherMode.Insecure.
- bandrami 3y ago
  It's also more resilient to partial transmission errors (that's just a different way of describing the same property that is its security weakness).
  - tptacek 3y ago
    That's Applied Cryptography logic. Applied Cryptography allocates a lot of space to discussing error recovery in ciphers, a concept that has essentially no place whatsoever in modern cryptography --- if you're worried about transmission errors, solve that problem at a higher level with an error correcting code, or send smaller messages so your system can tolerate the loss of messages.
barathr 3y ago
Exciting to hear that about OCB -- I hadn't been keeping track of the expiration. It's great that there's now a widely-usable, single-pass, block-cipher-only authenticated encryption mode.

tptacek 3y ago

In the main, people don't use ECB for performance; they use it because it doesn't require any library support and it doesn't require you to understand what a "cipher mode" is --- it's just the cipher applied directly to the plaintext, which, if you don't have any cryptography domain knowledge, seems like a totally sane thing to do. I'm an advocate for calling ECB "the default mode".

Retr0id 3y ago
Calling it the default mode sounds a bit risky, if one assumes that defaults are secure.
- tptacek 3y ago
  The implication, of course, is that the defaults in cryptography are rarely secure.
  - Retr0id 3y ago
    That seems like something we should to try to fix, rather than lean into
    - tptacek 3y ago
      Good luck! The reality is that this was a lot more relevant 10 years ago; today, new code is much more likely to use GCM or Chapoly than to generically compose a cipher mode with (hopefully) an authenticator.
      - Retr0id 3y ago
        Cryptography libraries etc. are moving towards exposing AEAD modes by default, so doesn't that make it even more weird to call ECB a default mode?
        tptacek 3y ago
        It does. I'm not saying it's not a weird me thing. It was a better rhetorical dunk back when people were rolling their own message encryption; then it served as a kind of warning that if you just took the library defaults and the simplest path to getting your code working, you'd end up with something totally insecure.
  - hinkley 3y ago
    Is there a legitimate reason to use it? Or is this a backward compatibility thing that nobody has made a fuss about? Sounds more like a foot gun to me.
- magicalhippo 3y ago
  Perhaps call it the dumb mode, as in it's not doing anything more clever than straight application, and it's dumb to use it like that...
jofla_net 3y ago
naive mode
trifurcate 3y ago
"Insecure mode" sounds a lot better than "default mode". If I didn't know what any of the options meant, I'd feel safe using BlockCipherMode.Default, but I wouldn't feel safe using BlockCipherMode.Insecure.
bandrami 3y ago
It's also more resilient to partial transmission errors (that's just a different way of describing the same property that is its security weakness).
- tptacek 3y ago
  That's Applied Cryptography logic. Applied Cryptography allocates a lot of space to discussing error recovery in ciphers, a concept that has essentially no place whatsoever in modern cryptography --- if you're worried about transmission errors, solve that problem at a higher level with an error correcting code, or send smaller messages so your system can tolerate the loss of messages.

barathr 3y ago

Exciting to hear that about OCB -- I hadn't been keeping track of the expiration. It's great that there's now a widely-usable, single-pass, block-cipher-only authenticated encryption mode.