On Wednesday 21 November 2007 01:46, Michael Rogers wrote: > Matthew Toseland wrote: > > You're talking about geeks. And even they don't usually go to the effort. But > > this whole conversation kicked off when you said files were inconvenient. :) > > They are inconvenient - if I could convince the rest of the world to use > short refs, I would. But not passwords, that would be a step backwards. ;-) > > > I still don't see how you are going to use them. Bob makes up a password and > > gives it to Alice out of band over the phone. Alice proves she has the > > password through a challenge/response. Alice gets 3 tries. What's the attack > > vector? > > Sorry, I misunderstood. I thought you were proposing that there should > be no up-front exchange of pubkeys/passwords, but after establishing the > connection it should be checked for MITM attacks by generating a > password from the JFK pubkeys and verifying it OOB (like Zfone does). > But you weren't, so forget I mentioned it and substitute my usual > objection to an up-front exchange of passwords: the users won't use a > secure channel, tampering with channels is harder than observing them, > so pubkeys are preferable to passwords.
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. I accept that wiretapping may be easier than MITM for some threat models e.g. it seems likely that most large scale infrastructure is built mainly for wiretaps, though we don't have full specs for these things! :) > > > Impossible without two way exchange of very long lines of text, with at least > > one way untamperable. Which is not remotely realistic, except in the trivial > > case of sending an encrypted email. > > 35 characters of base32 (IP + port + 128-bit pubkey hash) is not > remotely realistic? It's only four phone numbers! :-) 36 characters (you lost a bit). Hmmm. Does it provide sufficient security? 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? 61 characters may be too many. 51 plus email address (which hopefully the recipient already has) would be slightly better but somewhat convoluted and certainly slower. 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. How would this work? Alice and Bob send encrypted (obfuscated) handshake attempts to each other. Once they have added each other's refs, they respond to the handshakes and do diffie-hellman. If Mallory has seen both sides, he could have MITM'ed at this point. So Alice generates another password, which is sent out of band to Bob, Bob generates another password, which is sent out of band to Alice. Since we exclude weak keys, Mallory cannot make the crypto keys for both sides identical, so we do a challenge/response each way on H ( H ( link encryption key ) + H ( password ) ). We give 3 tries. If it doesn't work, we tell the user something bad has happened, possibly an attack, and they should exchange noderefs. The main practical weakness in this scheme AFAICS is that users won't believe it's an attack, (it might in fact not be, although we can include one character of redundancy; all these schemes depend on no font ambiguity!), and won't be bothered to do a full (61 chars) noderef exchange. The question is would they have bothered if it was an up-front cost? > > 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/a9b49775/attachment.pgp>
