[tptacek]

This comment is harshly written, but I don't mean it personally (you're anonymous, so how could I?) and anyways, I don't know what else to do with this (common) sentiment of "I don't understand the vulnerabilities you're talking about so I'm going to assume there's something basic about how stuff works that I grasp but you do not".

You're a security researcher who doesn't know crypto. This stuff isn't hard, but for some reason, most security researchers know fuck-all about how to test and exploit crypto bugs. Don't take too much offense; I was in the same bucket until a few years ago (and I'm not far from it even now), and I've been a researcher since 1994.

ECB is the default mode not because people choose overtly to make it the default mode, but because it requires no parameters to make it work. Look at a generalist programmer's cryptosystem. Flip a coin. Did it come up heads? It's ECB mode, because that's the moral default.

Nothing I'm talking about involves "several million ciphertexts".

Nothing I'm talking about involves side channels --- at least, not precision measuring side channels. "Side channel attacks" are the voodoo totem that security researchers wave around when they don't know a specific attack that will break a cryptosystem. Sort of like not knowing how to pick a lock a pin at a time, but talking about "bump keys".

Nothing I'm talking about even involves the attacker knowing for sure what algorithm the defender used. We test for this stuff black box; it takes less than a week to train people to do it.

No, I'm not going to provide more details here. Not because I jealously guard this stuff (I've written most of this stuff on HN before, and I've given talks about it that are recorded online), but because every time I get into a thread like this, someone comes back and says "oh yeah well THAT attack is LAME and I assumed that any smart developer would already have defended against it" and I'd rather reveal ignorance for what it is.

ECB will fall in seconds in most situations. If you knew how to test crypto, you'd know that none of these attacks "retrieve keys". Again: don't take offense. People way smarter than me don't know this stuff. I think it's because the papers use math notation.

[blazingice]

I'd be the first to tell you that I don't understand crypto. Most people don't.

You're unwilling to have this conversation again; I understand. Do you have a link to one of your talks? I'd be interested in watching.

Can you at least tell me what definition you're using for "fall", if not key retrieval? Replay attack? Information leakage?

Edit:

> "I don't understand the vulnerabilities you're talking about so I'm going to assume there's something basic about how stuff works that I grasp but you do not"

Sorry if it came off that way! I'm assuming that you understand something basic about how this works that I do not, and wondering what it is :)

[tptacek]

The security of most block ciphers revolves, in some ways, on the difficulty of brute force iterating through very large numbers --- 2^128, say.

"Byte-at-a-time decryption" means creating a scenario where attackers can brute force numbers like 2^8, winning a single byte of "plaintext" (or whatever the equivalent is depending on the primitive you're targeting). If your block size is 16 bytes long, the attacker might have to brute force 2^8 16 times; with a laptop, you might be talking about whole seconds of work.

Block cipher attacks generally never recover crypto keys.

I am being intentionally vague. Not because I want to keep information from you, but because I don't want to create yet another crypto thread that gives developers a false sense of knowing what the risks are when building crypto.

If this is something you're seriously interested in, and you can code in any programming language, email me and I'll give you a syllabus of straightforward things to work on.

[ircmaxell]

Ok, you have me confused. I half want to raise the BS flag...

Could you explain something here? How can a block cipher that has 128 bits of output be attacked 8 bits at a time (where 1 bit change in the input will change on average 64 bits of the output in a non-predictable manner)? Sure, you can try every 8 bit permutation, but without knowing the form of the original text how can you know if you have a valid character? And how is that different from extracting "raw data" out of pure randomness (where the fallacy is obvious, you're extracting data that was never there)?

I'm genuinely interested, so if an email will do it, could you please follow up: ircmaxell [at] php [dot] net...

Thanks!

[tptacek]

If I sound smart about any of this stuff, alarm bells should be going off in your head, because in terms of testing and breaking crypto, I am a piker.

I think you get my point now. Maybe rethink the crypto stuff in your pledge.