This is right. There are cryptosystems on the market (eg "UBE98") that make this beginners mistake; all files are encrypted with exactly the same RC4 key, so you can gain information about them in exactly the way you describe.
The solution is to send a "nonce" (sometimes called an "initialisation vector" or "IV") in the clear along with each message, and use the nonce to vary the encryption; so long as you never use the same nonce twice, the scheme is secure. Some stream ciphers (eg LEVIATHAN, SEAL) are explicitly designed to take a nonce as a parameter when performing encryption.
For RC4, it was common practice to simply concatenate the secret key and the nonce to make the RC4 key. This is how WEP encryption works in 802.11 wireless Ethernet cards, and it was this aspect of WEP that Fluhrer, Mantin and Shamir attacked in their famous paper wholly destroying the security of that scheme with RC4. It's now recommended to use a secure hash function to generate the RC4 key from the key and nonce, thus:
where "|" represents concatenation and SHA is the Secure Hash Algorithm.
Incidentally, a nonce is required for security even with schemes that don't have this (A+X) - (B+X) = A-B property, such as using a block cipher in CBC or CFB mode. It's considered a flaw in a stream cipher if there's a way of deducing that the same plaintext has been encrypted twice, so there has to be a way of getting different ciphertexts from the same plaintext.
Incidentally incidentally, most modern interest is in block ciphers still. Stream ciphers of any kind still get far too little study.
Incidentally^3, RC4 is the simplest decent cipher in the world. If you're curious about the guts of how cryptosystems work, I recommend looking at how RC4 works, it's very neat.
no subject
Date: 2001-09-14 04:27 am (UTC)The solution is to send a "nonce" (sometimes called an "initialisation vector" or "IV") in the clear along with each message, and use the nonce to vary the encryption; so long as you never use the same nonce twice, the scheme is secure. Some stream ciphers (eg LEVIATHAN, SEAL) are explicitly designed to take a nonce as a parameter when performing encryption.
For RC4, it was common practice to simply concatenate the secret key and the nonce to make the RC4 key. This is how WEP encryption works in 802.11 wireless Ethernet cards, and it was this aspect of WEP that Fluhrer, Mantin and Shamir attacked in their famous paper wholly destroying the security of that scheme with RC4. It's now recommended to use a secure hash function to generate the RC4 key from the key and nonce, thus:
ciphertext = nonce | RC4(SHA(key | nonce)) XOR plaintext
where "|" represents concatenation and SHA is the Secure Hash Algorithm.
Incidentally, a nonce is required for security even with schemes that don't have this (A+X) - (B+X) = A-B property, such as using a block cipher in CBC or CFB mode. It's considered a flaw in a stream cipher if there's a way of deducing that the same plaintext has been encrypted twice, so there has to be a way of getting different ciphertexts from the same plaintext.
Incidentally incidentally, most modern interest is in block ciphers still. Stream ciphers of any kind still get far too little study.
Incidentally^3, RC4 is the simplest decent cipher in the world. If you're curious about the guts of how cryptosystems work, I recommend looking at how RC4 works, it's very neat.