Standardizing Key Derivation Functions Hugo Krawczyk IBM Research

Standardizing Key Derivation Functions Hugo Krawczyk IBM Research http: //www. ee. technion. ac. il/~hugo/kdf Or: google kdf hmac 1

Key Derivation Functions (KDF) n Everywhere: Key expansion, Key-exchange protocols, Physical RNGs, System PRNGs, Password-derived keys, Key encapsulation, key wrapping, hybrid PK systems, key hierarchies, etc. n So what is it? n Can we standardize a single multi-purpose scheme? n n 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 2

The proposed scheme (HMAC-based) (Similar to IKE’s KDF) Internet draft coming… 3

Paper with VERY detailed rationale n 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… 4

KDF: What is it? n n 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 1 KB stream) ¨ Output of a key exchange (e. g. Diffie-Hellman): comput’l entropy Partial entropy, non-uniform, attacker has partial knowledge 5

KDF: Two Main Functionalities n n 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. n Two fundamentally different functionalities n Often mixed/confused in ad-hoc KDF schemes (a recipe for weaknesses and pitfalls) n Our approach: Extract-then-Expand 6

Key Expansion (the “easy” case) n Given a first strong key derive more keys ¨ K K 1, K 2, K 3 (e. g. keys for MAC, encryption, etc) ¨ If K is cryptographically strong so should K 1, K 2, … be n Independence: Knowing Ki should not help learning anything about Kj n Standard implementation via PRF: e. g. Ki = PRF(K, i) n Many think of KDF just as key expansion ¨ n 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 7

Key Extraction (the challenge) n Source key material --> Extractor --> Output uniform ¨ From partial randomness to strong crypto key n Extractor: a well-known notion in complexity theory n Here: cryptographic instantiation for KDFs (HMAC-based) n 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) 8

Extract-then-Expand n n n 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 9

Generic Extract-then-Expand KDF optional Kprf = Extract(salt, skm) skm= source key material Keys = Expand(Kprf , Keys-length, ctxt_info) Binds key to the application “context” OR. 10

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 = K 1 || K 2 || … First parameter is hmac’s key (can set salt to 0) where Ki+1= HMAC(Kprf, Ki || ctxt_info || i) OR (HMAC in “feedback mode” – which I prefer to counter mode) . 11

Why HMAC n Prudent use of hash, minimize “magic”, proven structure ¨ n Supports both PRF (traditional use) and extraction A “property preserving” mode: extractor, PRF, random oracle n n ¨ 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 (SHA 3 competiton), even block ciphers 12

Traditional Approach to KDF Hash(skm || “ 1” || info) ||. . . || Hash(skm || “t” || info) n Plain hash (not HMAC) used as both extractor and PRF ¨ Plain hash is neither (even if the compression function is purely random) n No separation extract/expand: all folded into one “ideal hash” n At a minimum a reasonable KDF should fare well as an expanding PRF (e. g. , when skm is random) ¨ n n 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 13

NIST Variant (SP 800 -56 A) Hash(“ 1”|| skm || info) ||. . . || Hash(“t” || skm || info) n 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 n ¨ n Apparently intended to counter the 2160 attack against Hash(skm || i): n Can break KDF with a 2160 guessing attacks even if skm much longer n 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): ¨ n pitfall: in an ideal hash the position of the key is unimportant mandates inclusion of identities as part of “info” Recent 800 -108 KDF draft: deals with expansion only 14

Cautionary Note n n 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 15

Summary n KDF: a fundamental ubiquitous cryptographc component n So far, most designs ad-hoc and “abuse” hash functions n The extract-then-expand paradigm as a better approach ¨ n Sound mathematics, prudent engineering Simple instantiation using HMAC ¨ Minimize complexity, mechanisms, and assumptions n Comparison and lessons from alternative schemes n Ready for standardization 16

Any interest? How do we proceed from here? More details/rationale: http: //www. ee. technion. ac. il/~hugo/kdf (internet draft coming. . . ) 17