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

Re: CBC makes Implementations too Slow.

Hi.
And other way to encrease speed and also not to loose security and also not
to pay for Overhead is to generate a random number for IV to use with first
block and generate other IVs for other Blocks based on this IV and number of
block.

I mean this.

(P satnds for Plain block, C stands for Ciphered Block, F is a function, S
is Security function.)


IV ( 0 ) = a random number; C ( 0 ) = S ( P(0) , IV ( 0 ) ) ; // may be S
 P (0) XOR IV ( 0 )

for i from 0 till end of Block
    IV ( i ) = F ( IV ( i - 1 ) ) ;  C ( i ) = S ( P ( i ) , IV ( i ) ) ; //
may be S ( P (0) XOR IV ( 0 )


If F be a right function that is known with both end node and be simple that
can be generated as fast we will gain all option that I mentioned.

In this way a very Efficient pipeline can be made.



----- Original Message -----
From: "Paul Koning" <ni1d@arrl.net>
To: <mikecyr@austin.ibm.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, November 29, 2001 6:07 PM
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



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Follow-Ups: References: