Example:the Diffie-Hellman Key Exchange

1

Cryptography from Theory to Practice (a personal
perspective)
Hugo Krawczyk IBM Research Asiacrypt2010
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 well
  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!

3
"In theory, theory and practice are the same. In
practice, they are not."
4
In cryptography, theory IS practical

• We dont have the luxury of most engineering
  fields
• Cant 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
Can you sell this view to practitioners?

• Not easy.. but its 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 well see it is all about a challenging
  balancing act

6
A tough balancing act
7
A tough balancing act
8
HMAC StoryA Balancing Act
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

10
A 1994 IPsec dialogue

• Me This mode is open to extension attacks!
• They Aha! But not if Ps 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
11
IP Packet Authentication in IPsec

• Two modes
• AH (authentication header) Authentication only
• ESP (encapsulating security payload)
  Authentication plus optional encryption

12
Authentication Header (AH) RFC 2402
IP Header
Payload Length
SPI
Replay Prevention Sequence Number
Payload
MAC (covers header)
Padding
Protocol
Pad Length
approximate description
MAC Value
13
ESP Format RFC 2403
MAC does not cover IP header!
IP Header
Payload Length
SPI
Replay Prevention Sequence Number
Initial Vector
MAC
Payload
Optionally Encrypted Payload
Padding
Protocol
Pad Length
MAC Value
14
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
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

Key replaces IV
16
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(Kopad Hash(Kipad M))
• As NMAC but with built-in key derivation
• K1Hash(Kopad) K2Hash(Kipad)
• and most important no change of IV

balance regained and the rest is history ?
17
Randomized Hashing StoryA Balancing Act HK06
18
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 NY89.
• Then why are we building signatures
  that depend on coll. resistance?

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?

20
Initial Randomized Hashing Proposal HK06

• First proposal Sign( r H(Mr))
• 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

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 s 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 (s, r)

22
RMX Preserving Hash-then-Sign
M (m1,,mL)
M (m1,,mL)
r
RMX
(r, m1?r,,,mL?r(
HASH
HASH
RMX X
1st proposal
SIGN
SIGN
signature
( signature , r )
23
Merkle- Damgard . Hash H

h
h
h
h
Hash(M)
IV
? ? ?
m1
mL-1
mL
r
r
r
r
?
?
?
The RMX Scheme (one-pass blockwise
processing)


h
h
h
h
H(r,M)
IV
? ? ?
24
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

25
Randomized Hashing Lesson

• Current focus is on changing the hash functions
  -- not on the way we use them
• Need to convey the message
• Its 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

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..

27
ECB vs CBC
Encrypted w/ECB!

• Linux Penguin Encrypted w/CBC
• Indeed, its 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
28
Back to Randomized Hashing

• I dont 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, todays 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

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?)

30
HKDF StoryA Balancing Act
31
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
  infocontext info
  
• Hash(skm 1 info) . . . Hash(skm
  t info)
• Can it be proven? Only for perfect hash (random
  oracle)
• Can we do better?

32
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(kx)
• 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 dont rely on info being of fixed length
  (multi-purpose KDF)

33
Can we balance the KDF act? HKDF K10

• Follow the extract-then-expand paradigm
• Key Extraction Derive a first cryptographically
  strong key from an imperfect source of
  randomness
• 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
34
Can we balance the KDF act? HKDF K10

• 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. fs)
• 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

35
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
  
  Ki1 HMAC(Kprf, Ki ctxt_info i)
• (HMAC as PRF in
  feedback mode)
• .

OR
36
HKDF Balance regained

• Practice HMAC already used as PRF, here re-used
  as extractor.
• Theory Detailed analysis DGHKR04,
  CDMP05,K10 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)

37
The Power of Proofsand Proof-driven Design in
Cryptographic ProtocolsSimple example
Asymmetric Key Wrapping and One-pass Key
Exchange
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 ABR01
• CCA-secure encryption, can transmit key and
  associated data
• Implicitly authenticates the intended receiver
  (the only one that can read the key/data)

39
Authenticated Key Wrapping

• DHIES implicitly authenticates the receiver
• Only intended receiver can read the key/data
• But how about senders authentication?
• Interestingly Just adding senders 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.

40
Authenticated DHIES and One-Pass KE

• DHIES is an instantiation of the KEM/DEM
  paradigm (Y,C,T)
• Key Encapsulation Ygy encapsulates KH(Ay) (A
  is receivers 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 HK11
  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 Aybe Receiver from Ya to
  (YBe)a
  

relation to signcryption Gorantla et al, Dent
41
Group Gltggt, hash function H, sym encryption Enc,
msg auth Mac

• DHIES
• Receivers PK Aga
• Sender chooses y, sends (Y,C,T)
  where
• Y gy s Ay K H(s)
  (2 expons)
  
• K ? K1, K2 C EncK1(M)
  T MacK2(C)
• Decryption sYa, etc (1 expon.)

• Authenticated DHIES
• Rs PK Aga Senders PK Bgb
• Sender chooses y, sends (Y,C,T)
  where
• Y gy s Aybe e H½(Y,idR) K H(s, idS,
  idR, Y) (2 expons)
• K ? K1, K2 C EncK1(M)
  T MacK2(C)
• Decryption s (YBe)a, etc (1.5
  expon.)

Just extra ½ exp for receiver. Free for sender.
No extra communication (true also when
considering co-factor exponn or group-membership
tests)
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
  bs owner
• Note Just adding a signature (say DSA) on top of
  DHIES is signifi- cantly more expensive, provides
  weaker authentication (attacker can learn
  someone elses M), and does not provides
  y-security

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

44
Concluding Remarks
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 ( its ok if the models are not
  perfect perfect models dont exist but w/o
  models and proofs we are left with words of
  gentlemen and broken designs)
• Its 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

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 its not just about what to use but how
  to use it

47
and most importantlyit requires
48
A challenging balancing act
exhilarating ___________
YOU
THANK