On Tuesday 20 November 2007 18:31, Michael Rogers wrote:
> 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.
Because it works immediately?
>
> >> 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.
Doesn't matter. They'd have to feed it in before the person hearing does;
voice recognition isn't that good, even if you can have it automatically
figure out that it's a password.
>
> >>> 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.
And towards what?
>
> > 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 are not talking about the same thing here. The 50 bits above are for a
one-use password which is exchanged once, and cannot be cracked offline. It
cannot be brute-forced, and it would have to be executed in real time (a few
seconds in fact).
>
> > 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?
You just have to keep the previous one as well.
>
> > 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?
Yes.
>
> > 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).
Not true. If he cannot observe one side but can MITM the other side, he can
get connected to one party but not the other.
>
> 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/d18621c6/attachment.pgp>
