Hacker News Reader

Comment by zxcvasd | Hacker News Reader

if i were to guess, they are referring to CVE-2016-2183, which lead to deprecation of 3DES by NIST in 2019 (announced in 2017) and disallowing all uses in 2023. openssl also stopped including it in default builds starting in 2016 because it is considered weak.

View on HN

This is Sweet32, an attack on any block cipher with an 8-byte block size. We don't consider those ciphers "broken"; they just can't be used safely in some common modes. You shouldn't use 3DES or IDEA or Blowfish, of course, but I don't think they're considered "broken", not in the same sense that, say, RC4 is.

It's true that 64 bits was known not to be enough when DES shipped decades ago, but there is some difference between "We know that's a bad idea" and a demo showing why, and so I think I'm OK with the word "broken" in that context.

There's a reason POCs matter right? Why you feel comfortable (even though I don't agree) saying multi-threaded Go doesn't have a memory safety problem and yet you wouldn't feel comfortable making the same claim for C++.

I'm not a cryptographer but to me "broken" seems to imply that the core algorithm itself can be attacked. If merely applying it in certain ways as part of some larger system can fail then aren't most (possibly all) ciphers broken? It's entirely possible to do all sorts of stupid things.

Granted, a 2^32 block limit is pretty severe by modern standards.

Si (2^32)*8 works out to 34GB for TDES. How many applications involve encrypting that much data in one go?

Sorry, calling that a block limit was an error by omission on my part. 2^32 yields a 50% chance of reuse. If we pick a sane security margin it's a lot smaller. Assuming I did the math correctly just now, 2^-32 only gives you ~2^17 blocks; dropping that to 2^-24 yields ~2^21 blocks.

Off the top of my head, NIST was suggesting something like 8GB as the working limit. It would depend on your risk tolerance and the application in practice I guess. For something like video you might not really care about exposing a few 8 byte blocks here and there where the exposure is one block XORed with the other.

An aside, personally I quite like TDES for the purpose of generating secure handles and the like. The larger block sizes of pretty much every other common algorithm yield URLs and integers that are more difficult to work with. 64 bits is a manageable enough length and you don't have to implement the algorithm yourself (at which point you'd have rolled your own crypto).

Further aside, note that there are constructions designed specifically for that problem and its relatives:

https://www.cs.ucdavis.edu/~rogaway/papers/subset.pdf

This semantic argument was more plausible before the original commenter claimed 3DES can be "broken with little effort".

That's fair, I won't defend "broken with little effort".

Not to be rude, but it seems to me that you are engaging in some hairsplitting. In general, security people do not recommend to use 3DES or RC4 - even if RC4 is broken in other ways than 3DES.

RC4 is actually broken. It's fundamentally broken. As you run it, it's face melts off like the guy at the end of Raiders. It's genuinely weird nobody noticed how bad it was, in a practical sense, until the late aughts.

The 64 bit block size in 3DES (and Blowfish and IDEA) limits how much data you can encrypt under a single key. I think the real "tell" that this isn't hair-splitting is that people don't ever generally talk about Blowfish being "broken", just obsoleted.

People just don’t talk about Blowfish.

They do, but indirectly, the b in bcrypt stands for blowfish.

to any non-cryptographer, i think that's a distinction without a difference. it's disallowed from use by the major standards institute due to a vulnerability where people can recover the plain text.

that sounds "broken" to me, but i'm not a cryptographer. so, i'll defer to you when you say it's not broken. (i dont know what the cryptographer-specific definition of broken is -- it'd be great if you would shed some light on that)

Again: not a vulnerability in the cipher.

Reply on news.ycombinator.com