[146853] in cryptography@c2.net mail archive
[Cryptography] Usage models (was Re: In the face of "cooperative"
daemon@ATHENA.MIT.EDU (Perry E. Metzger)
Sun Sep 8 15:51:58 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 8 Sep 2013 15:51:49 -0400
From: "Perry E. Metzger" <perry@piermont.com>
To: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <77E6AA7D-C8E2-4B40-82AD-7A3D866E41BC@lrw.com>
Cc: "Marcus D. Leech" <mleech@ripnet.com>, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter <leichter@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
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.)
It is a compromise, but one that fits with the usage pattern almost
everyone has gotten used to. It cannot be done with the existing
cloud model, though -- the user needs to own the box or we can't
simultaneously maintain current protocols (and thus current clients)
and current usage patterns.
Perry
--
Perry E. Metzger perry@piermont.com
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
