Matthew Toseland wrote: > We could combine the two: do challenge-response on the hash of both keys > encrypted using the password. This would defeat Mallory if he has MITMed but > doesn't know the password.
So the initial invitation would be IP:port:password, and the verification would be H(temp_pubkey_1 + temp_pubkey_2 + password) or E(password, H(temp_pubkey_1 + temp_pubkey_2)) or something like that? I suppose that would solve the port scanning problem mentioned in my other email: the initiator could present the hash of the password in the first JFKi message. But it wouldn't solve the problem of people skipping the verification step. > SHA-1 (160 bit) is looking rather weak at the moment, and there are some > theoretical attacks on SHA-256 iirc (?); is a 128-bit slice of a probably > weak hash likely to be even remotely safe? It's safer than a password! Bear in mind that the property we need is second preimage resistance rather than collision resistance: we don't care if the attacker can find two keys with the same fingerprint as long as she can't find a second key with the same fingerprint as ours. As far as I know, SHA-1 is still considered safe in terms of second preimage resistance. (Obviously it will be broken one day, but so will everything else.) Truncating the hash should be safe, it's often done in HMAC for example: calculate the hash and then chop it down to your desired security level. > We would therefore have to combine this with out of band password > verification. Which begs the question of why not simply use that in the first > place, and drop the pubkey hashes in favour of short obfuscation/identity > passwords (say 10 characters; long enough that online brute-force is > impossible), and OOB verification. And the answer is still "because passwords shouldn't be sent in plaintext, but users will do it anyway". :-) Seriously, if you're worried about an attacker cracking a 128-bit hash in real time, you should probably also worry about straightforward eavesdropping. Cheers, Michael
