On Thursday 22 November 2007 01:23, Michael Rogers wrote: > 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.
Well, we can force them to do a verification (whether it's a good idea is another question). What we can't do is force them to do it securely. > > > 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.) True. > > 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. Depending on how careless the user is. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071122/fdbe57cd/attachment.pgp>
