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

Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt



AES decryption isn't all that different from encryption; the algorithm
has only a minor difference and the rest is in tables.  Shouldn't
really make any noticeable difference in code size or development time.

Hilarie

In due time, on Tue, 27 Aug 2002 at 16:56:59 -0400 Housley, Russ
asserted:

>  Steve:

>  I disagree.  AES-CTR only uses the AES encrypt operation for both packet 
>  encryption and decryption.  Since AES encrypt and AES decrypt are quite 
>  different, unlike DES where they were nearly identical, there can be a 
>  considerable savings in code size and development time for AES-CTR since 
>  AES-CBC used both AES encrypt and decrypt operations.

>  Russ

>  At 08:40 AM 8/26/2002 -0400, Stephen Kent wrote:
>  >At 3:23 PM -0400 8/24/02, Michael Richardson wrote:
>  >>-----BEGIN PGP SIGNED MESSAGE-----
>  >>
>  >>
>  >>>>>>>  "Alex" == Alex Alten <Alten@attbi.com> writes:
>  >>     >> Anyone who *needs* AES-CTR mode, likely needs it because they have
>  >>     >> >1Gb/s links they want to secure. As such, I think that they have the
>  >>     >> bandwidth not to care.
>  >>
>  >>     Alex> Micahael,
>  >>
>  >>     Alex> Are you implying that AES-CTR on a modern Intel CPU can handle 
>  >> more
>  >>     Alex> than 1 Gb/s Ethernet?  Is this because the IV stays in L1 cache?
>  >>
>  >>   I'm not making any claim about hardware or software implementations.
>  >>My understanding is that AES-CTR mode is implemented more cheaply
>  >>than AES-CBC mode. Whether this is hardware or software is simply a question
>  >>of what year it is.
>  >
>  >I don't think we can say that CTR mode is easier to implement in software 
>  >than CBC mode. CTR mode probably isn't any faster than CBC, in general, in 
>  >software, since software can't generally take advantage of the pipelining 
>  >or parallelism.
>  >
>  >Steve