In your example, e...@dukgo.com gets access to the secret key material, so all bets are off there. I don't think your scenario would be any different if each account had a separate key versus all accounts using the same key.
.hc On 10/31/2013 11:25 PM, Patrick Baxter wrote: > Forgot to add, that you could do this if you changed verification to > be aware of a key-hierarchy so that if you verified > pa...@jabber.ccc.de with otr key X that is signed by master identity > M, then if patch@dukgo has otr key Y and a signature from M, its all > OK. > > On Thu, Oct 31, 2013 at 8:21 PM, Patrick Baxter <pa...@cs.ucsb.edu> wrote: >> I'm assuming OTR verifies n...@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 pa...@dukgo.com and acquaintance called e...@dukgo.com. >> 2. Evil user creates pa...@jabber.ccc.de with the same key from >> e...@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 >> pa...@dukgo.com must be the same as pa...@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 >> <h...@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@lists.cypherpunks.ca >>> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
