1 Standardizing Key Derivation Functions Hugo Krawczyk IBM Research 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 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 g xy 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 K prf = Extract(salt, skm) skm= source key material Keys = Expand(K prf, Keys-length, ctxt_info). OR Binds key to the application “ context ” optional

11 HMAC-based Implementation (HMAC as extractor and PRF) K prf = HMAC(salt, skm) skm= source key material Keys = HMAC(K prf, Keys-length, ctxt_info) where Keys = K 1 || K 2 || … where K i+1 = HMAC(K prf, K i || 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 A) 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 attack against Hash(skm || i): Can break KDF with a 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 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: (internet draft coming...)