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 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 > firstname.lastname@example.org > http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ The cryptography mailing list email@example.com http://www.metzdowd.com/mailman/listinfo/cryptography