I'm assuming OTR verifies [email protected] 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 [email protected] and acquaintance called [email protected]. 2. Evil user creates [email protected] with the same key from [email protected]. 3. You see that this key is trusted but confuse evil as patch One option would may to check only the username so that [email protected] must be the same as [email protected]. 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 <[email protected]> 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 > [email protected] > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
