CODEWITHSUNDEEP
encryptionpublic-key-encryption
Allan Jiang
Allan Jiang

Reputation: 11341

Encrypted Key Exchange understanding


I am trying to understand the Encrypted Key Exchange mechanism. I got a little confused with this illustration:
EKE
And did not find a lot of useful reference out there. Can anyone please explain the mechanism of EKE and how it works? What are the two sides exchanging and why that is safe to attack such as Man-in-the-middle? that will be greatly helpful.
Thank you.

Upvotes: 3

Views: 5884

Answers (1)

Kallex
Kallex

Reputation: 528

While trying to find an implementation of EKE or DH-EKE, I anticipate that there are quite limited amount of references out there. The Wikipedia cross-links to each/other and the explanations I bump into are not necessarily that easy to understand. The original patent of EKE expired on 2011, leading to my understanding EAP-EKE being published.

I found best explanation in "Applied Cryptography" by Bruce Schneier (2nd edition), including improvements to the algorithm. As you already have the image of the process, I'll try to layman-answer what happens there. I'm just learning myself, so I might mistake that image of yours, but it seems it's a DH-EKE implementation. I'll stick with EKE-idea on this answer, as that I think I've mostly understand ;-)

The basis is that Alice and Bob share a common secret. I might miss a point how "weak" it can be (in your image it's noted as weak), but let's assume it's a valid symmetric cryptography key.

Both parties have same symmetric key S, that's a shared secret

  1. Alice generates public/private key pair unique for the session Pa (private) and P'a (public) Alice encrypts public key using S and sends it to Bob.

  2. Bob (knowing S) decrypts Alices message and recovers Alice's public key P'a. Bob generates random session key K. Bob encrypts K with Alice's public key P'a and sends it to Alice.

  3. Alice decrypts the message and obtains K. Alice generates random string Ra, encrypts it with K and sends to bob

  4. Bob decrypts the message to obtain Ra, generates another random Rb, encrypts both with K and sends the encrypted message to Alice.

  5. Alice decrypts message, verifies her own Ra being valid in the message. She encrypts only Rb with K and sends to Bob.

  6. Bob decrypts Rb and verifies his own Rb being valid.

For Eve to pull off man-in-the-middle, she has only seen keys being encrypted with other keys. Guessworking the password from monitored traffic between Alice and Bob is not possible without cracking the public key algorithm as well. Weak shared secret however does allow Eve to try pretend to be Alice or Bob in the picture, so (my terminology may be flawed here) active attack against a listening server is possible to mount.

There are assumptions in the version that I described, best explained by others (published), Alice is trusted to generate good key pair, Bob is trusted to generate good session key. Also some algorithms suit better (or some quite much worse). There are things listed in the "Applied Cryptography", but as my 2nd edition seems to be a bit behind of things like AES, I'm trusting to dig more up-to-date information of good ciphers to choose for the algorithm.

For what it's worth, it seems that I need to implement EKE myself with C# and Java (Azure .NET back-end, Android client). I try to package it in a way that it could be useful for others.

UPDATE: Very straightforward implementation on C# is available at: https://github.com/kallex/sharp-eke-example

It's shortcutting few bits as it is now (just SHA256 of plaintext to use initial key), so take with caution. My current usage will machine-generate and distribute secure keys to both parties in separate channel, so I didn't need any more sophisticated implementation for this testbed.

Upvotes: 4

Related Questions