[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CBC makes Implementations too Slow.
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: