[prev in list] [next in list] [prev in thread] [next in thread]
List: otr-dev
Subject: Re: [OTR-dev] a single secret key for all accounts?
From: Hans of Guardian <hans () guardianproject ! info>
Date: 2013-11-05 16:08:31
Message-ID: DFD4883F-1939-4B05-A1DF-4AA59646B9E5 () guardianproject ! info
[Download RAW message or body]
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@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@dukgo and
> patch@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@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@dukgo.com's
> > secret key, then evil@dukgo.com can easily manually copy his evil@dukgo.com
> > secret key to his new patch@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@dukgo.com and patch@dukgo.com are both on our user's verified
> > > > buddy list. No one's key has been compromised. evil@dukgo.com
> > > > registers patch@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@dukgo.com. He assumes that
> > > > patch@jabber.ccc.de is the same as patch@dukgo.com because of the name
> > > > association.
> > > >
> > > > So I think you would still need to do either a simplified verification
> > > > upon contact with patch@jabber.ccc.de to let the user know this is the
> > > > same person as evil@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@dukgo.com will always appear under the
> > > > name they originally verified this with to the user even if he is
> > > > contacting you from patch@jabber.ccc.de.
> > > >
> > > > On Fri, Nov 1, 2013 at 11:47 AM, Hans-Christoph Steiner
> > > > <hans@guardianproject.info> wrote:
> > > > >
> > > > > In your example, evil@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@jabber.ccc.de 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 <patch@cs.ucsb.edu> \
> > > > > > wrote:
> > > > > > > I'm assuming OTR verifies name@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@dukgo.com and acquaintance called \
> > > > > > > evil@dukgo.com. 2. Evil user creates patch@jabber.ccc.de with the same \
> > > > > > > key from evil@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@dukgo.com must be the same as patch@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@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@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
_______________________________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic