Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 May, 2002 doc:.: 802.15-02/215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Similar presentations


Presentation on theme: "1 May, 2002 doc:.: 802.15-02/215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)"— Presentation transcript:

1 1 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P 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 2 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 2 Agenda Goals of symmetric components Algorithms and modes Options

3 3 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 3 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 its possible to use a block cipher for both encryption and integrity –This is what i is doing…should we do the same? Symmetric Algorithm Goals

4 4 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 4 Agenda Goals of symmetric components Algorithms and modes Options

5 5 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 6 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 Its a reasonable choice, but do we need to spend another ,000 gates? Other secure networking standards (IPSec, i) are choosing to use AES for both encryption and integrity What are the alternatives?

7 7 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 8 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 8 Electronic Codebook

9 9 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 9 Cipher-Block Chaining Each ECB block is encrypted independently –Attackers can mount dictionary attacks on a block by block basis Wed 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 10 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 10 Cipher-Block Chaining

11 11 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 12 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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: Theres no need to implement AES decryption! Any drawbacks? –You cant 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 13 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 14 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 Its patented according to /378r2

15 15 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 15 Quick Performance Comparison Since theyre both based on AES, they need roughly the same area –AES-CCMs a bit smaller since it doesnt use AES decryption AES-OCB always requires about half the encryptions for AES- CCM. When does it begin to matter?

16 16 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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, thats 4 million AES blocks/sec Or max throughput of 512 Mbps At 55 Mbps, it doesnt 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 17 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 17 Agenda Goals of symmetric components Algorithms and modes Options

18 18 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 19 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 20 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 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 21 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 21 Option 3: AES OCB Mode Pros: –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 22 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 22 Option 4: Do whatever i does! Pros: –Its Someone Elses Problem Cons: –Its Someone Elses Problem Theyre not expecting a standard anytime soon –Strict compatibility doesnt appear possible

23 23 May, 2002 doc:.: /215r0 Daniel V. Bailey, Ari Singer, NTRU 23 Summary Hardware –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 "1 May, 2002 doc:.: 802.15-02/215r0 Daniel V. Bailey, Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)"

Similar presentations


Ads by Google