Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

So I\'m trying to properly implement the EKE protocol and I\'m using C# with the

ID: 651070 • Letter: S

Question

So I'm trying to properly implement the EKE protocol and I'm using C# with the Windows CNG and ECDH key exchange. I need to use this because it's FIPS certified and all that jazz.

So what I'm understanding about EKE is the fact that it depends on the fact that the public keys are completely randomized, therefore not verifiable plaintext. Otherwise it would be easy to run a dictionary attack against the protocol because the public keys are encrypted using the pre-known password.

Here's my problem: I noticed that in the CNG algorithm, the public key is a large byte array and it is completely randomized except for the first 6 bytes are always the same. From there on its completely randomized. This leads me to believe that if I wanted to run a dictionary attack against that, all I would need to know is what the first 6 bytes were and I could validate that I was able to decrypt that public key or maybe even brute force it.

To protect against this, I could easily truncate off the first 6 bytes and encrypt the rest of the completely randomized byte array with the password and then just add those 6 bytes back on either endpoint to calculate the secret key.

I'm pretty sure that's right but I'm discovering that cryptographic systems are fiendishly tricky and I wanted to run it past you guys to make sure I'm thinking about this correctly.

Explanation / Answer

Doing EKE over an EC group is a tricky (and is something that RFC6124 avoids). The problem, as you note, is preventing an attacker from being able to determine whether a possible decryption is impossible (and hence he can remove that potential password from the list); that turns about to be considerably more involved than you would expect.

Even if you skip the first six bytes, well, the EC X and Y coordinates are not actually randomized (even though they look random); these coordinates are actually integers (if you're doing even-characteristic EC, field elements, don't worry about the distinction) which are related by an equation (perhaps y2+ax=x3+b mod p) that's easy to check; this would easily allow an attacker to do a dictionary attack.

Now, all this can be handled; you can just use the X coordinate (ECDH still works just fine; however, your ECDH package might not support that), and you can deal with the problem that about half of the bit patterns are not possible EC X coordinates (and that's also easy to check); you could modify the encryption algorithm to deal with that as well.

On the other hand, all this is rather tricky for someone who isn't used to working with Elliptic Curves. I would strongly recommend that you use either EKE using a MODP group (as RFC6124 has; don't forget you have you use the nonstandard generators that RFC6124 has), or go with SRP.

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote