3 ms·

That is so sick. (in an awesome way) It's like evolution in action. The defensive crypto guy's carapace has been pierced by the hacker's slow methodical lever

by pj 17y ago

That is so sick. (in an awesome way) It's like evolution in action. The defensive crypto guy's carapace has been pierced by the hacker's slow methodical leverage.

tptacek 17y ago
You want sick? Here's sick. An AES block is 16 bytes long. You want to encrypt the lyrics to "Yellow Submarine". You can't just repeat AES for each 16 byte block, because then you can tell where the words "yellow submarine" --- 1 AES block --- occur: they'll encrypt to the same block. So you use CBC mode, XOR'ing each plaintext block to the previous ciphertext block, creating a unique ciphertext every time you encrypt those lyrics. But "Yellow Submarine" is 902 characters long; the last block is 6 bytes short. So you pad the message which a count of the pad characters --- 06h 06h 06h 06h 06h 06h. With me so far? Decrypt the message. Check the padding: it should repeat as many times as the value of the last byte. If not, you decrypted badly. Send an error to that effect. Hey guess what! I can decrypt parts of your message! If I stick a random AES block in your message, it will scramble the padded block. Every once in awhile, that scrambled message will end in 01h. 01h is valid padding. The message will be gibberish, but you at least won't tell me it had bad padding. You wouldn't tell me if you decrypted to bad padding if I generated 02h 02h either. But that's much less likely than 01h. Now I know that your plaintext XOR my random block produces a last byte of 01h. Solve. Now my point: this is actually way old news --- back to Bleichenbacher and Vaudenay and probably before that (I'm not the resident expert) --- but attacks like this have broken peer-reviewed versions of TLS, the most peer-reviewed crypto protocol ever designed. Don't build crypto.
- NateLawson 17y ago
  This attack was found by Bodo Moeller in OpenSSL. I posted about this here, including a link to the slides: http://rdist.root.org/2008/01/25/tlsssl-mac-security-flaw/ http://rdist.root.org/2008/01/25/tlsssl-mac-security-flaw/
  - DamienMiller 17y ago
    ... and by Bellare, Kohno, and Namprempre for SSH: http://www.cs.washington.edu/homes/yoshi/papers/SSH/ http://www.cs.washington.edu/homes/yoshi/papers/SSH/

by pj 17y ago

That is so sick. (in an awesome way) It's like evolution in action. The defensive crypto guy's carapace has been pierced by the hacker's slow methodical leverage.

tptacek 17y ago

You want sick? Here's sick. An AES block is 16 bytes long. You want to encrypt the lyrics to "Yellow Submarine". You can't just repeat AES for each 16 byte block, because then you can tell where the words "yellow submarine" --- 1 AES block --- occur: they'll encrypt to the same block. So you use CBC mode, XOR'ing each plaintext block to the previous ciphertext block, creating a unique ciphertext every time you encrypt those lyrics. But "Yellow Submarine" is 902 characters long; the last block is 6 bytes short. So you pad the message which a count of the pad characters --- 06h 06h 06h 06h 06h 06h. With me so far? Decrypt the message. Check the padding: it should repeat as many times as the value of the last byte. If not, you decrypted badly. Send an error to that effect. Hey guess what! I can decrypt parts of your message! If I stick a random AES block in your message, it will scramble the padded block. Every once in awhile, that scrambled message will end in 01h. 01h is valid padding. The message will be gibberish, but you at least won't tell me it had bad padding. You wouldn't tell me if you decrypted to bad padding if I generated 02h 02h either. But that's much less likely than 01h. Now I know that your plaintext XOR my random block produces a last byte of 01h. Solve. Now my point: this is actually way old news --- back to Bleichenbacher and Vaudenay and probably before that (I'm not the resident expert) --- but attacks like this have broken peer-reviewed versions of TLS, the most peer-reviewed crypto protocol ever designed. Don't build crypto.

NateLawson 17y ago
This attack was found by Bodo Moeller in OpenSSL. I posted about this here, including a link to the slides: http://rdist.root.org/2008/01/25/tlsssl-mac-security-flaw/ http://rdist.root.org/2008/01/25/tlsssl-mac-security-flaw/
- DamienMiller 17y ago
  ... and by Bellare, Kohno, and Namprempre for SSH: http://www.cs.washington.edu/homes/yoshi/papers/SSH/ http://www.cs.washington.edu/homes/yoshi/papers/SSH/