5 ms·

Encrypt your content with AES-128 with a random (from /dev/random) key; write the key down as 32 hexadecimal digits. Nobody is going to break it, ever. There a

Encrypt your content with AES-128 with a random (from /dev/random) key; write the key down as 32 hexadecimal digits. Nobody is going to break it, ever. There are caveats. Don't reuse your key, because if an attacker can trigger your AES encryption on demand, and you're reusing the same key, then the attacker can break your encryption after alarmingly few operations. https://dl.dropboxusercontent.com/u/315/articles/Cache%20Attacks%20and%20Countermeasures%20-%20the%20Case%20of%20AES%20%5BShamir%2C%202005%5D.pdf https://dl.dropboxusercontent.com/u/315/articles/Cache%20Att... (That's a different situation than "write down the key," but we're throwing around ideas in this thread, so I just wanted to make sure everyone knows not to write software that can be triggered on-demand to AES encrypt some content with an unchanging key. I could imagine someone being tempted to write a chat program like that, and an attacker will rip its security to shreds using sidechannel attacks.)

tptacek 13y ago
That's not actually what that paper says. It says that if your AES implementation relies on secret-derived table lookups and your attacker shares a machine with you, they can write a spy process that will profile the local cache and from that trace data infer the table lookups you did. It's a great (and famous) paper, but it does not suggest that reusing an AES key is dangerous, because of course it isn't. The guy talking about using USB one-time pads is not in a good position to be concerned about mitigating localhost attackers.
- sillysaurus2 13y ago
  I'm trying to figure out how my understanding of the paper went so horribly awry, but I'm just not seeing it. From the paper: The first family of attacks, termed synchronous attacks, is applicable in scenarios where the plaintext or ciphertext is known and the attacker can operate synchronously with the encryption on the same processor, by using (or eavesdropping upon) some interface that triggers encryption under an unknown key. For example, a Virtual Private Network may allow an unprivileged user to send data packets through a secure channel. This lets the user trigger encryption of plaintexts that are mostly known (up to some uncertainties in the packet headers), and our attack would thus, under some circumstances, enable any such user to discover the key used by the VPN to protect all users’ packets. As another example, consider the Linux dm-crypt and cryptoloop services. These allow the administrator to create a virtual device which provides encrypted storage into an underlying physical device, and typically a normal filesystem is mounted on top of the virtual device. If a user has write permissions to any file on that filesystem, he can use it to trigger encryptions of known plaintext, and using our attack he is subsequently able to discover the encryption key used for the underlying device. We have experimentally demonstrated the latter attack, and showed it to reliably extract the full AES key using about 65ms of measurements (involving just 800 write operations) followed by 3 seconds of analysis. Questions: 1) In that example, the attacker "discovered the key used by the VPN to protect all users' packets." Does that mean the VPN reused the same AES key for each encryption? 2) If so, then if the VPN were to change the encryption key each time it encrypted a packet, wouldn't that protect against this attack? The attacker had to be able to trigger 800 encryptions that all used the same encryption key, right? Or does "write operation" refer to something other than "the attacker triggered an encryption of some known plaintext"?
  - tptacek 13y ago
    The problem Osvik and Tromer are pointing out isn't that the VPN doesn't rekey; it's that the AES implementation it uses can't prevent a localhost attacker from learning its secrets by watching the footprints it leaves in the cache. There is no reasonable solution to that problem that doesn't involve eliminating the side channel. The problem isn't the key management; it's the broken AES deployment.
    - sillysaurus2 13y ago
      What I think you're saying is, "the paper's point is that side channel attacks can be used to determine the key." I understand that... that's the whole point of the paper, after all. But wouldn't rekeying defend against this attack? And therefore how is what I originally said wrong (and hence how is it safe practice to reuse AES keys in general)? (I'm only trying to understand this.)
      - ghshephard 13y ago
        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.
        sillysaurus2 13y ago
        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.

tptacek 13y ago

That's not actually what that paper says. It says that if your AES implementation relies on secret-derived table lookups and your attacker shares a machine with you, they can write a spy process that will profile the local cache and from that trace data infer the table lookups you did. It's a great (and famous) paper, but it does not suggest that reusing an AES key is dangerous, because of course it isn't. The guy talking about using USB one-time pads is not in a good position to be concerned about mitigating localhost attackers.

sillysaurus2 13y ago
I'm trying to figure out how my understanding of the paper went so horribly awry, but I'm just not seeing it. From the paper: The first family of attacks, termed synchronous attacks, is applicable in scenarios where the plaintext or ciphertext is known and the attacker can operate synchronously with the encryption on the same processor, by using (or eavesdropping upon) some interface that triggers encryption under an unknown key. For example, a Virtual Private Network may allow an unprivileged user to send data packets through a secure channel. This lets the user trigger encryption of plaintexts that are mostly known (up to some uncertainties in the packet headers), and our attack would thus, under some circumstances, enable any such user to discover the key used by the VPN to protect all users’ packets. As another example, consider the Linux dm-crypt and cryptoloop services. These allow the administrator to create a virtual device which provides encrypted storage into an underlying physical device, and typically a normal filesystem is mounted on top of the virtual device. If a user has write permissions to any file on that filesystem, he can use it to trigger encryptions of known plaintext, and using our attack he is subsequently able to discover the encryption key used for the underlying device. We have experimentally demonstrated the latter attack, and showed it to reliably extract the full AES key using about 65ms of measurements (involving just 800 write operations) followed by 3 seconds of analysis. Questions: 1) In that example, the attacker "discovered the key used by the VPN to protect all users' packets." Does that mean the VPN reused the same AES key for each encryption? 2) If so, then if the VPN were to change the encryption key each time it encrypted a packet, wouldn't that protect against this attack? The attacker had to be able to trigger 800 encryptions that all used the same encryption key, right? Or does "write operation" refer to something other than "the attacker triggered an encryption of some known plaintext"?
- tptacek 13y ago
  The problem Osvik and Tromer are pointing out isn't that the VPN doesn't rekey; it's that the AES implementation it uses can't prevent a localhost attacker from learning its secrets by watching the footprints it leaves in the cache. There is no reasonable solution to that problem that doesn't involve eliminating the side channel. The problem isn't the key management; it's the broken AES deployment.
  - sillysaurus2 13y ago
    What I think you're saying is, "the paper's point is that side channel attacks can be used to determine the key." I understand that... that's the whole point of the paper, after all. But wouldn't rekeying defend against this attack? And therefore how is what I originally said wrong (and hence how is it safe practice to reuse AES keys in general)? (I'm only trying to understand this.)
    - ghshephard 13y ago
      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.
      - sillysaurus2 13y ago
        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.