[OTR-dev] Separate Fingerprint For Each Account?

[otr at synx.us.to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

I guess it could be a problem now that I think of it. Nobody's going to
be checking fingerprints every time they start a private conversation.
But putting in a few simple caveats will prevent this sort of
impersonation taking place. Supposing Joe were trying to take over Sam's
account. You could:

1) Pop up a dialog when a verified key shows up on a buddy it hasn't
shown on already. "This new account Sam is the same person as that old
account Joe". Only need to do this the first time such a change occurs
of course. Once the user's confirmed that, they have all the info they
need to make a decision.

2) Pop up a dialog when a verified key shows up on a buddy that has
already had a verified key associated with it, but this time ask them
whether they really want to trust that the key from "Joe" now overrides
the old key from "Sam"

Some combination of those two strategies should be quite enough to warn
when someone's account is getting hacked. (2) only would happen if Sam
also used OTR and had been verified with you before. Of course if Sam
never used OTR, and his account got hacked, there's no way to tell he's
not an impostor regardless of the key->account mapping. But if Joe used
the same key on Sam's account, even if he was hacking, you could still
tell that it was Joe. If Joe used a different key you would be unable to
verify it, obviously.

I'm not sure if this is a misunderstanding, but I did not mean that
there should be one key for all buddy accounts on your buddy list. I
mean that we only need one key for all accounts that you control and
accounts that you identify as. Of course I want a separate key for each
buddy who isn't the same person on a different account.

> But they are necessary, if the client has no way to know whether or not
> account A and account B are *supposed to* be the same person.

If they both can start an OTR session with the same key, with the same
fingerprint, then I think the client can conclude pretty confidently
that they are the same person. Whether it is supposed to happen or not
is an issue for the IM servers who obviously don't want anyone hacking
each other's account. But for the client, all they need is to be made
aware when someone's identity changes, and the user can judge at that
point whether it's kosher or not.

How about this then. Suppose with the current system Joe hacks Sam's
account, then sends you a message via Joe's account saying "This key on
Sam's account is verifiable". If you choose to accept that confirmation
from Joe, then Joe is free to use Sam's account verified. If you choose
to deny that, then Joe's stuck. It's the same as if with my hypothetical
system, Joe used the same key and saying "This key on Sam's account is
verifiable".

The fact Joe is using the same key for Joe's account and Sam's account
does not make it any less of a security concern than if Joe was using a
different key for Joe's account and Sam's account. You can confirm and
verify that both keys belong to Joe, but it'll still be a hacked
account. Thus you have to warn the user, no matter whether Joe's key is
verified or not, but only for possibly hacked accounts. Normally you
don't have to warn the user at all if the same key is on two accounts,
whether Joe's key is verified or not.

If Joe uses the same key when hacking Sam's account, he cannot lie about
being Joe. The key is the same, so he is easily identified, no matter
how convincingly he claims to be Sam. If Joe uses a previously unknown
account specific key, he could still use some form of subterfuge or
social engineering to trick you into thinking he's verifiable as Sam.
There's just no reason in my mind, to require that each account you own
has a separate OTR key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjUJOUACgkQB/meY5RuPPTHtACdFUCtcaVptAgkjlUTX0uWWSRu
6zwAnR+4OMYTYLt3CuJyyRlTlowlUpHP
=KOXK
-----END PGP SIGNATURE-----