Ah, ok, I see what you mean now. Yes, that is an issue. The accounts that share the same private need to be represented in the UI for this to work. This is the hard part of having OTR as a plugin to chat apps. From the user perspective, it really should be integrated into the user accounts.
.hc On 11/01/2013 03:15 PM, Patrick Baxter wrote: > Hmm, maybe i am confused but let me try explain again. I think the > issue here is that you must now auto-verifiy public keys that you have > previously trusted on your buddy list with out any limit on the new > name its bound too. This could confuse a user about who they are > talking to unless you can explain the trust relationship from that > last verified key. Without doing that you have the problem: > > [email protected] and [email protected] are both on our user's verified > buddy list. No one's key has been compromised. [email protected] > registers [email protected] and talks to our user. Our user see's > this this new patch account as verified because he has previously > verified this public key for [email protected]. He assumes that > [email protected] is the same as [email protected] because of the name > association. > > So I think you would still need to do either a simplified verification > upon contact with [email protected] to let the user know this is the > same person as [email protected] or maybe just display the name used for > the first confirmation and hide this information from the user. This > way the public key used by [email protected] will always appear under the > name they originally verified this with to the user even if he is > contacting you from [email protected]. > > On Fri, Nov 1, 2013 at 11:47 AM, Hans-Christoph Steiner > <[email protected]> wrote: >> >> In your example, [email protected] 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 >>> [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 >> >> -- >> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -- 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
