[OTR-dev] Multiple accounts
Callme Whatiwant
nejucomo at gmail.com
Tue Jul 2 17:03:42 EDT 2013
On Tue, Jul 2, 2013 at 6:48 AM, Jonas Wielicki <otr-dev at sotecware.net>wrote:
> On 02.07.2013 15:35, Kurt Roeckx wrote:
> > I seem to be more and more going to a PGP model, and have
> > to wonder if it's possible to use my GPG key for OTR.
>
> Honestly I think that the absence of many of the PGP features is the
> strength of OTR. OTR is so incredibly easy and, in my opinion, the only
> current example of strong crypto done right (from the user experience
> perspective).
>
>
+N for some very large N.
OTR's strength *comes* from the lack of such features. If users are lead
to believe "one fingerprint per (account, device)" this has two desirable
qualities:
First, they will understand the scope of verifying a fingerprint: It is
specific to a particular device and account. What if my friend's phone is
stolen? If I have separate verifications for their laptop versus their
phone, I don't have to know how to use any software tools whatsoever
(assuming the client shows this distinction!), I simply stop trusting my
friend's phone.
By contrast if there's some "tech" for associating and revoking keys, who
successfully use that? Average users will not practice revocation, because
it is a rare event, and so when their phone is stolen they won't know what
to do. If sharing keys across devices or accounts is common (because, IMO,
we've *miseducated* the user base), then what do they tell their friends?
"Oh, hey, stop trusting my phone, but you should still trust my laptop
access." How do they specify this?
Also, think about the usability? How do they associate keys between
accounts or devices? Every client will have a different UI. Which users
will get this right? Only some of them. Therefore the ecosystem will be
filled with confusion: "some people share a single fingerprint among
multiple accounts and/or devices, but other's do not, so now that I'm
talking to my friend Alice, which category is she in?" "Alice knows how to
share keys between devices/accounts, and I know she sync'd her identity
between her gchat account on her phone and her laptop, but what about her
home desktop?" etc...
That kind of usability confusion == making the wrong assumptions about
authentication == security vuln.
Security is only as strong as its usability.
> Adding complications such as key sync, key management, revocation etc.
> is not what I consider useful for the general case.
>
>
+1
Here's another thought experiment:
Count the number of people who have "correctly" verified their friends OTR
fingerprint. Of those, count the ones who have "the correct" belief about
the security implications and the risks they face because of that.
Now, do the same for PGP key verification. Add on key signing. Add on
transitive web of trust. Add revocations.
It's no wonder that PGP software is unusable[1], because every
implementation foists all this complexity (which I posit most users ignore)
on users. My intuition is that each usability foible in the "PKI
mentality" leads to first, an order of magnitude fewer attempted users, and
then within that set *another order of magnitude* fewer users who have
"correct" beliefs about the implications of their usage.
[1] Here, when I say "unusable" I don't mean by geeks. I mean by my mom
and my non-computer friends who anecdotally have successfully used OTR but
who have never successfully used PGP. The primary reason for this is that
I can explain how to use OTR in about 15 minutes to my mom, but I haven't
even dared to explain PGP.
I'd love to see actual empirical data about those counts above. Is anyone
aware of any?
> regards,
> Jonas
>
>
Opinionatedly yours,
callme whatiwant
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20130702/74f4898d/attachment.html>
More information about the OTR-dev
mailing list