2. 2
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!
4. 4
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!)
5. 5
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
8. 9
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. 10
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?
How?
The length indeed “disappeared”
10. 11
IP Packet Authentication in IPsec
Two modes
AH (authentication header): Authentication only
ESP (encapsulating security payload): Authentication
plus optional encryption
11. 12
Authentication Header (AH*) [~ RFC 2402]
IP Header
SPI
Replay Prevention Sequence Number
Payload
Padding
Pad Length Protocol
MAC Value
MAC (covers header)
Payload Length
*approximate
description
12. 13
ESP Format [RFC 2403]
IP Header
SPI
Replay Prevention Sequence Number
Initial Vector
Payload
Padding
Pad Length Protocol
MAC Value
MAC
Optionally
Encrypted
Payload
MAC does not
cover IP header!
Payload Length
13. 14
Theory
Engineering
Theory
Engineering
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
It was simple and secure under the specific conditions at the
time but too fragile to withstand future changes
It required a
balancing act…
14. 15
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)
... and two keys
Engineers wanted black-box call to the hash
(e.g. h/w implementation) and a single short key
Engineering
Theory
Engineering
Theory
Key replaces IV
15. 16
Theory
Engineering
Theory
Engineering
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, msg) = Hash(K+opad | Hash(K+ipad | M))
As NMAC but with “built-in” key derivation
K1=Hash(K+opad) K2=Hash(K+ipad)
and most important: no change of IV
balance regained and the rest is history…
17. 18
Theory
Engineering
Theory
Engineering
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)
In theory: Yes [NY’89].
Then why are we building signatures
that depend on coll. resistance?
18. 19
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. 20
Engineering
Theory
Engineering
Theory
Initial “Randomized Hashing” Proposal [HK06]
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
Attacker has a much harder problem to solve
An implementation of the “target collision resistance” notion
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. 21
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)
22. 24
Theory
Engineering
Theory
Engineering
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.
NIST standardized the RMX technique and eTCR
is an explicit requirement for SHA3.
Yet, no real implementations.
Why? Partly, because the following principle is missing
23. 25
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
24. 26
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..
25. 27
Linux Penguin Encrypted w/CBC
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
ECB vs CBC
Encrypted w/ECB!
Courtesy of wikipedia “modes of operation”
26. 28
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
27. 29
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. 31
Theory
Engineering
Theory
Engineering
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?
KDF in Practice
30. 32
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)
Hash(skm || “1” || info) || ... || Hash(skm || “t” || info)
31. 33
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
Kprf = Extract(salt, skm) skm= source key material
Keys = Expand(Kprf , Keys-length, ctxt_info)
Binds key to the application “context”
Optional (random but non-secret)
32. 34
Engineering
Theory
Engineering
Theory
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
33. 35
Kprf = HMAC(salt, skm) skm= source key material
Keys = HMAC(Kprf , Keys-length, ctxt_info)
where Keys = K1 || K2 ||
… Ki+1=
HMAC(Kprf, Ki || ctxt_info || i)
(HMAC as PRF in “feedback mode”)
Regaining Balance: HKDF
(HMAC as extractor and PRF)
OR
34. 36
Theory
Engineering
Theory
Engineering
HKDF: Balance regained
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)
35. 37
The Power of Proofs
and Proof-driven Design in
Cryptographic Protocols
Simple example: Asymmetric Key Wrapping
and One-pass Key Exchange
36. 38
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)
37. 39
Authenticated Key Wrapping
DHIES implicitly authenticates the receiver
Only intended receiver can read the key/data
But how about sender’s authentication?
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.
38. 40
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
Authenticated DHIES = “authenticated KEM” + DEM
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
mutually
relation to signcryption
[Gorantla et al, Dent]
39. 42
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 signifi-
cantly more expensive, provides weaker authentication (attacker
can learn someone else’s M), and does not provides y-security
40. 43
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…
42. 45
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
43. 46
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
