Matthew Toseland wrote:
>> 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.
I don't see why a one-way encrypted email is massively more convenient
than a two-way encrypted email - maybe we should use pubkey hashes
instead of passwords in this method as well, so it still offers
reasonable security if the email isn't encrypted.
>> 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.
I was assuming that the phone was tapped too. Maybe I've been watching
The Lives of Others too much recently.
>>> 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.
Maybe. The rest of the world is moving away from sending passwords in
plaintext.
> 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.
OK, if you think 50 bits is adequate then let's make the pubkey hashes
50 bits long as well. No sense demanding one level of security if the
exchange happens before the connection and a different level of security
if it happens afterwards - the attacker will attack the weakest point.
But let's be honest, 50 bits is not a decent security level. Even DES is
64 bits. ;-)
> We can limit his search time by using a temporary key which is
> changed every month/week/day/hour to limit this.
Possibly... it would require loose clock sync, and the connection hasn't
been established yet so we can't sync the clocks that way. But it's
probably not a show-stopper, we should encourage users to keep their
clocks accurate for anonymity purposes anyway (eg timestamps on Frost
messages). So do you think all invites should be time-limited?
> 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.
Could you describe exactly which mechanisms you mean to combine, and
how? Are you talking about a two-way exchange of time-limited passwords
followed by OOB verification using another two-way exchange of passwords?
> A -> B: H(tempKey_A)
> B -> A: E_(tempKey_A) { H(tempKey_B) }
Sorry, I don't see how this buys us any extra security. If we're using
pubkey hashes it doesn't matter whether the exchange is unobservable (or
rather, the observer only learns that an exchange has taken place, but
can't connect to either party).
Cheers,
Michael
