On Tuesday 20 November 2007 01:45, Michael Rogers wrote:
> Matthew Toseland wrote:
> > 1. Electronic but out-of-band or strongly encrypted.
> > Encrypted email, USB key etc. One way invite, no need for a return trip
unless
> > we need to update IP addresses. Generate a bundle including the node.
>
> If we offer a method designed for encrypted email, people will use it
> with unencrypted email.
True, but is that our problem? Especially if we ask the user and offer
something comparable but slightly more difficult for other cases? Maybe we
should only offer it in advanced mode - but it would be very useful for users
who really can do this.
>
> > 2. Email, IM, etc.
> > Reliable way to transport even large refs. 38 or 70 bytes is easier than a
> > full ref because it can be more easily cut and pasted, doesn't need to be
a
> > file transfer. Can be observed: the only way to do this securely is to
have
> > an out of band password verification over the phone.
>
> This sounds like the best solution to me: a two-way exhange of pubkey
> hashes followed by OOB password verification.
It does seem a good option. But see the note at the end.
>
> > 3. SMS, phone, print.
> > Must be really short! So much so that there is no possibility of
cryptographic
> > protection in the sense you have been using it.
>
> In that case we shouldn't offer this option.
>
> > IP + port + one time
> > generated password with enough entropy that it can't be brute forced in
the
> > time available (say 10 characters base64).
>
> The attacker doesn't need to brute force the password, it's in plaintext!
Not if it's exchanged over the phone. Which it could be.
>
> > Probably need to exchange both
> > ways, but maybe we can detect that somebody is trying to connect with a
> > specific invite.
>
> How can we distinguish the attacker from the invitee if we don't even
> have the invitee's IP address?
We can't, if he has the password.
>
> > We must not sabotage security for those who do the right thing in order to
> > make life easier for those who don't!
>
> Agreed. We also shouldn't make it easy to do the wrong thing.
>
> > If we use user-entered passwords they would be less easy to identify
(given we
> > only allow one or two attempts). Just a thought.
>
> Hmm, good point.
This is part of the reason that I suspect that a passwords-only approach may
be viable.
>
> >> We can make it safe if we know which side is OOB and we also assume it
> >> can't be eavesdropped (eg your one-time invite proposal). But IMO that
> >> assumption is too risky.
> >
> > It depends on what the user is doing with the invite. If the user is
sending
> > it in an encrypted email for example, it's fine.
>
> Right, but we don't know what the user's doing with the invite, so we
> have to make fail-safe assumptions.
>
> > I don't understand this. He doesn't know the password. He doesn't know the
> > hash of the password.
>
> Maybe I've misunderstood - I thought you were talking about not
> exchanging any pubkeys or passwords up front, just making the connection
> and then generating a password from the pubkeys exchanged during
> handshaking to make sure the connection hadn't been hijacked. If that
> was what you meant, here's the attack:
>
> Normal scenario: Alice connects to Bob. They exchange public keys during
> the handshake. They each hash the two public keys to obtain a password.
> Alice calls Bob or vice versa, and they check that the passwords match.
>
> Attack scenario: Alice connects to Mallory; Mallory connects to Bob.
> Alice and Mallory exchange public keys; Mallory and Bob exchange public
> keys. Mallory can use a different key on each side of the connection.
> When talking to Bob, she uses a key that will hash to the same password
> as Alice's key. When talking to Alice, she uses a key that will hash to
> the same password as Bob's key. So when Alice calls Bob or vice versa,
> the passwords match and they don't detect Mallory in the middle.
Hmm. So the first say 30 bits of the hash will be used to derive the password.
Mallory gets a public key from Alice (A1), and sends any key he wants (M1) to
her. Then he (Mallory is traditionally male) gets a public key from Bob (B1),
and computes a new pubkey such that H_30(M1 + A1) = H_30(M2 + B1).
So we would have to exchange enough bits to make this infeasible ... 50 bits
is 10 characters in base32 (more friendly than base64). Still quite feasible
imho; some CD keys are that length and they are often exchanged over the
phone for nefarious purposes.
Can Mallory stretch the exchange out to a long period so he might be able to
brute force search in that time? Maybe - JFK doesn't exchange pubkeys until
phase 2 and 3, so if Mallory can arrange to always be the initiator, he may
be able to get hold of the pubkey and do a search while appearing to be
offline. We can limit his search time by using a temporary key which is
changed every month/week/day/hour to limit this.
>
> This only works if Mallory can find a key for every possible password.
> But since the passwords are short, that's no problem: she can generate
> keys in advance for every possible password and pick a suitable one
> during the attack.
They're not (necessarily) that short.
We can also harden this by having short, easy to remember, hard to identify in
traffic, user-entered passwords for each side of the exchange. The various
mechanisms combined yield something which IMHO is adequately secure for many
cases, although it is 3-4 trips so exchanging pubkeys may be easier in many
cases. I'm not sure about this though: the first two messages may well be
exchanged offline (IP+port+password on a business card / email / piece of
paper / some other non-real-time form of communication), the last two are a
phone call which can include updating IPs if the nodes are not handshaking.
>
> > In some cases it is easy to do a secure exchange of invites. And
everything
> > else seems to offer less security!
>
> Yes, everything's less secure than a secure exchange. But some people
> (IMO most people) won't make a secure exchange. So how do we maximise
> security for the majority without harming the minority?
>
> Pubkey hashes are more secure than passwords - both approaches are
> vulnerable to MITM, but passwords are also vulnerable to eavesdropping.
> OOB verification adds an extra layer of security for those who can be
> bothered to use it, and doesn't harm those who can't.
>
> > If we do a two-way exchange of pubkeys,
> > and one side is OOB, then an attacker can easily get connected to Alice
but
> > not Bob, if we don't do any kind of OOB checking.
>
> Yes, MITM is possible if the pubkeys aren't exchanged or checked OOB.
> I'm not disputing that. But passwords are worse!
With the original invites scheme, as long as the first side is unobservable,
whether the return trip is visible does not matter. So we need to update the
two-way exchange proposal: we exchange an invite in each direction:
A -> B: H(tempKey_A)
B -> A: E_(tempKey_A) { H(tempKey_B) }
>
> 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/20071120/43ffa297/attachment.pgp>
