[607] in cryptography@c2.net mail archive
Re: The unmentionable algorithm
daemon@ATHENA.MIT.EDU (Steven Bellovin)
Mon Apr 21 13:33:02 1997
To: jamesd@echeque.com
cc: coderpunks@toad.com, cryptography@c2.net
Date: Sun, 20 Apr 1997 08:16:17 -0400
From: Steven Bellovin <smb@research.att.com>
At 11:24 PM 4/19/97 -0400, Steven Bellovin wrote:
> > Similarly, if used by itself there's no
> > standard way to take advantage of an IV to disguise common p
refixes.
>
> Huh? Rephrase.
>
> If you use a block cipher (such as DES) in CBC mode with a different
> IV for each message, then the resulting ciphertext will be different
,
> even if the plaintext is identical. This is because each block of
> ciphertext depends on both the current block of plaintext and the
> previous block of ciphertext. That propagate back to ``block 0'' of
> ciphertext -- the IV.
What has this got to do with the price of eggs?
I am well aware of what a CBC mode is, but I see no connection to
"failure to disguise common prefixes".
It is possible that what you actually meant to say, were you speaking
in plain english, is that if someone uses the same RC4 key twice,
they are screwed.
So what. Big deal. People do not use symmetric keys twice.
I'm not going to waste my time replying yet again to the rest of this thread.
But this point bears some clarification.
Keys are generally negotiated to protect *sessions*. A session can be
more than one message, in which case the encryption (often) starts anew for
each message. I'll give two concrete examples.
First, if you're using an encrypted file system (N.B. *not* an encrypted
disk, an encrypted file system, such as Matt Blaze's CFS), each file is
encrypted separately. Use of an IV with CBC mode disguises the fact
that two files are identical or have a common beginning. You can't do
that with a stream cipher. At most, you have a counter for how many times
you've ``turned the crank'' since key setup. Nor does it work to just
turn the crank a few times, and start each file from a different state
unless there's no overlap; you really don't want to reuse any part of the
key stream. That situation can be detected by use of the index of
coincidence, and it's often possible to recover plaintext in such
situations. (See the VENONA story for a concrete example...)
The second example is a messaging system, such as IPSEC -- you're sending
a number of independent messages in the session, each of which must be
protected. Because some messages can be lost (or retransmitted, or
received out of order), each one has to be encrypted independently.
This is easy with CBC mode. There are definitions for how to use RC4
in such a situation, but it's messier -- you have to include a counter
in each packet, and the receiver has to iterate the cipher backwards or
forwards to make the two counters match. If packets can be received
seriously out of order, or if you're dealing with a multipoint conversation
(say, a conference call), it's just much harder. Add in an enemy who
will send forged packets that have very different initial byte numbers,
just to make you work some more, and you can see the problem.
None of this bears on your main (albeit disputed) point, which is that
RC4 is stronger than DES. Everything here applies equally well to
DES in OFB mode. I'm simply pointing out that stream ciphers really
do have different properties than block ciphers, and substituting the
former for the latter doesn't always work. You need to rethink your
entire design.
I'll be happy to discuss the further offline, if anyone is still interested.
