Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I was reading about Ruby ciphers and found this:
Although the key is generally a random value, too, it is a bad choice as an IV. There are elaborate ways how an attacker can take advantage of such an IV. As a general rule of thumb, exposing the key directly or indirectly should be avoided at all cost and exceptions only be made with good reason.
What does this mean?
First, a definition. An initialization vector or nonce (and these are in fact different things) are designed for one purpose, and that is to be a non-secret input to a symmetric cipher that allows it to retain semantic security by ensuring that the resulting ciphertext is indistinguishable from random when a given key is reused.
Remember, the only thing that must remain secret in an encryption scheme according to Kerckhoffs's Principal, is the key. However, if we don't want to generate a new secret key for every single encryption operation, we still need the same message, when encrypted twice, to result in entirely different ciphertexts, indistinguishable from random (what we call IND-CPA). If encrypting the same message twice results in the same ciphertext, well, we can clearly tell that it was in fact our message that was encrypted the second time, and not a randomly generated value. This is the property that the initialization vector gives us.
So, first, reusing the key as a the IV defeats the purpose of either a) being able to use the key, or b) providing IND-CPA. In the first option, we have to generate a new secret key for every encryption operation, track them so we can decyrpt, and keep them secret all the while, as Kerckhoffs's Principal says we must. In the second option, we begin leaking information. In a block mode cipher such as CBC, we leak whether two messages are the same, as illustrated above, or if two different messages begin with the same plaintext. In a streaming mode or stream cipher, the construction is broken catastrophically when a key/nonce combination is reused, allowing potentially complete recovery of the plaintext and keystream.
We resolve these issues by having a separate key and IV. The key we keep secret, the IV we MAC and can then transmit in the clear with the ciphertext with no loss of security.
One last point. In addition to their being a very good technical reason for the IV to be different from the key, what I think they were getting at in the comment you quoted was a more general principal that is fuzzier, but still widely held as good practice, and that is that keys should not be reused for different purposes. You wouldn't use the same key for both encryption and authentication functions, for instance. You might derive encryption and authentication keys from a single master key using a KDF, but you wouldn't typically want to use a single random key for both purposes. That, I think, is what they may actually be trying to say without having a terribly solid grasp on the specifics.
This is just at guess, but as it refers to the "key = cipher.random_key", a possibly leak of information from the random function used in generating the key could be implied. A rather strange property, but if the random seed for the IV and the key differs there might be a point.
