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

Re: CBC makes Implementations too Slow.

Is there an rfc or paper that discuss the proper uses of IV w/ different modes?


At 09:50 AM 11/30/2001 -0500, Derek Atkins wrote:
>The problem with this "mode" is that your plaintext/ciphertext has no
>relation to your IV.  It means there really is no chaining going on,
>except via 'F' which may or may not provide as much security as 'S'.
>Moreover, the IV chaining you propose depends on neither P nor K,
>which some may consider a bug.
>
>-derek
>
>"mahdavi" <mahdavi110@yahoo.com> writes:
>
> > 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
> >
>
>--
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
Follow-Ups: References: