Hacker News Reader

Comment by coppsilgold | Hacker News Reader

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://competitions.cr.yp.to/round3/ocbv11.pdf>

View on HN

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".

Calling it the default mode sounds a bit risky, if one assumes that defaults are secure.

The implication, of course, is that the defaults in cryptography are rarely secure.

That seems like something we should to try to fix, rather than lean into

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.

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?

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.

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.

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...

naive mode

"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.

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).

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.

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.

Reply on news.ycombinator.com