[Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)

Max Kington mkington at webhanger.com
Tue Sep 10 16:22:40 EDT 2013


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 <leichter at 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 phone
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.

Regards,
Max

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



More information about the cryptography mailing list