Skip to main content
Cryptography

Return to Answer

replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 1

AES-CBC as implemented in TLS 1.2 is susceptible to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.

AES-CBC as implemented in TLS 1.2 is susceptible to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.

AES-CBC as implemented in TLS 1.2 is susceptible to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.

Source Link
mti2935
mti2935
  • 959
  • 8
  • 9

AES-CBC as implemented in TLS 1.2 is susceptible to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.