[OTR-dev] Separate Fingerprint For Each Account?

Ian Goldberg ian at cypherpunks.ca
Thu Sep 18 10:37:13 EDT 2008


On Wed, Sep 17, 2008 at 07:45:29PM -0700, otr at synx.us.to wrote:
> Ian Goldberg wrote:
> 
> > If I've verified that the AIM id "fooman" has
> > a particular key, should OTR (technically, pidgin-otr, Adium, Kopete,
> > Psi, etc.) automatically believe that "fooman at foo.com" on MSN
> > and "fooman at jabber.de" on XMPP can be correctly authenticated with
> > that same key?
> 
> Assuming an attacker with fooman at jabber.de on XMPP is trying to
> impersonate "fooman" on AIM, but does not have the key that "fooman" on
> AIM has, how could he possibly produce the same OTR fingerprint, even if
> it's from an account that the real fooman does not control?

If the IM client automatically treats "similar" IM names as the same
person, then if you have two friends that happen to have similar IM
names, they could impersonate each other.

> It's my opinion that identity should start from within the encryption,
> and what account you log into outside of that is not something that can
> be automatically trusted.

Sure, and what you say after that is at least mostly reasonable.  But
that's not how IM clients treat identity today.  Remember that most OTR
users have no idea what a key or a fingerprint is.  If the user
authenticates the buddy "fooman" on AIM, that creates a binding between
that fingerprint and the person he knows as "they guy who has the fooman
screen name on AIM".  If that same key shows up on another account,
the IM client has no way to tell the user "although you're talking to
fooman at jabber.de, this person is actually the guy who has the fooman
screen name on AIM".

On the other hand, if you *did* write an IM client with a user-centric
notion of identity, I'm pretty sure you could use that identity as the
binding for the fingerprint instead of the screen name (with the
existing libotr).  Not positive, though; it may depend on the details of
your implementation.

   - Ian



More information about the OTR-dev mailing list