[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CBC makes Implementations too Slow.

I'm not sure if using a packet counter for an IV is bad. It's just that you can't wrap. It's important that the same key/IV combination not get reused. I don't believe that the requirement for a random IV is necessary. The reason I point this out is that the secure RTP spec <draft-ieft-avt-srtp-01.txt> uses an implicit IV (to save on transmitting extra data) which is based on information in the RTP header (and really is just a packet counter under the covers).

Lee Dilkie

Mitel Networks
350 Legget Drive
Kanata, ON, Canada
K2K 2W7

Phone: 1-613-592-5660

"It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day."
     - Homer Simpson (from "The Simpsons")


> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, November 29, 2001 9:37 AM
> To: mikecyr@austin.ibm.com
> Cc: ipsec@lists.tislabs.com
> Subject: 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: