5 ms·

Ok, I'll bite. Why would it be more secure? Would the following block cipher be more secure than AES? function encrypt(block, key) { return block

Ok, I'll bite. Why would it be more secure? Would the following block cipher be more secure than AES? function encrypt(block, key) { return block XOR key; }

tptacek 14y ago
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.
- X-Istence 14y ago
  How would this change for example if instead of using just plain AES you use AES with a block cipher mode (CTR-BE/CBC/or others just no CBE)?
  - tptacek 14y ago
    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.
    - X-Istence 14y ago
      Excuse the typo, had just woken up.
- blazingice 14y ago
  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?
  - tptacek 14y ago
    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.
brohee 14y ago
Actually, depending on the mode of operation it may be about as secure as AES in ECB... That's it, not secure at all. Using a well known algorithm is such a small part of the overall security of a cryptosystem that it makes the call to use only well known algorithms useless by itself. Hence tptacek recommending using proven high level libraries (e.g. OpenSSL's EVP_* family of functions).
- tptacek 14y ago
  Whoah. Hold on. OpenSSL EVPxxx claims to be a "high-level interface", but isn't one. Here's some acid tests for high-level libraries: * Does the library expose block cipher mode choices to callers? It's not high-level. * Does the library expose IVs to callers? It's not high-level. * Does the library separate "encryption" from "authentication", offering the choice of doing one without the other? It's not high level. * Does the library by default allow users to pass in raw buffers as keys? It's not high level. Don't use OpenSSL directly to do crypto in applications.
  - brohee 14y ago
    I get your point, but pretty often you must respect some general mandate (e.g. must use this approved chaining mode, this certified PRNG...) and OpenSSL EVP comes very handy if you don't find a library doing exactly what you need. It still shields you quite a bit from the lower level mistakes to be made. What's your go to solution?
    - tptacek 14y ago
      Keyczar. For the situation you describe, a "low-level" crypto library is handy; for instance, very few libraries implement ciphertext stealing, so if you require compatibility with some wacky protocol or file format that uses CTS, OpenSSL EVP is no help either. That doesn't make OpenSSL's primitive interface a good choice. If you are designing crypto for your own application, and you find yourself typing "O-p-e-n-S-S-L" or even "A-E-S", you are probably in for a lot of trouble.
      - 14y ago

Ok, I'll bite. Why would it be more secure? Would the following block cipher be more secure than AES? function encrypt(block, key) { return block XOR key; }

tptacek 14y ago

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.

X-Istence 14y ago
How would this change for example if instead of using just plain AES you use AES with a block cipher mode (CTR-BE/CBC/or others just no CBE)?
- tptacek 14y ago
  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.
  - X-Istence 14y ago
    Excuse the typo, had just woken up.
blazingice 14y ago
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?
- tptacek 14y ago
  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.

brohee 14y ago

Actually, depending on the mode of operation it may be about as secure as AES in ECB... That's it, not secure at all. Using a well known algorithm is such a small part of the overall security of a cryptosystem that it makes the call to use only well known algorithms useless by itself. Hence tptacek recommending using proven high level libraries (e.g. OpenSSL's EVP_* family of functions).

tptacek 14y ago
Whoah. Hold on. OpenSSL EVPxxx claims to be a "high-level interface", but isn't one. Here's some acid tests for high-level libraries: * Does the library expose block cipher mode choices to callers? It's not high-level. * Does the library expose IVs to callers? It's not high-level. * Does the library separate "encryption" from "authentication", offering the choice of doing one without the other? It's not high level. * Does the library by default allow users to pass in raw buffers as keys? It's not high level. Don't use OpenSSL directly to do crypto in applications.
- brohee 14y ago
  I get your point, but pretty often you must respect some general mandate (e.g. must use this approved chaining mode, this certified PRNG...) and OpenSSL EVP comes very handy if you don't find a library doing exactly what you need. It still shields you quite a bit from the lower level mistakes to be made. What's your go to solution?
  - tptacek 14y ago
    Keyczar. For the situation you describe, a "low-level" crypto library is handy; for instance, very few libraries implement ciphertext stealing, so if you require compatibility with some wacky protocol or file format that uses CTS, OpenSSL EVP is no help either. That doesn't make OpenSSL's primitive interface a good choice. If you are designing crypto for your own application, and you find yourself typing "O-p-e-n-S-S-L" or even "A-E-S", you are probably in for a lot of trouble.
    - 14y ago