[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CBC makes Implementations too Slow.
>>>>> "Michael" == Michael Cyr <mikecyr@austin.ibm.com> writes:
Michael> 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].
Michael> I know this discussion was a while ago, but I have a
Michael> question related to the problem. First, let me say that I'm
Michael> new to the list, and still somewhat new to IPsec in general,
Michael> so I hope you'll forgive any ignorance on my part.
Michael> Would it be a complete violation of the protocol to use
Michael> random data for the IV data instead of a portion of the
Michael> ciphertext of the previous block? I know this violates the
Michael> spirit of cipher block _chaining_, but it would seem to
Michael> address the concern that CBC was meant to fix, which is to
Michael> ensure that if the same cleartext is encrypted twice, it
Michael> doesn't produce the same ciphertext. Anyone have a
Michael> definitive answer on this?
My reading of the spec is that this is perfectly legal. The one thing
you're not supposed to do is to use a low entropy IV value, such as a
packet counter.
That doesn't fix the performance problem for a single packet, though.
You can do each packet independently if you use a random IV, but each
plaintext block *within* the packet is still dependent on the previous
block.
On the other hand, using independent IVs per packet provides a useful
gain if you have a number of packets pending (for the same SA) -- you
can then encrypt them in parallel. In high load cases you will almost
certainly have multiple packets waiting to be processed, so this
should indeed give you a significant performance gain.
paul
Follow-Ups:
References: