170 likes | 512 Views
Should NIST Develop an Additional Version of GCM? . July 26, 2007 Morris Dworkin, Mathematician Security Technology Group dworkin@nist.gov. Some of the Submissions to NIST for Authenticated Encryption. Patented, One-Pass, Parallelizable Modes XECB, etc. Gligor, Donescu IAPM Jutla
E N D
Should NIST Develop an Additional Version of GCM? July 26, 2007 Morris Dworkin, Mathematician Security Technology Groupdworkin@nist.gov
Some of the Submissions to NIST for Authenticated Encryption • Patented, One-Pass, Parallelizable Modes • XECB, etc. Gligor, Donescu • IAPM Jutla • OCB Rogaway • Other Parallelizable Modes, One-Pass + Universal Hash • GCM McGrew, Viega • CWC Kohno, Viega, Whiting • Two-Pass Modes • CCM Housley, Whiting, Ferguson • EAX Bellare, Rogaway, Wagner
Galois/Counter Mode (GCM) • Designed, analyzed, submitted by McGrew & Viega • Authenticated encryption with associated data (AEAD) • Counter mode encryption using approved block cipher • Authentication using universal hash function in Galois field • Requires 96-bit initialization vectors (IVs) that do not repeat for the life of the key • Performance • High-speed (10Gbit/sec) hardware implementation • Good in software, given table lookups
GCM Authenticated Encryption IV P J0 inc GCTRK A 0v C 0u [len(A)]64 [len(C)]64 0128 GHASHH GCTRK CIPHK MSBt H T
GCM Authenticated Decryption P IV J0 inc GCTRK A 0v C 0u [len(A)]64 [len(C)]64 0128 GHASHH GCTRK CIPHK MSBt H T T if FAIL
GHASH Function(NIST version, w/o length encodings) In effect, the GHASH function calculates X1Hm X2Hm-1 ... Xm-1H2 XmH.
Summary of the Development ofNIST Special Publication 800-38D • Announcement of selection of GCM over CWC (2005) • First draft SP 800-38D (spring of 2006) • Restricts range of tag lengths to 12-16 bytes • Joux’s public comment (June, 2006) • Practical attack if initialization vector (IV) is repeated for a key • Suggests design modifications • Second draft SP 800-38D (July, 2007) • Elaborates on IV requirements • Removes support for variable-length IVs
Joux’s Attack on Repeating IVs • Assumes IVs are repeated for distinct encryption inputs • Violation of GCM requirements (implementation error) • Adversary needs only a couple of pairs of IV-sharing ciphertexts • Adversary can probably derive authentication subkey • If so, authentication assurance is essentially lost • Valid tags can be found for arbitrary ciphertext, reusing old IV • Counter mode “malleability” can be exploited • Given one known plaintext-ciphertext pair, and reusing its IV, adversary can choose any bits to “flip” • Confidentiality apparently not affected
Elaboration on IV Requirements in Second Draft NIST SP 800-38D • Two IV constructions • Deterministic assurance of uniqueness • Random bit generator, up to threshold of 2-32 over life of key • Implementation considerations for designer and implementer • E.g., recovery from power loss • For validation against FIPS 140-2 • IV generation must be within cryptographic boundary of module • IV is a critical security parameter until invoked (for encryption) • Documentation requirements
Develop a “Misuse Resistant” Variant? • Joux suggests modifications • NIST would like feedback on whether to develop a variant of GCM that resists Joux’s attack • Pros • Allow relaxation of IV validation • Increase general purpose usability • Cons • Reduce performance, especially in hardware • Algorithm proliferation • NIST intends to finalize the original spec independently
K Strong KDF K1 K2 K3 K4 IV P K2 K1 J0 inc GCTR A 0v C 0u [len(A)]64 [len(C)]64 GHASH K3 0128 K4 GCTR CIPHK CIPH H MSBt T Joux’s Suggested Modifications to GCM Authenticated Encryption
Hardware Performance (bits/cycle)Assuming Single AES Pipeline
Internet Performance Index (IPI) • Table taken from “The Security and Performance of the Galois/Counter Mode (GCM) of Operation (Full Version)” • Packet distribution f(s)=the expected fraction of bytes that are carried in packets of size s. • Using data from paper of Claffy, Miller Thompson (1998): f(1500)=0.6, f(576)=0.2, f(552)=0.15, f(44)=0.05 • IPI=the expected number of bits processed per clock cycle for this packet distribution. • “Useful indicator of the performance of a crypto module that protects IP traffic using e.g. ESP in tunnel mode…”
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 … P4 P3 P2 P1 T P1 T P2 P1 GCM in Hardware: No Stalls in the AES Pipeline The grey message has three counter blocks to encrypt: two for its plaintext blocks, and one for the output of the GHASH function. The counter blocks for the one-block yellow message and the multi-block blue message follow directly in the pipeline.