Adding TLS 1.2 Support to Your TLS Library - Implementing SSL/TLS Using Cryptography and PKI - page 493

and encrypting it again, XORing each such encrypted block with the ciphertext
recovers the plaintext. In fact, if you try to use aes_decrypt here, you end up
getting the wrong answer.
Nonce selection is crucial with CTR mode, though. You can never, ever reuse a
nonce with the same key. In CBC mode, reusing an initialization vector was sort
of bad. With CTR mode, it's catastrophic. Consider the CTR-mode encryption
of the ASCII string “Hello, World!!” ( 0x68656c6c6f20776f726c642121 ) with the
key 0x404142434445464748494a4b4c4d4e4f and a nonce of 0x10111213141516 .
This encrypts, in CTR mode, to 0xfb35f1556ac63f6f226935cd57 . So far, so
good; an attacker can't determine anything about the plaintext from the
ciphertext.
Later, though, you encrypt the plaintext “Known Plaintxt”
( 0x4b6e6f776e20506c616e747874 ), which the attacker knows. Using the
same key and the same nonce (starting from counter 0), this encrypts to
0xd83ef24e6bc6186c316b259402 . Unfortunately, if the attacker now XOR's the
fi rst cipher text block with the second, and then XOR's this with the known
input, he recovers p1. This attack is illustrated in Table 9-1. This vulnerability
has nothing to do with the strength of the cipher or the choice of the key; it's
a fi xed property of CTR mode itself. As long as you keep incrementing the
counter, you're safe. As soon as the counter is reset (or wraps) back to 0, you
must change the nonce.

Table 9-1: Recovering unknown plaintext from known plaintext when a nonce is reused

PURPOSE VALUE

cipher text block 2 (c1) 0xfb35f1556ac63f6f226935cd57

cipher text block 1 (c2) 0xd83ef24e6bc6186c316b259402

c1 ≈ c2 0x230b031b010027031302105955

plain text 2 (p2) 0x4b6e6f776e20506c616e747874

p2 ≈ c1 ≈ c2 0x68656c6c6f20776f726c642121

As usual, the implementation presented by this topic completely disregards
this critical security advice and reuses the same hardcoded nonce over and
over again for the sake of illustration. However, at least you can get around this
security hole by making sure never to reuse a nonce. There's another problem
with CTR mode that you can't solve, at least not within CTR mode.
Consider the plaintext 0xAB and the CTR-mode key stream byte 0x34 . XORed
together, they become the cipher text 0xB2 . So far, so good; the attacker can't
recover the plaintext 0xAB without the keystream byte 0x34 and can't learn
anything about the plaintext from the ciphertext. But say that the attacker does