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(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>