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

[Hans of Guardian]

I have this vague feeling that there is a simple elegant solution to how to represent this, but it escapes me now.  I think #3 is a good solution for now, its relatively simple to implement, and probably won't be triggered very often, so most users won't be fatigued when they see it.

.hc 

On Nov 4, 2013, at 3:56 PM, Patrick Baxter wrote:

> Thats a good point that this is purely a UI/human-understanding based
> issue since its all about how visible the human-readable aspect of the
> name is.
> 
> I was wrong in one of the earlier posts that linking accounts through
> a key-hierarchy would solve it at all as well.
> 
> I think anytime you associate a new human-readable name with a
> public-key you have this problem. I can think of 3 ways around it:
> 
> 1) When you verify someone the first time, you require the user to
> actually pin a unique local nick to that key. If that key can be
> talked to at multiple accounts, it is inconsequential since their nick
> always appears in chat.
> 
> 2) You always display to the user the first account that they verified
> (evil at dukgo in the example) even if evil is using new xmpp accounts
> 
> 3) A public key is associated with a set of addresses (like a pgp key
> with multiple idents), anytime that set is updated, a user must be
> shown the new list and agree to it.
> 
> Option 1 and 2 are similar and maybe the simplest to the user. Option
> 3 I would personally like because its more explicit about which
> account someone is using, but requires a user click through that could
> be ignored. You could also passively group contacts in the UI with
> option 3 but, that might not be seen or noticed either.
> 
> Its kinda a subtle problem though and is a result of the human
> tendency to associate two federated accounts (patch at dukgo and
> patch at jabber) that in the system, are not semantically related.
> Requiring uniqueness of the first name would be cool, but require a
> central registrar and could be more problematic for people hogging
> namespaces or not getting the one they want.
> 
> On Mon, Nov 4, 2013 at 7:47 AM, Hans-Christoph Steiner
> <hans at guardianproject.info> wrote:
>> 
>> But now that I think about it, having keysync make the chat apps use a single
>> key would not change this issue.  If our user validated evil at dukgo.com's
>> secret key, then evil at dukgo.com can easily manually copy his evil at dukgo.com
>> secret key to his new patch at jabber.ccc.de account, having the same effect.
>> 
>> So the issue that you illustrate here is not with having one key for all
>> accounts, but instead with the OTR apps not representing this info in the UI.
>> The chat app's UI really needs to make it clear which accounts are using a
>> given key.
>> 
>> OpenPGP deals with this by having the account ID (email address) as part of
>> the signed data in signed key, so there is a cryptographic link between the
>> accounts sharing a given key.  But I'm not sure many email apps do a good job
>> of representing this to the user either.
>> 
>> .hc
>> 
>> On 11/04/2013 10:39 AM, Hans-Christoph Steiner wrote:
>>> 
>>> 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