I\'m reading the SSL specs here. The interesting thing seems to be that RC4 is n
ID: 649020 • Letter: I
Question
I'm reading the SSL specs here.
The interesting thing seems to be that RC4 is not re-keyed with a new IV for each message. The stream cipher state is simply carried over to the next record. Why is this secure? Shouldn't messages be encrypted with different IVs? Honestly, this is one part I don't fully understand about IVs: each message needs a different IV, but what counts as a message? A full stream of records? One record?
The CBC modes do have different IVs for each block.
My question is, how about a stream ciphery mode of operation, like OFB or CTR? Do I need new IVs for each smallish record, or can I do what SSL does with RC4 and just carry over the cipher state? Is that in any way insecure? WEP seems to do the new-IV-per-packet thing, and that seems to have caused its downfall. Why?
Explanation / Answer
There is a number of ways how to generate the initialization vector (IV), and not all of them are secure for a particular mode of operation. The NIST recommendations are sometimes ambiguous and may lead to confusion. A comprehensive story of these issues has been recently told by Rogaway (see also excellent pictures there); let me summarize what should be said about CTR and OFB in the context of the IV generation (Sections 4.6, 4.7, 5.4).
First, by security I mean a rather strong model where the adversary selects a plaintext for the encryption and is then asked to tell apart a random string from the ciphertext. If the IV is random, it can not be chosen by the adversary; if it is a nonce, an adversary can choose it accordingly. If the probability of success is negligible up to huge amount of attempts with a fixed key, the mode is considered secure to chosen-plaintext attacks. This setting covers virtually all attacks that a good mode of operation that provides confidentiality (but not necessarily authenticity) should counteract.
Coming back to IVs, the OFB and CTR mode treat them differently even though they are somewhat stream-based. The IV in the OFB mode undergoes a number of encryptions; it can be easily proved secure if IV is random. However, a nonce-based OFB is generally insecure, as taking any previous ciphertext block as an IV destroys the security while being a good nonce (so the answer to one of your questions is definite "No"). A counter for the IV in OFB is fine and can be proved secure.
The CTR mode generates a keystream by encrypting an arithmetic progression starting with an IV. The best security is achieved when IV is selected such that no repetition in these values ever occurs; the NIST approach is good enough. A random IV is still fine, but not better; any previous ciphertext block should be fine and is likely to be secure, but it is unnecessary complication.