Forgot to add, that you could do this if you changed verification to be aware of a key-hierarchy so that if you verified [email protected] 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 <[email protected]> wrote: > 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
