[OTR-users] new user, comments on authentication

[Gregory Maxwell]

On Nov 25, 2007 6:20 PM, Harlan Iverson <h.iverson at gmail.com> wrote:
> Hi,
> I am a new OTR user and have shared it with a few of my privacy conscious
> friends. Overall, getting it going using Pidgin has been an extremely smooth
> experience, but one hiccup has been explaining authentication. The two
> people I use OTR with now are 'authenticated', but only in that we have
> confirmed each others' keys (advanced > [I Have] ...); when I mentioned
> authenticating using some secret that we both know, like the name of a place
> that fits some description, they became confused. If privacy conscious
> hackers don't understand without reading a lot of documentation, I think
> there is a weakness in usability.

Long time OTR user here.  With the new authentication mode I took the
opportunity to get some more of my contacts using OTR.  I found that,
as in the past, my contacts had no trouble with the general concept of
authentication but getting them to understand that the match is not
fuzzy and must be exact was hard.  They all seemed to think that the
text in the dialog would be shown to me and that I would approve it.
ugh.

Perhaps changing the dialog so that it asks for a "passphrase" might
make it more clear that the  spacing matters.   If this results in
people being mislead into thinking the passphrase will be used to
encrypt their communication, then so be it. I think that would be
better than the current state.

It might also be worthwhile to explore including normalization, i.e.
case-folding and whitespace removal. That would reduce security, but
any secret which is weak after normalization was probably weak before
normalization.

All in all I'm happy to see this new authentication mode in OTR,
thought I would have preferred an alternative design
(http://lists.cypherpunks.ca/pipermail/otr-users/2006-March/000602.html,
I prefered the idea of using a strengthened additional shared secret
as an additional input to the symetric cipher to avoid DH weaknesses).

On the subject of OTR usability I still frequently suffer from the
"multiple client problem" with AIM users, where a user logs in
multiple OTR enabled clients and all respond to my OTR messages.  This
especially problematic with the Mac contacts that I have who run OTR
without even knowing it.  While it is really good that OTR is enabled
by default for these users, they get really confused when we run into
a multiple client issue.

This family of problems has resulted in a few of my contacts keeping
OTR disabled most of the time, so at least as far as my contact go
it's still a larger security problem than the authentication issue.

I also still run into cases where the OTR overhead makes hitting the
maximum message size in aim much easier, especially with HTML pastes.
It's not obvious to users that OTR is causing their suffering, so it
doesn't get turned off in response.  I understand that the requirement
for blind forgability pretty much rules out compression (which is too
bad because algorithms like XML-WRT w/ dictionary do an amazing job
averaging 6.886 bits per char on my shortest messages and 3.2 bits per
char on my size-rejected IMs) ... but automatic message splitting
would be really nice.  Even if you had to manually set the MTU.