[OTR-dev] Separate Fingerprint For Each Account?

Donny Viszneki donny.viszneki at gmail.com
Fri Sep 19 22:25:53 EDT 2008


On Fri, Sep 19, 2008 at 6:17 PM,  <otr at synx.us.to> wrote:
> Ian Goldberg wrote:
>> That doesn't work.  If I'm your buddy, and you've verified my key, I'd
>> be able to impersonate any of your other buddies.
>
> Not true. If I verified your key, that wouldn't give you any inherent
> ability to hack into my buddies's instant message accounts. If you did
> then sure, you could impersonate them, but that's true even without OTR
> involved. If my buddy himself had his own key, then even if you did hack
> his account, you could not duplicate his fingerprint.

One of the principal purposes of OTR is to protect against the
scenario in which an attack can send your IM client forged
messenger-service messages that appear to be from another user. By
adding end-to-end encryption, OTR prevents this attack from working,
whether the attack vector is through your buddy's network connection
to the messenger service, your buddy's messenger service account, the
messenger service itself, or your connection to the messenger service.

Also:

What you seem to want mostly out of this is auto-verification of keys
where it is applicable. If that's correct, I propose a different
solution: the addition of a new OTR plugin message (which need not be
part of the core OTR protocol and library, but could belong only to
OTR plugins, based on my understanding of how OTR and OTR plugin code
is organized) which would allow one OTR plugin to tell another OTR
plugin which keys it has "verified."

You could even introduce multiple gradations of "verification." The
usefulness of this feature would accomplish most of what you want (if
I understand correctly that you mostly want automatic, painless
verification of multiple accounts belonging to the same user) plus
much more. It could provide even greater security and convenience at
the same time. I've considered the idea for quite a while, I just
haven't had time to write extensively enough about it to make a formal
proposal.

-- 
http://codebad.com/



More information about the OTR-dev mailing list