[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CBC makes Implementations too Slow.
At 07:53 AM 11/29/01 , Dilkie, Lee wrote:
>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.
I disagree. If you use a counter, and the initial blocks of two packets differ in precisely the same bits as the two counters do, the same plaintext will be given to the underlying block cipher, and produce the exact same ciphertext. I would claim that this potential leak is too serious to permit using a counter.
In fact, the suggestion to reuse a previous ciphertext block as an IV can be insufficient, and we really should require implementations to use random IVs.
>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).
Apart from the silliness of the argument "that protocol over there does it, hence it must be secure", may I point out that draft-ieft-avt-srtp-01 uses counter mode (or another "seekable additive stream cipher"), not CBC.
>
>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
>>
>
References: