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

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



At 5:06 PM +0300 8/26/02, Arne Ansper wrote:
>  > 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.
>
>yes it can.
>
>for example, we have implemented IDEA and Rijandel using Pentium MMX
>assembler instructions. 4 blocks are encrypted at the same time. using CBC
>mode we can use this optimization only for encryption. using CTR mode we
>can use this optimization for decryption too.

I was puzzled until I saw your corrected message :-)! yes, parallel 
decryption (though not encryption) is possible for CBC mode. Good 
point about the ability to take advantage of parallelism of some 
instruction sets in general purpose PCs! long ago I coded DES for a 
Cray and was amazed how one could take advantage of the 64-bit wide 
registers and the well-advertised pipelining features of the multiple 
executing units.

>another idea: one can use the CTR mode to reduce the latency of the
>encryption process. you can use the idle CPU cycles for producing the
>encrypted stream of bytes. when the packet arrives you can just XOR it
>with precomputed data. this way, you can use the spare memory to decrese
>the latency of your device. you cannot do this with CBC mode.

Yes, CTR mode, or any stream cipher mode without feedback, e.g., OFB 
mode, can precompute keystream and thus reduce delay. This can be 
done for both transmitter and receiver IF the kesyteam generation 
algorithm uses values that both transmitter and receiver know in 
advance. There are various contexts in which this is useful, although 
it may not be practical in the general IPsec context, where the 
number of SAs might be large and packet loss of out of order arrival 
might negate the advantage of precomputation.

However, Russ Housley pointed out to me that in 602.11 nets, 
communication is typically between each PC and the station, not 
peer-to-peer, and out of order delivery is not likely, although 
packet loss may occur. A PC can precompute keystream for the pair of 
"SAs" it has with the station since the number of associations is so 
small. A station needs more memory and horsepower to be able to take 
advantage of this opportunity, but it may be feasible there too. 
Paul Hoffman noted that these optimizations also may apply in the 
iSCSI context, where per-node SA fan out is likely to be very low.

>when you use only CTR mode, you don't need decryption routines :) helps to
>save couple of kilobytes of code memory.

True, but also true for OFB and CFB, i.e., any mode in which the base 
algorithm is used as a keystream generator at both ends.

Steve