Presentation is loading. Please wait.

Presentation is loading. Please wait.

Submission Title: [AES Modes] Date Submitted: [May 10, 2002]

Similar presentations

Presentation on theme: "Submission Title: [AES Modes] Date Submitted: [May 10, 2002]"— Presentation transcript:

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

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

Download ppt "Submission Title: [AES Modes] Date Submitted: [May 10, 2002]"

Similar presentations

Ads by Google