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

[Uri Blumenthal <uri@xxxxxxxxxxxxxx>]

Adam Back says:
> > First - an observation. Just like a block cipher must have an IV (PGP
> > side-stepped this by prepending the message with random stuff), a
> > stram cipher must have a stream offset.
> 
> I presume by a stream offset you mean that you spin the stream cipher
> PRNG for the published offset number of bytes, before using it to
> encrypt data.

Yes, that hat is not my idea, not any more than using IV for block
ciphers - and for precisely the same purpose.

> This has a number of problems/added complexities I think:
> - you have to remember a current offest to avoid re-using offsets
>   (adds state to symmetric crypto where there is none currently)

Similarly to having to remember not to re-use IVs.

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

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

> > For the keys to have a stream offset can mean the difference between
> > secure and insecure.
> Another way to do things which avoids some of the problems with
> offsets is to have a random, or at least non-repeating IV, which is
> sent in the clear.  Then use the IV as part of the key.  eg.
> 
> rc4-key-shedule( iv || s2k( passphrase ) )

A possibility. Would need more time to evaluate it...

> ..... 
> Now you encrypt with rc4 session keys sk1 and sk2 for two separate
> messages m1 and m2, so the SKESK packets contain:
> 
>   skesk1 = rc4-encrypt( rc4key, sk1 ) = rc4out xor sk1
>   skesk2 = rc4-encrypt( rc4key, sk2 ) = rc4out xor sk2

Which is why there must be an offset.

> you can then recover sk1 xor sk2:

You might want to take a look at SEAL. It provides the offset VERY
elegantly. Unfortunately it's patented...

> Leaking of xors of sets of keys means that people can observe which
> keybits are the same on a set of messages.  This seems like a leak you
> would be better off without.

Oh, of course! (:-)
-- 
Regards,
Uri		uri@xxxxxxxxxxxxxx
-=-=-=-=-=-=-
<Disclaimer>