2

I'm currently using Diffie-Hellman to encrypt data sent across an arbitrary link (can be ethernet, Wi-Fi, USB, bluetooth, etc), and I'm not a huge fan of the potential that DH is vulnerable to an active MITMA.

I came across Samy Kamkar's Anti-MITMA technique. Does anyone have any thought on how secure this is?

From my understanding, the above technique involves taking a password and using the shared secret as the salt, hashing them together, and sending the hash to the end host. If the end host does not know the password, then it can't reverse the hash, assuming it's prohibitively expensive to hash with the given function, and thus expensive to brute force in a short enough amount of time.

Or at least, I'd imagine that the generated hash can be used as the shared secret, thus saving us the effort of having to send the hash.

Sal Rahman
  • 631
  • 1
  • 5
  • 14

2 Answers2

3

From a quick look, this is reasonably secure against a network attacker. However, it requires the server to store the password as plaintext, which is discouraged. Secure password storage has been discussed at length on this site.

A somewhat similar protocol is SRP which achieves the same goals as Samy Kamkar without storing a plaintext password on the server. As a side benefit, it is actually slightly faster as one fewer round-trip is required to login.

As a more general point, the SRP protocol has been subject to detailed analysis and is thought to be secure. Samy's protocol has not (as far as I can tell) be subjected to the same rigour so there may be subtle issues. You should use SRP so you don't roll your own crypto.

Update - Another consideration is that Samy's protocol reveals a password hash to an active MITM attacker, which they could then brute force. This is quite a bad weakness, which SRP is not vulnerable to.

Community
  • 1
paj28
  • 32,906
  • 8
  • 93
  • 130
1

Not exactly a direct answer, but the comment section is too limited, so...

I might be blind (a sleepless night can do that for you) but that document describes a situation where you don't want nor need a Diffie-Hellman key exchange. In fact, it doesn't add anything to the security of the whole thing.

If both sides already have a shared secret (password in this case), and that secret is not known to the malicious adversary (Mallory in this case), then why would you go through all that trouble in the first place? After all, DHKE is used to share a secret over an insecure channel, if you have already done that you have no use for DHKE*. You can simply derive a symmetric key out of that secret and be quite confident that nobody can MITM you unless they get a hold of the said password. In pseudo-code, a straight-forward example:

a:
    password = 54321
    kdfParams = [salt, iterations, other] // depends on the KDF, some or all may be random
    secretKey = KDF(password, kdfParams)
    data = ENCRYPT(secretKey, "Hello, Bob!")
    a->b (data, kdfParams)

m:
    b->m<-a (data, kdfParams)
    // Doesn't know the password and have no use for the publically transmitted kdfParams
    // Can derive the secretKey only through brute-force,
    // so choose your KDF and password carefully

b:
    b<-a (data, kdfParams)
    password = 54321
    secretKey = KDF(password, kdfParams)
    data = DECRYPT(secretKey, data) // << "Hello, Bob!"

Works the other way around as well.

Of course, if Mallory somehow finds out the password, the whole hell breaks loose, but the referenced document doesn't help with that either. If you are worried about forward and backward secrecy, you can use the secretKey to HMAC the public part of the DHKE to thwart any MITM attacks and have a fresh sessionKey for encryption each time.

To conclude, the explained 'method' is no explanation at all and the author either doesn't understand what DHKE is used for, or I need to get some sleep.

* in this particular example, CodesInChaos raises a valid point on general usefulness of DHKE.

BeagleEagle
  • 194
  • 5
  • 1
    Even if you have a shared secret, there are at least two reasons to use DH: 1) Forward secrecy 2) The secret might have low entropy (e.g. it's a password). So a [socialist millionaire](http://en.wikipedia.org/wiki/Socialist_millionaire) style protocol that doesn't open up the secret for offline-brute force is beneficial. PAKE protocols were designed to deal with these issues. – CodesInChaos Mar 13 '14 at 10:10
  • There is no reason to use it in the way the problem is presented in the referenced document - there DH adds only to obscurity. Of course that DHKE has its own merits for ephemeral keys and consequently forward and backward secrecy. And yes, PAKE protocols should be used here instead, I just wanted to explain the principle behind. – BeagleEagle Mar 13 '14 at 10:20