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


  • 185 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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

GCM GCTR Function


Ghash function nist version w o length encodings l.jpg

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 of nist special publication 800 38d l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Joux s suggested modifications to gcm authenticated encryption l.jpg

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 l.jpg

Hardware Performance (bits/cycle)Assuming Single AES Pipeline


Internet performance index ipi l.jpg

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…”


Gcm in hardware no stalls in the aes pipeline l.jpg

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 l.jpg

Software Performance Comparison(Mbps on 1 GHz processor)


Slide17 l.jpg

Comments ?


  • Login