1

Standardizing

Key Derivation Functions

Hugo Krawczyk

IBM Research

http://www.ee.technion.ac.il/~hugo/kdf

Or: google kdf hmac

2

Key Derivation Functions (KDF)

Everywhere: Key expansion, Key-exchange protocols, Physical

RNGs, System PRNGs, Password-derived keys, Key encapsulation, key wrapping, hybrid PK systems, key hierarchies, etc.

So what is it?

Can we standardize a single multi-purpose scheme?

Proliferation of ad-hoc schemes, no clear candidate for standardization, everyone invents its own scheme

Time for action (part of cleaning the “hash mess”)

In particular: prudent use of hash functions, sound rationale

3

The proposed scheme (HMAC-based)

(Similar to IKE’s KDF)

Internet draft coming…

4

Paper with VERY detailed rationale

http://www.ee.technion.ac.il/~hugo/kdf

Why this scheme

Why common plain-hash designs should be avoided

Focus on prudent use of hash functions and mathematical rationale

Here: short summary, call for action

Feedback welcome…

5

KDF: What is it?

From “Initial Source Key Material” to one-or-more strong cryptographic keys (fixed size, “close to uniform”)

Source key material (many forms)

A random uniform string (or a strong cryptographic key): just a key expansion functionality (from one key to many)

An imperfect random number generator, an “event sampler”, etc: good amount of entropy but not in a uniform way (e.g. 160 bits of entropy “trapped” into a 1KB stream)

Output of a key exchange (e.g. Diffie-Hellman): comput’l entropy

Partial entropy, non-uniform, attacker has partial knowledge

6

KDF: Two Main Functionalities

Key Expansion: Given a first cryptographically strong key derive more keys

Key Extraction: Derive a first cryptographically strong key from an “imperfect source of randomness”

Imperfect RNG, system PRNG, Diffie-Hellman, etc.

Two fundamentally different functionalities

Often mixed/confused in ad-hoc KDF schemes (a recipe for weaknesses and pitfalls)

Our approach: Extract-then-Expand

7

Key Expansion (the “easy” case)

Given a first strong key derive more keys

K K1, K2, K3 (e.g. keys for MAC, encryption, etc)

If K is cryptographically strong so should K1, K2, … be

Independence: Knowing Ki should not help learning anything about Kj

Standard implementation via PRF: e.g. Ki = PRF(K, i)

Many think of KDF just as key expansion

Leads to weak designs: e.g., using DH value gxy as a PRF key (TLS)

Simple, but often “wrong” (no binding, weak use of hash,

etc), and non-standardized

8

Key Extraction (the challenge)

Source key material --> Extractor --> Output uniform

From partial randomness to strong crypto key

Extractor: a well-known notion in complexity theory

Here: cryptographic instantiation for KDFs (HMAC-based)

Deterministic vs non-deterministic extractors

Using random salt in the extractor computation allows for much stronger properties (“generic extractor”, enforces independnce)

Salt: random but non-secret (similar to an IV) and reusable! We will use it optionally if available (e.g., RNG, key exchange)

9

Extract-then-Expand

Extract-then-Expand: Our basic design paradigm

Two well differentiated modules, for the two well differentiated functionalities

Modules are orthogonal and replaceable

But can implement with same underlying cryptographic primitive: hash functions or block ciphers

Our specific hash-based proposal uses HMAC for both

10

Generic Extract-then-Expand KDF

Kprf = Extract(salt, skm) skm= source key material

Keys = Expand(Kprf , Keys-length, ctxt_info)

.

OR

Binds key to the application “context”

optional

11

HMAC-based Implementation (HMAC as extractor and PRF)

Kprf = HMAC(salt, skm) skm= source key material

Keys = HMAC(Kprf , Keys-length, ctxt_info)

where Keys = K1 || K2 || …

where Ki+1= HMAC(Kprf, Ki ||

ctxt_info || i)

(HMAC in “feedback mode” – which I prefer to counter mode)

.

OR

First parameter is hmac’s key (can set salt

to 0)

12

Why HMAC

Prudent use of hash, minimize “magic”, proven structure

Supports both PRF (traditional use) and extraction

A “property preserving” mode: extractor, PRF, random oracle

none of these achieved by plain hash

supported by recent crypto literature

With and without key, with and without salt

Can replace HMAC with new “property preserving” modes (SHA3 competiton), even block ciphers

13

Traditional Approach to KDF

Plain hash (not HMAC) used as both extractor and PRF

Plain hash is neither (even if the compression function is purely random)

No separation extract/expand: all folded into one “ideal hash”

At a minimum a reasonable KDF should fare well as an expanding PRF (e.g., when skm is random)

But above scheme uses the weak “key-prepended” PRF mode

Scheme is unsuited as extractor

Repeated extraction from same skm dilutes entropy

Correlated inputs break even information-theoretic extractors

Does not accommodate salt even if available

Hash(skm || “1” || info) || . . . || Hash(skm || “t” || info)

14

NIST Variant (SP 800-56A)

The traditional approach with a swapped counter

Exemplifies the ad-hoc nature of these designs

As PRF: a bad combination of key-prepended and key-appended modes pitfall: in an ideal hash the position of the key is unimportant

Apparently intended to counter the 2160 attack against Hash(skm || i):

Can break KDF with a 2160 guessing attacks even if skm much longer

The illusion of > 160-bit security with a 160-bit hash (nist does not claim >160)

Also: NIST function is “over-specified” (even for key exchange):

mandates inclusion of identities as part of “info”

Recent 800-108 KDF draft: deals with expansion only

Hash(“1”|| skm || info) || . . . || Hash(“t” || skm || info)

15

Cautionary Note

Everything is “correct” when Hash is treated as purely random

Idealization leads to wrong designs (e.g., all key positions equal)

Even if a compression function is random, its M-D iteration is not (not even a good extractor!)

In contrast: HMAC preserves the compression function randomness

16

Summary

KDF: a fundamental ubiquitous cryptographc component

So far, most designs ad-hoc and “abuse” hash functions

The extract-then-expand paradigm as a better approach

Sound mathematics, prudent engineering

Simple instantiation using HMAC

Minimize complexity, mechanisms, and assumptions

Comparison and lessons from alternative schemes

Ready for standardization

17

Any interest?

How do we proceed from here?

More details/rationale: http://www.ee.technion.ac.il/~hugo/kdf (internet draft coming...)