AES Modes

[dj at deadhat.com]

On the IEEE 802 standards track, CCM and GCM have traction. CCM has been
in 802.11 for a while and the 802.16-2004 was published last week,
supplanting the broken DES-CBC mode with AES-CCM. For wireless systems, we
know and like CCM and it's going to take a lot to oust it.

I'm aware of a handful of other wireless protocols in development that
appear to be all headed the CCM way.

GCM proposed for 802.1ae linksec. This is the 'fast' mode for wired ethernet.

For packetised traffic below 1Gbps, CCM works just great. The CTR and CBC
parts of CCM run in parallel in hardware, making the basic latency = 1 AES
(which is 11 clocks in a simple implementation). With a bit of HW loop
unrolling and pipelining, I can do CCM upto several gigabits.

CCM nicely matches the structure of packets. Namely
1) Get header -> Process additional authenticated data
2) Get payload -> Process MAC and encryption in parallel.
So it is not a bear to implement in a typical communications datapath IC,
where things are presented to you in this order.

GCM allows block level parallelism up to a point. Hence enabling me to put
lots of parallel AES blocks on a chip and go at multi gigabits without
breaking a sweat. It does however have all that Galois arithmetic to do
per block, which increases the path depth a bit.

There is however a fundamental speed problem with packet oriented AES
based modes. The parallelism you can achieve on things like GCM requires
that you have multiple blocks to run in parallel. If I get a large number
of small packets, each < 128 bits long, then there's nothing to do in
parallel at the block level and so my speed limit is determined by how
fast I can run 11 rounds of AES.

This may come to bite us in the future and when we start having to protect
data pushing the terabits, we either need larger packets or something
different in the crypto. One way is to protect over large packet
aggregates, but no 802 level protocol is set up to support it. Stream
ciphers look attractive here, we can make them go *really* fast in
hardware.

Another frustrating aspect of the current crop of modes is frame
expansion. Throwing in an 8 byte nonce and an 8 byte ICV per packet is a
heavy overhead. Deriving nonces from the protocol state is generally not
wise since the frame counts are either non existant (802.3, 802.11) or not
secured (802.16).

In the coming years, I would like to see link protocols (I.E. 802.*) move
link security down to the PHY, to protect management and data traffic
equally, to secure the protocol state as well as data and so to reduce
packet overhead. I would also like to see the standardized crypto and
protocols be structured to work over larger aggregates of packets,
protecting the structure of transmission as well as the content and
allowing much greater levels of parallelism in the HW implementations.

Obviously, none of this is very relevant above layer 2.

Regards,
DJ

>>From: Ian Grigg <iang at systemics.com>
>>Sent: Oct 10, 2004 11:11 AM
>>To: Metzdowd Crypto <cryptography at metzdowd.com>
>>Subject: AES Modes
>
>
>>I'm looking for basic mode to encrypt blocks (using AES)
>>of about 1k in length, +/- an order of magnitude.  Looking
>>at the above table (2nd link) there are oodles of proposed
>>ones.
>
>>It would be nice to have a mode that didn't also require
>>a separate MAC operation - I get the impression that
>>this is behind some of the proposals?
>
> I think CCM is just about perfect for this goal.  The MAC isn't free, but
> it's integrated into the chaining mode.  There are also some patented
> modes that provide a MAC for almost no extra computation(OCB, IACBC), and
> some proposed modes that combine an efficient, parallelizeable MAC with
> encryption in a secure way (CWC,GCM), though none of these are standards
> yet.
>
>>iang
>
> --John
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at metzdowd.com
>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com