[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CBC makes Implementations too Slow.
Michael Cyr wrote:
>
> On Tue, 30 Oct 2001, Steven M. Bellovin wrote:
>
> > CBC mode requires
> > feedback, which makes it impossible to pipeline encryptions; you can't
> > encrypt plaintext block P[n+1] until you have the ciphertext from
> > encrypting P[n].
>
> I know this discussion was a while ago, but I have a question related to
> the problem. First, let me say that I'm new to the list, and still
> somewhat new to IPsec in general, so I hope you'll forgive any ignorance
> on my part.
>
> Would it be a complete violation of the protocol to use random data for
> the IV data instead of a portion of the ciphertext of the previous
> block? I know this violates the spirit of cipher block _chaining_, but
> it would seem to address the concern that CBC was meant to fix, which is
> to ensure that if the same cleartext is encrypted twice, it doesn't
> produce the same ciphertext. Anyone have a definitive answer on this?
Yes. There can be many cipher blocks in a single packet. The IV is xored
with the first plaintext block in the packet and encrypted to produce
the first cipher block, which in turn is xored with the second plaintext
block and encrypted to produce second ciphertext block, and so on. The
packet's IV can be random or can be carried over from a previous packet.
Using a random IV for each cipher block instead of each packet would
double the size of the packet.
There is nothing to stop you from encrypting multiple packets, each with
its own IV, simultaneously. This does nothing to address the latency
that a single packet experiences, which is (roughly) the latency to
encrypt a single block times the number of blocks in the packet.
References: