This paper introduces a chosen-plaintext vulnerability in the Secure Sockets Layer (SSL) and Trasport Layer Security (TLS) protocols which enables recovery of low entropy strings such as can be guessed from a likely set of 2--1000 options. SSL and TLS are widely used for securing communication over the Internet. When utilizing block ciphers for encryption, the SSL and TLS standards mandate the use of the cipher block chaining (CBC) mode of encryption which requires an initialization vector (IV) in order to encrypt. Although the first IV used by SSL is a (pseudo)random string which is generated and shared during the initial handshake phase, subsequent IVs used by SSL are chosen in a deterministic, predictable pattern; in particular, the IV of a message is taken to be the final ciphertext block of the immediately-preceding message, and is therefore known to the adversary. The one-

In this note, we present a comparison of the following CBC MAC variants: • RMAC by Jaulmes, Joux and Valette [9, 10, 5, 6], • EMAC from ISO 9797-1 [1, 13], • XCBC by Black and Rogaway [3, 4], • TMAC by Kurosawa and Iwata [12], and • OMAC by Iwata and Kurosawa [7]. We consider two RMACs. One is RMAC defined in NIST’s draft [5], which we write RMAC1, with parameter set IV or V, where AES is used as the underlying block cipher, and uses a nonce R. The other one is RMAC mode 2 stated in NIST’s consultation paper [6], which we write RMAC2, where AES128 is used to compute the CBC MAC tag, AES256 is used to encrypt it, and uses a nonce R. We write RMAC to mean both RMAC1 and RMAC2 1. 2

this paper [JJV], NIST did a lot of further, independent, design. They ended up with a kind of object that isn't even a conventional MAC, and isn't supported by any published scientific work. We don't think this is a right way to go. We recommend abandoning RMAC and choosing a more mature construction