1. CRYPTOGRAPHic Protocols and Diffie-Hellman-Merkle Key Exchange
Dr. Suzanne Buchele
(A lot of content borrowed from Ed Crowley at The University of Houston)

2. Symmetric Cryptography Overview
Classic cryptography
Shared secrete key encrypts and decrypts
Fast
Ideal for bulk encryption
1000 to 10,000 times faster than public key cryptography.
Problematic Key Management
Both parties must already have the shared secret key
Does not scale well
A system with N users requires N(N-1)/2 keys
Can provide confidentiality, with other protocols also integrity, and authentication

3. Asymmetric Key Overview
Relatively new cryptographic technology
Utilizes two different, but mathematically related, keys.
Normally, public key is widely distributed
Only one person possesses private key (bound to identity)
A message encrypted with one key can only be decrypted with the other.
In most cases, utilizes a relatively large key
Solves classic cryptography key management problem
Only 2N keys needed for N entities
Relatively slow
Depending on how employed, may provide confidentiality, integrity, authentication, and/or non-repudiation
though, not all at the same time

4. Asymmetric Cryptography Algorithms
RSA
Used for encryption and digital signatures
El Gamal
Used in DSA, for digital signatures
Diffie-Hellman
Allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel.
Elliptic Curve
Uses algebraic system defined on points of elliptic curve to provide public-key algorithms
Of all public key systems, highest strength per bit
Requires less computational and memory requirements

5. Hybrid Cryptosystems
Typical hybrid systems use public key cryptography to distribute symmetric keys.
Asymmetric key for key distribution of symmetric keys
Symmetric key for bulk data encryption
Symmetric keys typically temporary session keys
Limited lifespan, so that quantity of data encrypted with any one key is limited
So cryptanalysis is hampered
Recall we don’t use previous symmetric keys to encrypt the next symmetric key, since compromise of any one key would compromise them all

6. Diffie-Hellman-Merkle Key Exchange
Subjects exchange secret keys over an insecure communications channel without exposing the keys
Introduced the notion of public key cryptography
Actually predates RSA
Used for symmetric key distribution
Not used to encrypt and decrypt messages.
Is a practical method for public exchange of a secret key
Used by IKE (Internet Key Exchange Protocol), a standard protocol used for secure communications in the IPsec protocol suite

7. Diffie-Hellman-Merkle Key Exchange (cont)
Used for two parties with no prior knowledge of each other or shared information to establish a common, shared key
Although communication between them is insecure, resultant shared key is secure
Seems like magic…
Based on principles similar to RSA cryptography
Exponentiation modulo a prime
Security relies on the difficulty of computing discrete logarithms
Given m, n, and y, can’t determine x such that
mx mod n = y

8. Diffie-Hellman-Merkle Summary
All users agree on global parameters:
Often proposed by entity initiating the key exchange
Large prime integer (or polynomial ) q
Also select g, a “primitive root” mod q
Each user (eg. Alice, Bob) generates their keys
Chooses a secret key (number): x < q
Computes their public key: y = gx mod q
Shared session key for users Alice & Bob is KAB:
KAB = gxA.xB mod q = (gxA)xB mod q = (gxB)xA mod q

9. Primitive Roots Recall Euler’s theorem: m(p-1)(q-1)mod p*q = 1
Consider: mk mod n = 1 for m, n such that GCD(m,n)=1
Know it works for k = (p-1)(q-1), but could be one smaller
If smallest is k = (p-1)(q-1) then m is called a primitive root of n
Has the property that successive powers of m (mod n) are all distinct (mod n)
E.g. m mod n, m2 mod n, m3 mod n, m4 mod n, ..., mk-1 mod n are all different and in the range 0...n-1 (by def of mod)
By using m, a primitive root of n, then it is hardest for someone to guess x such that mx mod n = y
This is the heart of the security of the Diffie-Hellman-
Merkle algorithm

10. Diffie-Hellman-Merkle Algorithm
Users Alice and Bob want to agree on a shared key
Alice chooses s large prime integer q
Example: q = 353
Alice also selects g, (preferrably) a primitive root mod q
Example: g = 3
Alice sends q and g insecurely to Bob
Alice and Bob each generate their keys
Alice chooses her secret key: xA < q
Example: xA = 97
Bob chooses his secret key: xB < q
Example: xB = 233

11. Diffie-Hellman-Merkle Algorithm (cont)
Global parameters: q = 353, g = 3
Alice’s secret key: xA = 97, Bob’s secret key: xB = 233
Alice computes her public key: yA = gxA mod q
Example: 397 mod 353 = 40
Bob computes his public key: yB = gxB mod q
Example: 3233 mod 353 = 248
So, public parameters: q = 353, g = 3, yA = 40, yB = 248
Shared session key for users Alice & Bob is KAB:
KAB = gxA.xB mod q =
(gxA)xB mod q = (yA)xB mod q (which Bob can compute)
(gxB)xA mod q = (yB)xA mod q (which Alice can compute)

12. Diffie-Hellman-Merkle Algorithm (cont)
Public parameters: q = 353, g = 3, yA = 40, yB = 248
Alice’s secret key is xA = 97
Alice computes the shared secret key:
(gxB)xA mod q = (yB)xA mod q = mod 353 = 160
Bob’s secret key is xB = 233
Bob computes the shared secret key:
(gxA)xB mod q = (yA)xB mod q = mod 353 = 160
So, both Alice and Bob arrive at the same shared secret key (160) with all communication between them done insecurely!

13. Diffie-Hellman-Merkle Uses and Security
Shared secret key is then the session key for symmetric encryption for one session of communication between Alice and Bob
For the next session, Alice and Bob need to choose new public keys
Or they will end up with the same session key
Public keys (prime number and exponents) are typically 1024 bits in length (≈300 decimal digits)
Attacker needs to be able to solve for x, given m, q, and y, where (discrete log problem):
y = gx mod q
No known algorithm to do this other than brute-force search

14. Cryptographic Protocols
A protocol is an agreed-upon sequence of actions performed by two or more entities
Cryptographic protocols make use of cryptography to accomplish some task (usually securely)
Example:
How can Alice and Bob agree on a shared session key to protect a conversation?
Answer: use a key-exchange cryptographic protocol
E.g. Diffie-Hellman-Merkle Key Exchange Protocol
There are others (some we have seen before…)

15. Key Exchange Using Only Symmetric Cryptography
Assume Alice and Bob each share a key with a Key Distribution Center (KDC)
KA is the key shared by Alice and the KDC
KB is the key shared by Bob and the KDC
To agree on a session key:
Alice requests a session key for Bob and her from the KDC
KDC generates a random session key, encrypts it with both KA and KB, and sends to Alice
Alice decrypts part of the message encrypted with KA and learns the session key
Alice sends part of the message encrypted with KB to Bob
Bob receives Alice’s message, decrypts it to learn session key
Alice and Bob communicate securely using the session key

16. Key Exchange Using Only Symmetric Cryptography
The key-exchange protocol:
A: => KDC (A,B)
KDC: => A (Encrypt(KAB,KA) || E(KAB,KB))
A: => B (Encrypt(KAB,KB))
Problems?
Replay attack:
An intruder, Eve, watches them do this and stores the KDC’s message to Alice and all the subsequent messages between Alice Bob encrypted with KAB
Eve cryptanalyzes the session and eventually recovers KAB
The next time Alice and Bob want to talk Eve intercepts the KDC’s reply and replays the old message containing KAB
Alice and Bob conduct a “secure” conversation which is
protected by KAB which is known to Eve

17. Simple Symmetric Cryptography Key Exchange Problems
Alice and Bob need to be able to distinguish between a current (or fresh) response from the KDC and an old one
Solutions:
Alice and Bob could keep track of all previously-used session keys and never accept an old session key
KDC could include freshness information in its messages
Nonces
Timestamps
Alice and Bob’s clocks must both synchronized with the KDC’s
Alice and Bob both check the KDC’s message to make sure it was generated recently

18. Key Exchange Using Only Symmetric Cryptography
N’s here could be Nonces or Timestamps

19. Key Exchange Using Public Key Cryptography (Simple Protocol)
Alice learns Bob’s public key (by either asking Bob or some third party)
Alice generates a random session key, KAB
Alice encrypts the session key with Bob’s public key
Alice sends Encrypt(KAB,BPublic) to Bob
Bob receives Alice’s message and decrypts it with his private key
Alice and Bob now share the secret key KAB and encrypt their subsequent communications with KAB

20. Simple Key Exchange Using Public Key Cryptography – Problem
Recall the man-in-the-middle attack:
If Eve can trick Alice into thinking that EPublic is Bob’s public key, then
Eve can decrypt Alice’s first message to Bob:
Encrypt(KAB,EPublic)
Eve learns the proposed session key KAB
Eve can send Bob: Encrypt(KAB,BPublic)
Alice and Bob will encrypt their subsequent communications with KAB thinking that it is secure
This can be a very serious problem because it’s sometimes difficult to be sure you know somebody’s public key

21. The Interlock Protocol, aka Bit Commitment (Not in Readings)
Combating the man-in-the-middle attack:
Alice and Bob exchange public keys
Alice encrypts her message using Bob’s public key. Alice sends half the encrypted message to Bob (e.g. every other bit)
Bob encrypts his message using Alice’s public key. Bob sends half the encrypted message to Alice (e.g. every other bit)
Alice sends the other half of her encrypted message to Bob. Bob puts the two halves together and decrypts them using his private key
Bob sends the other half of his encrypted message to Alice. Alice puts the two halves together and decrypts them using her private key

22. Why the Interlock Protocol Works
Assume Eve can trick Alice into using EPublic instead of BPublic
When Eve receives the first half of Alice’s message she won’t be able to decrypt it and re-encrypt it with Bpublic because it is only half of the encrypted message
You can’t decrypt half a message!
Eve must invent a completely new message, encrypt it and send half of it to Bob
When the second half of Alice’s message arrives, Eve can put the two halves together, decrypt, and learn what Alice’s original message was…
However, Eve has already committed to the first and second halves of the message and sent it to Bob, it is too late to change
Therefore Alice and Bob will be able to figure out that there is an intruder between them

23. Interlock Protocol and Public Key Crypto Key Exchange Protocol
The Interlock Protocol can be used with key exchange using public key cryptography to ensure that the information being sent back and forth is not subject to a Man-in-the-Middle attack:
When Alice sends the session key to Bob, encrypted with Bob’s public key, she first sends only ½ the bits
Bob sends an acknowledgement including a nonce, encrypted with Alice’s public key, but sends only ½ the bits
Then Alice sends the other ½ of the bits of the session key
Then Bob sends the other ½ of the bits of the acknowledgement and nonce
They should now share a secret key, Alice can send Bob’s nonce back to him using their newly shared secret key

24. Interlock Protocol Security
Bob won’t send the first half of his acknowledgement (encrypted with APublic) until Alice sends first half of proposed key (encrypted with BPublic).
If Eve tries to get in the middle, she won’t know how to decrypt ½ a message, and if she tries to make a message up, it won’t match the 2nd half of the messages that come later.
Alice doesn’t send the 2nd half of the proposed key until she receives the acknowledgement from Bob
If later 2nd half of acknowledegement, when put together with 1st half, doesn’t make sense, she knows there was a problem

25. One-way Authentication Protocol Using Symmetric-Key Cryptography
Assume that Alice and Bob share a secret symmetric key, KAB
One-way authentication protocol (Challenge and Response:
Alice creates a nonce, NA, and sends it to Bob as a challenge
Bob encrypts Alice’s nonce with their secret key and returns the result, Encrypt(NA, KAB), to Alice
Alice can decrypt Bob’s response and verify that the result is her nonce
A: => B(NA);
B: => A(Encrypt(NA, KAB));

26. Two-way Authentication Protocol Using Symmetric-Key Cryptography
Two-way authentication protocol (Challenge and Response:
Alice creates a nonce, NA, and sends it to Bob as a challenge
Bob encrypts Alice’s nonce with their secret key and appends his own nonce, NB, and returns the result,
NB || Encrypt(NA, KAB), to Alice
Alice can decrypt Bob’s response and verify that the result is her nonce, and send back to Bob Bob’s nonce encrypted with their shared secret key
A: => B(NA)
B: => A(NB||Encrypt(NA, KAB))
A: => B(Encrypt(NB, KAB))

27. Two-way Authentication Protocol – Problem #1
Eve tricks Bob into creating the correct response to the nonce for her:
A: => E(NA) (here Eve is impersonating Bob)
E: => B(NA) (here Eve is impersonating Alice)
B: => E(NB||Encrypt(NA, KAB))
E: => A(E(NB||Encrypt(NA, KAB))
A: => E(Encrypt(NB, KAB))
E: => B(Encrypt(NB, KAB))
This is the classic Man-in-the-Middle attack
Note that Eve still doesn’t know KAB, but, Eve is authenticated to both Alice and Bob
impersonating Alice to Bob and Bob to Alice

28. Two-way Authentication Protocol – Problem #2
Eve puts Alice on “hold” and then gets Alice to authenticate herself using the same Nonce Alice used!
thus getting Alice to create her own correct response for Eve!
A: => E(NA) (here Eve is again impersonating Bob)
E: => A(NA) (Eve turns is back to Alice!)
A: => E(Encrypt(NA, KAB))
E: => A(Encrypt(NA, KAB))
So, Eve is now authenticated to Alice as Bob
Note that again, Eve doesn’t know KAB, but, Eve is authenticated to Alice as Bob
Solutions?

29. Authentication Protocol Using Public-Key Cryptography
Could do the same one-way or two-way authentication using public-key cryptography:
Alice sends a nonce to Bob
Bob responds to the nonce by encrypting it with his private key and sending it back to Alice
Alice knows the response came from Bob, since only Bob could have encrypted with Bob’s private key, if it is successfully decrypted with Bob’s public key

30. Authentication Using Public-Key Cryptography - Drawback
Note that digital signatures are sometimes a public message encrypted using the signer’s private key
anyone can decrypt with signer’s public key and validate the signature
By using the previous public key authentication, Bob is essentially blindly signing something that he thinks is a nonce from Alice, but he really doesn’t know what it is or who it is coming from
someone could trick Bob into responding to a nonce that is really text that says, “Bob owes Eve USD $1 million”.

31. Authentication Using Public-Key Cryptography – Another Protocol
Another challenge-and-response authentication protocol:
Alice performs a computation based on some random numbers (chosen by Alice) and her private key and sends the result to Bob
Bob sends Alice a random number (chosen by Bob)
Alice makes some computation based on her private key, her random numbers, and the random number received from Bob and sends the result to Bob
Bob performs some computations on the various numbers and Alice’s public key to verify that Alice knows her private key
Advantage: Alice never encrypts a message chosen by someone else

32. Authentication AND Key Exchange Protocols
Combine authentication and key-exchange
Assume Carla and Diane are on opposite ends of a network and want to talk securely
Want to agree on a new session key securely
Want to each be sure that they are talking to the other and not an intruder

33. Authentication AND Key Exchange Protocol – Wide Mouth Frog
Assumes a trusted third-party, Sam, who shares a secret keys, KCS and KDS, respectively, with Carla and Diane
Carla generates a shared secret key, encrypts together with a timestamp, and sends to Sam
Sam decrypts and re-encrypts, updates timestamp, sends to Diane
C: => S(C,Encrypt((D,KCD,TC),KCS));
S: => D(Encrypt((C, KCD, TS), KDS));
Observations:
Reliance on synchronized clocks for timestamps
Depends on a third-party that both participants trust, may be a bottleneck
Initiator is trusted to generate good session keys

34. Authentication AND Key Exchange Protocol – Yahalom
Yahalom Protocol:
Uses nonces
Carla contacts Diane
Diane is the first one to contact Sam
Sam generates the session key and sends to Carla
Carla sends to Diane the information forwarded from Sam
C: => D (C,NC);
D: => S (D,Encrypt((C,NC,ND),KDS));
S: => C (Encrypt((D,NC,ND,KCD),KCS),Encrypt((C,KCD),KDS));
C: => D(Encrypt((C,KCD),KDS),Encrypt(ND,KCD));
Observations:
reply and man-in-the-middle attacks are all avoided

35. Authentication AND Key Exchange Protocol – Denning-Sacco
Denning-Sacco Protocol:
First three messages assure both parties have each others’ correct public keys (authentication)
Key exchange accomplished with last message
Including session key generated by Carla, and a timestamp
C: => S(C,D);
S: => C(Encrypt((C,CPublic,TS),SPrivate),Encrypt((D,DPublic,TS),SPrivate));
C: => D(Encrypt((C,CPublic,TS),SPrivate),Encrypt((D,DPublic,TS),SPrivate));
C: => D(Encrypt(Encrypt((D, KCD ,TC),CPrivate),DPublic));
Observations:
Addition of D in last message makes it secure against a spoof attack
someone with a valid session key with Carla claiming to be Carla to Diane

36. Next…
5 minute break, then Lab