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

[Hans-Christoph Steiner]

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:
> 
> evil at dukgo.com and patch at dukgo.com are both on our user's verified
> buddy list. No one's key has been compromised. evil at dukgo.com
> registers patch at jabber.ccc.de 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 evil at dukgo.com. He assumes that
> patch at jabber.ccc.de is the same as patch at dukgo.com because of the name
> association.
> 
> So I think you would still need to do either a simplified verification
> upon contact with patch at jabber.ccc.de to let the user know this is the
> same person as evil at dukgo.com 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 evil at dukgo.com will always appear under the
> name they originally verified this with to the user even if he is
> contacting you from patch at jabber.ccc.de.
> 
> On Fri, Nov 1, 2013 at 11:47 AM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>>
>> In your example, evil at 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
>>> patch at jabber.ccc.de with otr key X that is signed by master identity
>>> M, then if patch at dukgo has otr key Y and a signature from M, its all
>>> OK.
>>>
>>> On Thu, Oct 31, 2013 at 8:21 PM, Patrick Baxter <patch at cs.ucsb.edu> wrote:
>>>> 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
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81