That block cipher would not in practice be much worse than the cryptosystems developers end up with when they use OpenSSL, its bindings in Python or Ruby, or "javax.crypto" to get AES.
AES in its default block cipher mode can usually be byte-at-a-time decrypted. AES in its "conservative" mode can almost always be byte-at-a-time decrypted when not augmented with another crypto building block that developers invariably forget. When developers don't forget that building block, they often manage to implement it in such a way that it too can by byte-at-a-time broken. AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters.
On the other hand, if you read the Wikipedia page on Feistel networks and wrote your own --- or if you just used reduced-round FEAL-4 --- but used Keyczar to actually deploy it against real data, all those mistakes I alluded to above would be avoided, and your attackers would have to do real cryptanalysis to attempt to break your application; nobody does that.
Knowing this, you can now see why I'd take issue with the idea that your "Secure Progammer's Pledge" urges people to use "vetted algorithms" to protect data. AES is about as "vetted" as algorithms ever get, and its use in production code by generalist developers is almost always comically insecure.
So: no, that one example turns out not to be more secure than AES, even in Keyczar. The problem is, by itself, it usually turns out not to be less secure either.
As a security researcher (but not necessarily a crypto one), I do not understand this comment.
> AES in its default block cipher mode can usually be byte-at-a-time decrypted.
1. Block ciphers don't have default modes. Implementations might. Does OpenSSL really use ECB as the default mode? (I agree wholeheartedly with you that sensible defaults are extremely important, and so ECB-as-default seems hard to believe.)
2. What does "byte-at-a-time" decrypted mean? You haven't specified the threat or attacker models.
Are you saying that given several million ciphertexts, you can recover the key from AES-ECB? AES-CTR? Does the attacker need side channel acccess? How about given one ciphertext? Or is this a chosen-plaintext or chosen-ciphertext attack?
In short, could you please detail the attack you have in mind?
> AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters.
As far as I can tell, this is entirely predicated on your later statement that "nobody does [real cryptanalysis]". What is AES's 'most "modern" mode'? Which parameters are you referring to here (key size, mode, any others?)
My guess is that XOR will fall in some small number of hours against someone who cares; AES-128-ECB (as bad as it is) may require many more resources for key retrieval.
For fun, which definition of security are you using to compare cryptosystems?
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.
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 :)
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.
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...
If you read my comment carefully, you'll see I'm talking about mistakes people make when using "safe" block cipher modes. The default mode is ECB, by the way, not CBE.
AES in its default block cipher mode can usually be byte-at-a-time decrypted. AES in its "conservative" mode can almost always be byte-at-a-time decrypted when not augmented with another crypto building block that developers invariably forget. When developers don't forget that building block, they often manage to implement it in such a way that it too can by byte-at-a-time broken. AES in its most "modern" mode ends up being exactly as secure as naive XOR when developers use it without understanding its parameters.
On the other hand, if you read the Wikipedia page on Feistel networks and wrote your own --- or if you just used reduced-round FEAL-4 --- but used Keyczar to actually deploy it against real data, all those mistakes I alluded to above would be avoided, and your attackers would have to do real cryptanalysis to attempt to break your application; nobody does that.
Knowing this, you can now see why I'd take issue with the idea that your "Secure Progammer's Pledge" urges people to use "vetted algorithms" to protect data. AES is about as "vetted" as algorithms ever get, and its use in production code by generalist developers is almost always comically insecure.
So: no, that one example turns out not to be more secure than AES, even in Keyczar. The problem is, by itself, it usually turns out not to be less secure either.