Should nist develop an additional version of gcm l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

Should NIST Develop an Additional Version of GCM? PowerPoint PPT Presentation


  • 191 Views
  • Uploaded on
  • Presentation posted in: General

Should NIST Develop an Additional Version of GCM? . July 26, 2007 Morris Dworkin, Mathematician Security Technology Group [email protected] Some of the Submissions to NIST for Authenticated Encryption. Patented, One-Pass, Parallelizable Modes XECB, etc.Gligor, Donescu IAPMJutla

Download Presentation

Should NIST Develop an Additional Version of GCM?

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Should NIST Develop an Additional Version of GCM?

July 26, 2007

Morris Dworkin, Mathematician

Security Technology [email protected]


Some of the Submissions to NIST for Authenticated Encryption

  • Patented, One-Pass, Parallelizable Modes

    • XECB, etc.Gligor, Donescu

    • IAPMJutla

    • OCBRogaway

  • Other Parallelizable Modes, One-Pass + Universal Hash

    • GCMMcGrew, Viega

    • CWCKohno, Viega, Whiting

  • Two-Pass Modes

    • CCMHousley, Whiting, Ferguson

    • EAXBellare, 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


GCM GCTR Function


GHASH Function(NIST version, w/o length encodings)

In effect, the GHASH function calculates

X1Hm X2Hm-1  ... Xm-1H2  XmH.


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.


Software Performance Comparison(Mbps on 1 GHz processor)


Comments ?


  • Login