5 ms·

Could you explain why "encrypt then MAC" is the right option please? It isn't obvious why the other two are broken. Luckily I don't work in crypto :)

• tptacek 14y ago
  It allows you to use MAC validation as a screen for incoming messages and so prevents attacks that depend on ciphertext manipulation.
• dchest 14y ago
  cperciva wrote a blog post about this: http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....
• forgotusername 14y ago
  If I'm not mistaken (and haven't read up on this stuff in years, so probably), the majority of encryption modes rely on XORing the stream of bits from the cipher with your plain text. In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters. Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.
  • tptacek 14y ago
    I'm not sure I totally follow this (you seem to be talking about an attack on CBC mode, but the mode you're describing sounds more like CTR mode), but a good rule of thumb is, without explicit authentication, attackers can alter and often rewrite messages even though all they can see is ciphertext. But there are even more problems than that with unauthenticated encryption. If you don't authenticate there is a good chance attackers will be able to decrypt your messages wholesale.
    • forgotusername 14y ago
      > decrypt your messages wholesale. Eek, that sounds fun :) Tell us more?
      • Nursie 14y ago
        If they can get your system to tell them if a message is valid somehow, perhaps by making thousands of attempts to pass a message and noting where it says 'login failed' or '404' instead of invalid message (for instance) then there are all sorts of things that can be done to recover messages and keys. I highly recommend Dan Boneh's crypto 101 on coursera for anyone that has the time.
      • tptacek 14y ago
        The CBC padding oracle is one such attack. There are a bunch of similar ones. They're "chosen ciphertext" attacks. Again, even if you get this part right, there are other things that go wrong. TLS is authenticated, and it fell to two adaptive chosen plaintext attacks because of two different implementation details they messed up. And no public cryptosystem in the world has been as thoroughly tested and analyzed as TLS.
        • pjscott 14y ago
          There's an entertaining article about one such attack here: http://blog.cryptographyengineering.com/2011/10/attack-of-week-xml-encryption.html http://blog.cryptographyengineering.com/2011/10/attack-of-we... For some mind-boggling reason, the designers of the XML Encryption standard decided to make authentication optional, so an attacker can simply avoid sending an incorrect MAC.
• agwa 14y ago
  Moxie Marlinspike wrote a great blog post about this: http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...
• cdjk 14y ago
  Short answer - it lets you verify the data before decrypting so you can reject invalid data earlier.
• femto113 14y ago
  Missing from this blog post, but made clear here (http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html http://blog.cryptographyengineering.com/2012/05/how-to-choos...) is that you need to USE TWO DIFFERENT KEYS, one for the cipher, the other for the MAC. This makes it practically impossible to forge a valid message, since even if someone forged an apparently valid cipher section they'd be unable generate the corresponding MAC (unless they already had your keys, in which case you're already toast).
  • marshray 14y ago
    Using two different keys is considered good practice, but I don't think it helps as much as you seem to think it does.
    • tptacek 14y ago
      Not to mention: if you're doing it right, you really don't have to think about whether you have two keys; you just naturally kind of do. It's the systems where you consciously have to handle two different keys that you have to worry about, because they're probably not keying themselves safely to begin with.
• sweis 14y ago
  Here's a slide deck by Bellare talking about some of the differences between encrypt-and-MAC, MAC-then-encrypt, and encrypt-then-MAC: http://cseweb.ucsd.edu/~mihir/cse207/s-ae.pdf http://cseweb.ucsd.edu/~mihir/cse207/s-ae.pdf
• marshray 14y ago
  The simplest way to think about it is during the receiving process: checking the MAC before decrypting catches and rejects evil messages earlier so there are fewer things that can (and will) go wrong. Even if you tell the world that the message wasn't invalid, you don't reveal any new information to the attacker. OTOH, if the receiver must decrypt before checking the MAC, any information leaked to the attacker (success or failure, timing, etc) is very likely to give the attacker a systematic method to decrypt some or all of your secret plaintext.