[OTR-dev] a single secret key for all accounts?

[Patrick Baxter]

I'm assuming OTR verifies name at provider.tld is bound to public key X,
but I don't know the spec. In this case, to use the same key across
multiple names with the goal of reducing verification, i think you run
into the following problem:

1. You have trusted patch at dukgo.com and acquaintance called evil at dukgo.com.
2. Evil user creates patch at jabber.ccc.de with the same key from evil at dukgo.com.
3. You see that this key is trusted but confuse evil as patch

One option would may to check only the username so that
patch at dukgo.com must be the same as patch at jabber.ccc.de. This won't
work unless you can enforce that people using the same name field
always use the same key and are the same user which are not the
registration semantics of a federated system.

On Thu, Oct 31, 2013 at 7:47 PM, Hans-Christoph Steiner
<hans at guardianproject.info> wrote:
>
> Is there a particular reason why OTR apps generally create a new secret key
> for each account rather than generating a single key and using it for all
> accounts?  Our keysync app[1] is basically is a band-aid to ameliorate the
> proliferation of OTR keys, so I'm curious what issues we should be thinking
> about as we progress.  I've been thinking that the next step is that keysync
> should pick a single secret key and use it everywhere with the goal of making
> it more likely that both sides are using verified keys.
>
> [1] https://guardianproject.info/apps/keysync/
>
> .hc
>
> --
> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev