On Tuesday 20 November 2007 23:48, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Because it works immediately?
>
> Replying to an email is hardly arduous. The increase in convenience
> isn't worth the decrease in security in my opinion, but let's agree to
> disagree.
>
> > 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 there's a person listening, they can initiate a connection just as
> quickly as the intended listener. But if targetted surveillance is
> outside your attack model, fair enough. Like I said, too many spy films. :-)
:)
>
> >> Maybe. The rest of the world is moving away from sending passwords in
> >> plaintext.
> >
> > And towards what?
>
> Public keys. Gnutella and BitTorrent use anonymous Diffie-Hellman, WASTE
> uses public keys exchanged OOB, ask someone for a shell account and they
> won't send you the password in plaintext, they'll ask for an SSH or PGP key.
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. :)
>
> > 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).
>
> If the password is used for OOB verification then the hash collision
> doesn't need to be found in real time - keys for every possible hash are
> pre-generated and stored, and a suitable key is selected in real time.
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?
>
> Maybe the NSA has enough storage for 2^50 keys, maybe not... again, I'm
> probably being paranoid but I think we should stick to a security level
> of 128 bits.
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.
>
> >>> 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.
>
> Ah, I see. Yup, the encryption step seems to fix that, though at the
> cost of preventing both peers from generating their invites in advance,
> eg before a face-to-face meeting.
Indeed, which is yet another reason to support out of band one-way invites.
>
> 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/20071121/12c2e274/attachment.pgp>
