1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [AES Modes]
Date Submitted: [May 10, 2002]
Source: [Daniel V. Bailey, Product Manager for Wireless Networks and Ari Singer, Principal Engineer]
Company [NTRU]
Address [5 Burlington Woods, Burlington, MA 01803]
Voice:[(781) ], FAX: [(781) ],
Re: [Draft P /D0A]
Abstract: [This presentation gives a summary of the pros and cons for the selection of the symmetric algorithm portion of the security suites for with a focus on AES.]
Purpose: [Provide information to the working group to allow the group to make the best decision for symmetric security for ]
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P

2. Agenda
Goals of symmetric components
Algorithms and modes
Options

3. Symmetric Algorithm Goals
Encryption
Must be able to encrypt 55 Mbps at modest gate count and clock rate
Integrity
Must be able to process 55 Mbps at modest gate count and clock rate
Draft D10 specifies different algorithms for encryption and integrity
But it’s possible to use a block cipher for both encryption and integrity
This is what i is doing…should we do the same?

4. Agenda
Goals of symmetric components
Algorithms and modes
Options

5. SHA-256 HMAC SHA-256 is a new algorithm
In a draft NIST FIPS standard
Limited implementation reports
Vendors selling SHA-256 cores quote 23-27,000 gates for implementation
NIST FIPS 198 describes generic HMAC construction
Currently in draft for data integrity
No IP issues
NIST algorithms are traditionally royalty-free to the world

6. SHA-256 HMAC Combined with AES, appears very secure
Known attacks on variable length CBC encryption do not apply when integrity protection is provided
It’s a reasonable choice, but do we need to spend another 23-27,000 gates?
Other secure networking standards (IPSec, i) are choosing to use AES for both encryption and integrity
What are the alternatives?

7. AES Modes of Operation
At first glance, a block cipher is a pretty simple beast
It takes plaintext and a key and outputs ciphertext
Most naïve mode called Electronic Codebook (ECB)
Diagrams here from NIST FIPS 81

8. Electronic Codebook

9. Cipher-Block Chaining
Each ECB block is encrypted independently
Attackers can mount dictionary attacks on a block by block basis
We’d prefer that a plaintext block never encrypt to the same ciphetext block twice
…And so CBC came to be
The last output block depends on each preceding output block

10. Cipher-Block Chaining

11. CBC-MAC
We can use the error-detection properties with or without sending encrypted data
Use CBC encryption on the data stream
Output only the last block, which is now a fancy keyed CRC
The last block is the Integrity Code
Same net effect as using SHA-256 HMAC, but uses same hardware as encryption

12. Counter Mode (CTR) Yet another encryption mode
Introduced by Diffie and Hellman in 1979
Standardized in NIST SP800-38A
It actually uses ECB mode to make a keystream which you XOR with your plaintext
Keystream is the ciphertext blocks computed by encrypting a counter
Why would you do that??
Allows pipelined hardware.
Slightly lower bandwidth overhead: in CBC, you need to send an extra bytes
Modest gate count savings: There’s no need to implement AES decryption!
Any drawbacks?
You can’t reuse counter values with any key
With CBC, you send a random Initialization Vector with the frame to start the chaining
With CTR, you send the first counter value with the frame

13. AES-CCM (CTR with CBC-MAC)
This is just using Counter Mode for encryption and CBC-MAC for integrity
Using one key instead of two
Allows you to do all your data-rate dependent operations with just AES encryption
Eliminates need for high-speed SHA-256 hardware
Eliminates need for AES decryption hardware
Unpatented according to /634r0
Fully described in /001r0
Text for adoption by i in /144r1
Has a majority of support in i
But not enough to unseat the mode in the i called AES-OCB.

14. AES-OCB (Offset Codebook)
Using AES-CCM requires two AES encryptions on each block of data
One for the AES-CTR encryption
One for the AES-CBC-MAC integrity code
AES-OCB is an integrated mode that needs only one AES encryption/decryption for both data encryption and integrity
Allows pipelined hardware like AES-CCM
Also eliminates need for high-speed SHA-256 hardware
Full details in /378r2
More online at
Diagram available at
It’s patented according to /378r2

15. Quick Performance Comparison
Since they’re both based on AES, they need roughly the same area
AES-CCM’s a bit smaller since it doesn’t use AES decryption
AES-OCB always requires about half the encryptions for AES-CCM.
When does it begin to matter?

16. Quick Performance Comparison
/634r0 observes the following:
Typical AES encryption implementation in 20k gates.
10 cycles for a 128-bit encryption
At 40 MHz, that’s 4 million AES blocks/sec
Or max throughput of 512 Mbps
At 55 Mbps, it doesn’t matter
Nor at 100 Mbps.
But at 400 Mbps, AES-OCB needs only a 40 MHz clock, while AES-CCM needs a 65 MHz clock

17. Agenda
Goals of symmetric components
Algorithms and modes
Options

18. Option 1: AES-CBC with SHA-256 HMAC
Pros:
This combination is currently in the draft
Neither algorithm is patented
Highly secure
Known attacks on variable length CBC encryption do not apply when integrity protection is provided
Cons:
SHA-256 may be costly to implement in hardware at high speeds – estimated at 23-27K gates (may be less costly)
This must be implemented in hardware along with AES encryption to hit the data rate
Will not match i

19. Option 2: AES-CCM
Pros:
This combination of modes has received a majority support in i (it is not in the current draft)
Being proposed by RSA Security and others
AES Decryption not needed
Modest gate count savings
SHA-256 no longer has to meet the data rate
Not patented
Text is available in /144r1
May align with i

20. Option 2: AES-CCM Cons: Possible issues with provable security
MAC-then-encrypt not provably secure in generic case
Use of only one key for two different AES modes, so it is not strictly generic composition of two algorithms
A proof is evidently in process but not yet published
Increased security with use of 2 keys (if selected) would require additional gates to store both keys
Will require some tweaks to the draft to ensure unique IV and support MAC-then-encrypt paradigm

21. Option 3: AES OCB Mode Pros: Cons: Currently in 802.1x draft
Has security proofs
Original paper only covered situation where entire data was both encrypted and integrity protected
Newer paper covers a cleartext header (needed for and )
SHA-256 no longer has to meet the data rate
Cons:
Patented
Arguments made that number of ciphertexts before security degrades is limited, but this is not a problem in practice

22. Option 4: Do whatever 802.11i does!
Pros:
It’s Someone Else’s Problem
Cons:
They’re not expecting a standard anytime soon
Strict compatibility doesn’t appear possible

23. Summary Hardware Security Patents Compatibility with 802.11i
AES-CBC with SHA-256 HMAC will cost the most
CCM and OCB are close in hardware cost (depending on implementation and throughput needed)
Security
AES-CBC with SHA-256 and OCB seem to provide the best known security
Good reason to believe that CCM is secure as well
Patents
OCB is patented, the other two options are not
Compatibility with i
Compatibility may be difficult even if we choose the same algorithm