5 ms·

Then what does "800 write operations" refer to, if not 800 encryptions? How can a side channel be used to break a single encryption? Also, how would a one time

Then what does "800 write operations" refer to, if not 800 encryptions? How can a side channel be used to break a single encryption? Also, how would a one time pad be vulnerable to any side channel attack? That seems like it makes no sense. What am I missing here?

ghshephard 13y ago
http://en.wikipedia.org/wiki/Side_channel_attack http://en.wikipedia.org/wiki/Side_channel_attack does a really good job Of describing it, but, in short, a side channel attack isn't a weakness in the algorithm - both a OTP and AES are strong. Rather, the side channel attack describes information leaked in a particular implementation. If your OTP implementation left some registers or cache lines in a state from which key information could be gleaned, then the attacker would be able to decrypt your message. Side channel attacks are about weaknesses in implementations, not algorithms.
- sillysaurus2 13y ago
  Yes, but it makes no sense that a one time pad would leak key information via cache timing, because the entire operation is just 'message xor key'." With a one time pad, the key's length has to be the length of the plaintext. There's no way for the key to be leaked through cache timing, because no memory location is ever read twice. The entire operation is simply: read a byte of plaintext; read a byte of key; XOR the two, writing the resulting byte" It makes no sense to use cache timing attacks against one time pads, because the speed of memory access is independent of the key and plaintext! If you have a side channel attack then a single use of the key would be sufficient to break it-even a OTP would be vulnerable. Let me try to put it another way: as far as I know, there are no reasonable side channel attacks against one time pad encryption, and certainly no cache timing attacks. So I don't understand why you're saying OTP is vulnerable to side channel attacks. Also, how is it possible for a single use of the key to be vulnerable to a timing-based side channel attack? If I'm wrong, please point out precisely what I've said that's wrong, so that I can learn from my mistake. I'll reword my original questions for clarity: does "800 write operations" mean "the attacker initiated 800 separate encryption operations, each using the same encryption key X, then analyzed the cache timing in order to infer X"? If so, doesn't that mean this attack can be defended against by changing the AES key for each encryption operation? And if that's correct, then by definition isn't it less safe (if not unsafe) to reuse your AES key?
  - tptacek 13y ago
    There was a paper just published that built on Osvik & Tromer that recovered a GPG RSA key from a single run of GPG. This problem has nothing to do with key reuse.
    - sillysaurus2 13y ago
      I think this is the paper you're referring to: http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf The only reason they were able to recover the key in a single run is because GPG uses branching in its inner loop, making it trivial to determine the difference in timing between 1 and 0 bits of the key. AES requires no such branching. Attacking AES requires that the attacker try to predict the key, then calculate how long encryption would take if the attacker's guess was correct, then compare that guess to how long it actually took. This means it's not possible to recover the AES key in a single run unless the attacker happened to guess it correctly the first time (which is effectively impossible). In other words, the paper you cited apparently doesn't build off of Osvik & Tromer at all, except in the sense that they're both cache timing attacks. The paper uses a completely different technique than Osvik & Tromer. So how is it safe to reuse your AES key? I'm just trying to understand. Since the attacker needs multiple runs to attack AES, then wouldn't the logical defense be to rekey after every encryption? It seems like you've been saying "it's impossible to defend against a side channel attack." But that doesn't seem to be true in the case of AES, as long as you don't reuse your key. What am I missing?
      - tptacek 13y ago
        No, that's not what I'm saying. I'm saying that the solution to side channel attacks is to eliminate the side channel, not to redesign the cryptosystem around it. I keep telling you this: you can reuse AES keys. Reusing an AES key does not in any intrinsic way reduce the security of AES (at least, not unless you encrypt a truly staggering amount of data with it). However: you should not be working with encryption at this level of detail anyways. Sillysaurus 2, please go download Nacl and play with it. You'll be using 2012 crypto instead of debating implementation flaws in old crypto.

ghshephard 13y ago

http://en.wikipedia.org/wiki/Side_channel_attack http://en.wikipedia.org/wiki/Side_channel_attack does a really good job Of describing it, but, in short, a side channel attack isn't a weakness in the algorithm - both a OTP and AES are strong. Rather, the side channel attack describes information leaked in a particular implementation. If your OTP implementation left some registers or cache lines in a state from which key information could be gleaned, then the attacker would be able to decrypt your message. Side channel attacks are about weaknesses in implementations, not algorithms.

sillysaurus2 13y ago
Yes, but it makes no sense that a one time pad would leak key information via cache timing, because the entire operation is just 'message xor key'." With a one time pad, the key's length has to be the length of the plaintext. There's no way for the key to be leaked through cache timing, because no memory location is ever read twice. The entire operation is simply: read a byte of plaintext; read a byte of key; XOR the two, writing the resulting byte" It makes no sense to use cache timing attacks against one time pads, because the speed of memory access is independent of the key and plaintext! If you have a side channel attack then a single use of the key would be sufficient to break it-even a OTP would be vulnerable. Let me try to put it another way: as far as I know, there are no reasonable side channel attacks against one time pad encryption, and certainly no cache timing attacks. So I don't understand why you're saying OTP is vulnerable to side channel attacks. Also, how is it possible for a single use of the key to be vulnerable to a timing-based side channel attack? If I'm wrong, please point out precisely what I've said that's wrong, so that I can learn from my mistake. I'll reword my original questions for clarity: does "800 write operations" mean "the attacker initiated 800 separate encryption operations, each using the same encryption key X, then analyzed the cache timing in order to infer X"? If so, doesn't that mean this attack can be defended against by changing the AES key for each encryption operation? And if that's correct, then by definition isn't it less safe (if not unsafe) to reuse your AES key?
- tptacek 13y ago
  There was a paper just published that built on Osvik & Tromer that recovered a GPG RSA key from a single run of GPG. This problem has nothing to do with key reuse.
  - sillysaurus2 13y ago
    I think this is the paper you're referring to: http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf The only reason they were able to recover the key in a single run is because GPG uses branching in its inner loop, making it trivial to determine the difference in timing between 1 and 0 bits of the key. AES requires no such branching. Attacking AES requires that the attacker try to predict the key, then calculate how long encryption would take if the attacker's guess was correct, then compare that guess to how long it actually took. This means it's not possible to recover the AES key in a single run unless the attacker happened to guess it correctly the first time (which is effectively impossible). In other words, the paper you cited apparently doesn't build off of Osvik & Tromer at all, except in the sense that they're both cache timing attacks. The paper uses a completely different technique than Osvik & Tromer. So how is it safe to reuse your AES key? I'm just trying to understand. Since the attacker needs multiple runs to attack AES, then wouldn't the logical defense be to rekey after every encryption? It seems like you've been saying "it's impossible to defend against a side channel attack." But that doesn't seem to be true in the case of AES, as long as you don't reuse your key. What am I missing?
    - tptacek 13y ago
      No, that's not what I'm saying. I'm saying that the solution to side channel attacks is to eliminate the side channel, not to redesign the cryptosystem around it. I keep telling you this: you can reuse AES keys. Reusing an AES key does not in any intrinsic way reduce the security of AES (at least, not unless you encrypt a truly staggering amount of data with it). However: you should not be working with encryption at this level of detail anyways. Sillysaurus 2, please go download Nacl and play with it. You'll be using 2012 crypto instead of debating implementation flaws in old crypto.