On 10 Sep 2013, at 17:07, Walter van Holst wrote:

> On 08/09/2013 21:51, Perry E. Metzger wrote:
>> On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter <leich...@lrw.com>
>> wrote:
>>> Even for one-to-one discussions, these days, people want
>>> transparent movement across their hardware.  If I'm in a chat
>>> session on my laptop and leave the house, I'd like to be able to
>>> continue on my phone.  How do I hand off the conversation - and the
>>> keys?
>> I wrote about this a couple of weeks ago, see:
>> http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html
> Which is pretty spot-on and one of my biggest gripes about OTR. It just
> doesn't mesh at all with user's expectations.
>> In summary, it would appear that the most viable solution is to make
>> the end-to-end encryption endpoint a piece of hardware the user owns
>> (say the oft mentioned $50 Raspberry Pi class machine on their home
>> net) and let the user interact with it over an encrypted connection
>> (say running a normal protocol like Jabber client to server
>> protocol over TLS, or IMAP over TLS, or https: and a web client.)
> Sounds like another Freedom Box...
> Anyway, if we consider each device an end-point to a group-chat that has
> to be verified at least once by another end-point (and that is a
> somewhat doable thing, e.g. the socialist millionaire's problem), what
> about having end-points being able to vouch for other end-points?

It's not a dumb idea at all but getting the 'introduction' mechanism right is 
tricky.  I've 
implemented something similar where we 'trust' the first endpoint and then 
allow that well verified device to be
bound to other entities.  The mechanism I built was that each one gets its own 
identity and can be
peer'ed into a conversation and that the group can in fact decide if it wants 
to allow
the arrival of 'Walter on his Tablet' or 'Walter on his phone' depending on 
your level of paranoia
or that of the group.  I don't mind Walter on his PC at work but I don't like 
sending these messages
to Walter on his phone especially when I know he has a habit of leaving his 
on the bus.

> For example if I introduce my smartphone to an already existing instant
> messaging chat, I can vouch for it through my PC and if other end-points
> already trust my PC, there is no reason not to trust my smartphone either.

 I've implemented the primary notion around a phone because it's a simple
identity, it doesn't change much and it has multiple an out-of-band delivery 
channels which lends itself  to multiple authentication factors.

> If this is a dumb idea, feel free to point it out.

It allows other possibilities too, for instance, you can nominate the in-use 
end point and temporarily
suspend others or even kick them out by refusing to complete an MPC protocol 
with them, exchange
new keys and carry on the discussion.

The idea of multiple sub-idenities lends itself well to keys which have 
different lifecycles. So chat
for example, where a transient set of keys which, if lost isn't a massive 
problem but email for instance
where loosing them and having stacks of encrypted email in your inbox which is 
now useless is unhelpful.

I'm literally just in the process of building the master entity as a smart card 
component which can be used 
to 'introduce' the first device on an NFC capable android platform.  From  
there you can bootstrap the 
other devices.

What I don't know the answer to yet is if material changes need to be 
notionally signed by the master entity
or if introductions can be done by devices as peers.  Of course, compromise one 
device and it winds up
with peer introducing rights.  There is a usability trade off and I suspect 
until I've 
actually tried using it the answer is non obvious.


> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

The cryptography mailing list

Reply via email to