Hugo Krawczyk
IBM Research
Asiacrypt’2010
1
An exciting journey…


This talk reflects my personal journey between theory
and practice
I will focus on the “influencing practice” part



hence the title “from theory to practice”, though it is always a
two-way journey (as we’ll see)
It is laborious but ultimately quite fun and rewarding
(most of the time  )
I will try to offer some (hopefully useful) lessons for
those who want to join the journey

…and you are very welcome and encouraged to do so!
2
"In theory, theory and practice are the same.
In practice, they are not."
3
In cryptography, theory IS practical

We don’t have the luxury of most engineering fields:

Can’t resort to experimental evidence: no testing, no simulations

Think of safety systems (airplanes, cars):
one can simulate nature forces experimentally or by computer

But you cannot model “human force” – especially a malicious one
(think of designing WTC to withstand an airplane accident vs a 9/11 attack)


And you cannot computer-simulate crypto attackers,
but you can “simulate” them via mathematical models and proofs
Math models & proofs as our main source of confidence
(even when keeping in mind the imperfection of math models…)

Alternative is to spend “1000 PY cryptanalysis” or pray (or both!)
4
Can you sell this view to
practitioners?

Not easy.. but it’s getting much easier



Today if you come with a proposal even the engineers may ask
for (mathematical) analyses – an farfetched dream 15 years ago
It has one condition though: You need to respect the
“rules of the engineering game”

Simplicity, efficiency, low cost of deployment, …

And it has to solve a problem the engineers want to solve

Selling a solution is not easy – selling a problem is much harder
As we’ll see it is all about a challenging balancing act
5
A tough balancing act…
6
HMAC Story:
A Balancing Act
8
1994: IPsec design underway

Goal: Secure the Internet Protocol



Authenticate and encrypt IP packets
Authentication method: Key-prepend MAC

MACK(P) = Hash(K || P)

Can you see the problem?
Next: A not too friendly “dialogue” with some IPsec
leading engineers at the time
9
A 1994 IPsec dialogue






Me: This mode is open to extension attacks!
They: Aha! But not if P’s length is prepended…
and IP packets always carry the length in the header!
Me: I do not like to use non-cryptographic elements as
essential cryptographic elements. What if tomorrow
the length is omitted?
They: Are you cookoo? IP packets will always carry
their length
I insisted, though I did not have a truly convincing
answer beyond: “prudent engineering, sound principles”
But guess what? The length indeed “disappeared”
How?
10
IP Packet Authentication in IPsec

Two modes
 AH
(authentication header): Authentication only
 ESP
(encapsulating security payload): Authentication
plus optional encryption
11
Authentication Header (AH*)
[~ RFC 2402]
Payload Length
IP Header
SPI
Replay Prevention Sequence Number
Payload
MAC (covers header)
Padding
Pad Length
MAC Value
Protocol
*approximate
description
12
ESP Format
[RFC 2403]
Payload Length
IP Header
SPI
Replay Prevention Sequence Number
MAC does not
cover IP header!
Initial Vector
MAC
Payload
Optionally
Encrypted
Payload
Padding
Pad Length
Protocol
MAC Value
13
The end of the story?


ESP is the most common IPsec mode, the MAC does not
cover the header (for some good reasons).
So how about the MAC security w/o the length?


Eventually, HMAC was (invented and) adopted
The prepend-only proposal is a clear example of too much
focus on engineering-only considerations
ry

eo
Th
It was simple and secure under the specific conditions at the
It required a
time but too fragile to gwithstand future changes
in
Eng
eer
in
balancing act…
14
Theory: NMAC

NMACK1,K2(M)= HashK1(HashK2(M))
 The
“right thing”: conceptually PRF(UH) & nice proof
 but
requires a variable IV (replaced with the keys)
 ...

Key replaces IV
and two keys
Engineers wanted black-box call to the hash
(e.g. h/w implementation) and a single short key
Eng
ine
eri
ng
Th
eor
y
15
Bridging between Theory and Practice

Proof used NMACK1,K2(M)= HashK1(HashK2(M))
 Here

subscript means replacing hash IV with key
The “compromise” (black-box call to Hash, single key)
 HMAC(K,
 As
msg) = Hash(K+opad | Hash(K+ipad | M))
NMAC but with “built-in” key derivation
K1=Hash(K+opad)
 and
K2=Hash(K+ipad)
most important: no change of IV
ing
Engineer
Theory
balance regained and the rest is history… 
16
Randomized Hashing Story:
A Balancing Act
[HK’06]
17
The Collisions Crisis


Background: The “hash confidence” crisis
Obvious answer: design, standardize, implement new
stronger hash functions (SHA3 competition)

But what if new functions broken in 5-10 years?

Can we buy insurance against future collisions??

Specifically: Can we build digital signatures without


collision resistance? (remain secure even if collisions found)
ry
eo
Th
In theory: Yes [NY’89].
Then why are we building signatures
that depend on coll. resistance?
ng
eri
E
ne
ngi
18
Randomized Hashing

From: Sign(H(M)) (hash-then-sign)
To:

Sign(Hr(M)) where Hr = randomized version of H
Idea: r chosen by signer at the time of signature;
r sent with message and signature
Thus, attack on signature starts only after learning r

Fundamental shift in attack scenario: Off-line vs. On-line


In particular, no use for off-line collisions
But can it be built? Can it be proven?
Can it be practical?
19
Initial “Randomized Hashing” Proposal

First proposal: Sign( r | H(M+r))


| concatenation, + blockwise xor, r = repeated random block
We proved that off-line collisions on H do not break the
signature
Eng




[HK06]
ine
er i
ng
Attacker has a much harder problem to solve
An implementation of the “target collision resistance” notion
Th
eo
ry
But, would the engineers buy it?
No! we broke the hash-then-sign paradigm and with it
1000s of implementations

The signature of r in addition to the hash does not work with
sign-then-hash
20
Back to the drawing board


Find a randomized hashing scheme that provides
freedom from collisions but preserves hash-then-sign
Enter RMX: Given msg M to sign
 Signer
chooses fresh r
 Computes
σ = Sign( H (RMX(r,M)) )

Sign is any “hash-then-sign signature scheme” (RSA, DSS,…)

Note that only the output of H is signed, not r
 Signature
= (σ, r)
21
RMX: Preserving Hash-then-Sign
M =(m1,…,mL)
M =(m1,…,mL)
r
RMX
(r, m1r,,…,mLr(
HASH
HASH
RMX
1st proposal
SIGN
SIGN
signature
( signature
,
X
r )
22
Randomized Hashing Lesson




To meet the engineers’ requirement to preserve
hash-then-sign we had to re-design RMX
We had to change the proof and introduce a new
notion: “enhanced target collision resistance” (eTCR).
Luckily, we could prove eTCR under the same
assumptions on underlying compression function.
So, were the engineers impressed? Mixed results.

Theory
NIST standardized the RMX technique
and eTCR
g
in
r
e
e
in
is an explicitEngrequirement for SHA3.

Yet, no real implementations.

Why? Partly, because the following principle is missing
24
Randomized Hashing Lesson


Current focus is on changing the hash functions -- not
on the way we use them
Need to convey the message:
It’s not just about WHAT to use but HOW to use it


Many times, the “how to use” is more critical than the
basic design (using it right can survive a weaker function)
I love to use the following ECB vs CBC analogy

The “what”: Block cipher

The “how”: ECB vs CBC
25
Analogy from block ciphers: CBC vs ECB

ECB encrypts each input block independently

CBC randomizes encryption to hide repeated blocks

But does CBC adds real security?


“Come on, how bad it is to leak repeated blocks?”

Certainly not too bad for “random” (incompressible) plaintext
Well..
26
ECB vs CBC
Linux Penguin

Encrypted w/CBC
Encrypted w/ECB!
Indeed, it’s about how to use it!

Note that in this case a strong block cipher (e.g. AES) with
ECB is weaker than a weak block cipher (e.g. DES) with CBC
Courtesy of wikipedia “modes of operation”
27
Back to Randomized Hashing


I don’t have an eloquent picture to show the benefits
of randomized hashing as with CBC vs ECB
But the safety net provided to digital signatures by an
RMX-like technique is huge

If we were using RMX, today’s signatures would be much less
at risk from collision attacks

Obviously, we need to design the strongest possible hash
functions but also use them more prudently
28
Randomized Hashing: Work in Progress

The randomized hashing story is not over… we need
to make it happen in the real world (and you can help!)

Need to update standards to compute RMX and transport r


Note: can re-use randomness in randomized signatures (DSA, PSS)
Should we rely on random serial #’s in certificates?

No! Remember the reliance on pre-pended length in IPsec?

Today s/n may be random, tomorrow just a sequence number (why not?)
29
HKDF Story:
A Balancing Act
30
KDF in Practice

Key derivation function (KDF): From an imperfect source of keying
material to strong crypto keys

Imperfect: non-uniform, side information (partial secrecy)

Random Number Gen, system entropy sources, Diffie-Hellman (KE), ...

Output: one or more keys (e.g., encryption, MAC, etc)

A fundamental crypto primitive: Yet common design very ad-hoc-ish

Common practice: skm = “source key material” info=context info

Hash(skm || “1” || info) || . . . || Hash(skm || “t” || info)

Can it be proven? Only for “perfect” hash (random oracle)

Can we do better?
ine
Eng
eri
eor
Th
y
ng
31
Hash(skm || “1” || info) || ... || Hash(skm || “t” || info)

To illustrate weakness, consider the “easy” case:
where skm is a fully random key



In this case only need a PRF to convert skm into multiple keys
But the above design is not even a good PRF

This is the old “prepend-key” PRF: PRFK(x)=Hash(k||x)

which has been deprecated long ago in favor of better modes’
KDF is a much more demanding primitive than PRF
(needs to work with non-random keys), and yet we are
using a design that is weak even as a PRF.

And don’t rely on “info” being of fixed length (multi-purpose KDF)
32
Can we balance the KDF act? HKDF


[K’10]
Follow the “extract-then-expand” paradigm
1.
Key Extraction: Derive a first cryptographically strong key
from an “imperfect source of randomness”
2.
Key Expansion: Given a first cryptographically strong key derive
more keys (basically a PRF with variable-length output)
Generic Extract-then-Expand KDF
Optional (random but non-secret)
Kprf = Extract(salt, skm) skm= source key material
Keys = Expand(Kprf , Keys-length, ctxt_info)
Binds key to the application “context”
33
Can we balance the KDF act? HKDF

[K’10]
How to implement “extraction”? (from imperfect source to
single strong PRF key)

Can use the theory of randomness extractors (complexity theory)

Efficient unconditional constructions exist (e.g. strong univ. f’s)


But require large salt, do not fulfill all crypto needs (e.g. RO uses,
tight gaps, etc), and are not available in crypto libraries
Unconditional extractors not likely to be used in practice

balance tilted to the theoretical side
Eng
ine
er i
ng
Th
eor
34
y
Regaining Balance: HKDF
(HMAC as extractor and PRF)
Kprf = HMAC(salt, skm)
skm= source key material
Keys = HMAC(Kprf , Keys-length, ctxt_info)
where Keys = K1 || K2 ||
Ki+1=
…
OR
HMAC(Kprf, Ki || ctxt_info || i)
(HMAC as PRF in “feedback mode”)
35
HKDF: Balance regained
Engineer


ing
Theory
Practice: HMAC already used as PRF, here re-used as extractor.
Theory: Detailed analysis [DGHKR’04, CDMP’05,K’10] shows
HMAC as a good computational extractor under various models
of compression functions


Wide range of assumptions depending on use: from purely
combinatorial to random-oracle type modeling
Not satisfied by plain M-D hash: HMAC much stronger as a
property-preserving mode (pseudorandomness and extraction)
36
The Power of Proofs
and Proof-driven Design in
Cryptographic Protocols
Simple example: Asymmetric Key Wrapping
and One-pass Key Exchange
37
Key Wrapping

Key-wrapping or key encapsulation: server transmits a
key (and possibly associated data) to a client

Major key management tool: storage, hardware security modules,
secure co-processors, ATM machines, etc.

Symmetric vs Asymmetric: AES-based, RSA-based

Industry is searching for an ECC solution

Main candidate: DHIES [ABR’01]


CCA-secure encryption, can transmit key and associated data
Implicitly authenticates the intended receiver (the only one
that can read the key/data)
38
Authenticated Key Wrapping

DHIES implicitly authenticates the receiver


But how about sender’s authentication?


Only intended receiver can read the key/data
Interestingly: Just adding sender’s signature on top of
DHIES is weaker than it may look
Good news: Can solve the problem even more efficiently
than with signatures and with better security

Thanks to well-defined (reusable) primitives and models

Thanks to designs that can get rid of safety margins

Thanks to the power of proofs in well defined models.
39
Authenticated DHIES and One-Pass KE


DHIES is an instantiation of the KEM/DEM paradigm: (Y,C,T)

Key Encapsulation: Y=gy encapsulates K=H(Ay) (A is receiver’s PK)

Data Encapsulation: (C,T) CCA-encrypts data under K
KEM  receiver-authenticated one-pass KE
mutually
 Authenticated DHIES = “authenticated KEM” + DEM
relation to signcryption
[Gorantla et al, Dent]

Authenticated KEM  Authenticated One-Pass KE

ECC-friendly AKEM implementation [HK’11]: One-Pass HMQV [K,MQV]

Reduction to the OP-KE case avoids need for new models and protocols

Efficiency: same as DHIES for sender and just ½ expon more for receiver

Sender: from Ay to Ay+be ; Receiver: from Ya to (YBe)a
40
See what ½ exponentiation buys us




Sender authentication (plus all properties of basic KE security)
Sender forward security (disclosure of b does not
compromise past keys and messages)
y-security : The disclosure of ephemeral y does not
compromise any keys or messages
Moreover: the disclosure of both y and b reveals the
msg sent using y but no other msgs sent by b’s owner
Note: Just adding a signature (say DSA) on top of DHIES is significantly more expensive, provides weaker authentication (attacker
can learn someone else’s M), and does not provides y-security
42
The Power of Proofs
(not only in theory but in practice too)

Proof maps exact functionality of each element in the
protocol

What security properties require that element and which do not

What the effect of leakage of each secret value is

A precise guide to protocol design and to getting rid of safety
margins  simpler and more efficient protocols


Proofs are even excellent cryptanalysis tools for debugging
protocols and finding attacks
I called this “Proof-Driven Design”

but this is a topic for another full talk…
43
Concluding Remarks
44
Crypto: a truly cool field!


Amazing ideas, beautiful math, great theory, practical
and social relevance. Unusual mix of theory and practice.
In crypto theory IS practical!

No experimental evidence, no computer-simulations, no testing

Only well-defined notions and models* to develop sound analysis
( * it’s ok if the models are not perfect; perfect models don’t exist; but w/o
models and proofs we are left with “words of gentlemen” and broken designs)

It’s amazing how well the theoretical notions and techniques
work in practice (pseudo-randomness, simulations, zero knowledge, semantic
security, even idealized random oracles and “ugly assumptions” such as Gap-DH)

Proof-Driven Design: Sound and Practical for the same price
45
Lessons from the field…




Only way to get sound crypto used is to interact with
the engineers: listen, respect, argue, be persistent
Practice-Efficiency-Simplicity-Beauty
Timing: Not easy to sell solutions but much harder to
sell problems (see what keeps the engineers awake at night)
Sound principles, robustness of design

Design by functionality not by implementation (PRF/MAC/extract vs
HMAC/SHA1); do not piggyback on non-crypto elements*; design to last
*

examples: pre-pended length, relying on random s/n in certs,
assuming “info” to be of fixed length (actually, adv. chosen)
Remember: it’s not just about what to use but how to use it
46
and most importantly…
it requires…
47
exhilarating
A ___________
challenging balancing act…
48