[OTR-users] new user, comments on authentication

[Gregory Maxwell]

On Nov 26, 2007 6:41 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> Indeed, if DH is weak, we're pretty much hosed all around.  The other
> problem is that requiring the shared secret to be entered before the
> first DH was calculated would have been bad for UI, and prevented
> agreement on the secret.

Eh, once the secret is agreed on (as it now does now, though perhaps
agreeing on a strengthened hash of the secret instead),  compute
secretID=PBKDF2('id' +lowerfingerprint+upperfingerprint+ secret)
savedsecret=PBKDF2('otr'+lowerfingerprint+upperfingerprint+ secret)

save the savedsecret along with the remote parties fingerprint.

Now, for all future times DH is run, also exchange secret ID  (in the
clear or with the encryption established the last time DH was run). If
both sides have matching secret IDs, they both XOR the savedsecret
into the DH derived key before using it.

Thus even if DH is weak, someone would need the secret or the
savedsecret from one of the computers to recover the messages.

Obviously the savedsecrets are a target for theft... but so are logs
and otr private keys. I'd really like it if my client could use the
gnome-keyring stuff to store an encryption key that protects my logs,
otr private keys, etc but thats outside of the scope of OTR.

Perhaps the additional DH weakness resistance is of too little value
to make this interesting, on the other hand it might be easier to
explain to people that they should authenticate so their conversations
are secured with a password than it is to explain that they should
authenticate to avoid MITM.

> As for normalization: that's hard to do when you don't know what the
> users will be entering.  But the users can say (in-band) "that
> restaurant we went to that time, all lowercase, no spaces".

Eh, the software could still apply a default normalization with the
assumption that they are writing text. For example:
s/(\s\s+)/ /g       //Fold all whitespace into a single space.
s/(^\s+)//g         //Squash all leading whitespace.
S/(\s+$)//g        //Squash all trailing whitespace.

Removing trailing punctuation, Folding case, Reducing repeated
characters to a single character.. all these might be reasonable.

Of course, doing this will lower the key entropy... but it would
mostly be reducing bad entropy that humans aren't likely to use.  If
users keys differ by only these factors it's really really unlikely
that the users choose a really clever password like
"<tab><space><space>The<space>dog<space>jumped<space><space>" and
there is a MITM who is right except for the spaces, but it is really
likely that someone just mistyped something.

It could probably go as far as running double metaphone on every
contiguous span of five or more ascii characters and still not really
reduce security.

Paul Wouters <paul at cypherpunks.ca> wrote:
>> As for normalization: that's hard to do when you don't know what the
>> users will be entering.  But the users can say (in-band) "that
>> restaurant we went to that time, all lowercase, no spaces".
>That's opening a dangerous door. If you have geo tagged flickr
>photos of that dinner that was memorable enough.

A MITM with the determination and resources to pull off monitoring the
conversation and conduct a quick real-time flickr search for the
involved parties, could probably find a pair of people to impersonate
the voices of the folks on the phone.  The phone is probably better
than a weak secret, but probably not better than a strong one.

Ian Goldberg <ian at cypherpunks.ca> wrote:
On Sun, Nov 25, 2007 at 10:07:47PM -0500, Gregory Maxwell wrote:
>> I also still run into cases where the OTR overhead makes hitting the
>> maximum message size in aim much easier, especially with HTML pastes.
>Are you still seeing this with 3.1?  Automated message splitting is
>indeed turned on in that version.

oh.. now that you mention it. Not on any 3.1 clients.  THANKS!

Ian Goldberg <ian at cypherpunks.ca> wrote:
[snip]
> I would much rather the users actually pick up the phone.  But they
> won't, and there's nothing we can do about that.  So we need to provide
> them a method that's at least plausible for them to use securely.
> We're definitely open to ideas of ways to make it as easy to use
> securely as possible.

Bonus prize if you can invent a web-of-trust authentication system
that uses common members on the users buddy-list without disclosing a
users social network to the whole world... ;)

[snip]
> We also want to see all messaging be secure and private.  Ideally, it'll be that way by
> default, and without the user even knowing it.

To really get there OTR needs to be included and enabled in quality
clients *by* *default*.  Half my AIM contacts have OTR ... but this is
only because 1/4 are Mac users with a client that has OTR by default.
 Asking windows contacts to switch clients is a tall request, but
pidgin has a lot of advantages over the default stuff. ... but to also
ask them to install OTR, oy.. thats starting to ask too much in some
cases.