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

[Hans-Christoph Steiner]

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