ietf-openpgp
[Top] [All Lists]

Re: stream ciphers (Re: 128 bit block ciphers)

1998-07-01 15:10:34

Paul Koning writes;
 >> - you incur the performance penalty of spinning the PRNG by the
 >> offset number of bytes (eg could be 100s of megs).

 Uri> Possibly, but again, I'm not "inventing" it - just sharing the
 Uri> crypto rules of using stream ciphers with the list. "Don't blame
 Uri> the messenger" (:-)

Hm.  That sounds like practical stream cyphers will always be insecure 
(to the extent that an unknown stream offset has a significant
security benefit).

the stream offset doesn't have to be unknown, it just has to be chosen
so that no PRNG output byte used more than once.  (ie just start at 0,
and keep incrementing.)

The reason for the offset is that RC4 (and other stream ciphers) work
by xoring the output of a pseudo random number generator with the
plaintext.  The seed of the PRNG is the stream ciphers key.

So, if we take RC4, and call the PRNG output for byte i and key k
rc4-prng(k,i), you encrypt like this:

ciphertext[i] = plaintext[i] xor rc4-prng(k,i)

So if you use the same key (k), and you still start i at 0, you end up
with leaking the two plaintexts xored together.  

c1 = p1 xor prng, c2 = p2 xor prng => p1 xor p2 = c1 xor c2

leaking two plaintexts xored together is close to leaking the
plaintext outright.

So you just make sure never to reuse bytes from the prng output, ie
first message size 1000 bytes, start with prng output byte 0, and use
up to output byte 999, next message of 1000 bytes start at 1000, use
up to output byte 1999.

An IV can (and should be) random -- all bits unpredictable.  

That is safe, but for some block-cipher modes a stronger requirement
than strictly necessary.  CFB, and CBC only require unique IVs (not
random ones), so an incrementing variable or timestamp would be
enough.  The stream offset also doesn't need to be random.

Adam