Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On 08/09/2013 21:51, Perry E. Metzger wrote: > I wrote about this a couple of weeks ago, see: > > http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html In short, https to a server that you /do/ trust. Problem is, joe average is not going to set up his own server. Making setting up your own server user friendly is the same problem as making OTR user friendly, with knobs on. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On 08/09/2013 21:51, Perry E. Metzger wrote: > On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter > 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? 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. If this is a dumb idea, feel free to point it out. Regards, Walter ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
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 >> 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@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On Sep 8, 2013, at 11:41 PM, james hughes wrote: >>> In summary, it would appear that the most viable solution is to make >> I don't see how it's possible to make any real progress within the existing >> cloud model, so I'm with you 100% here. (I've said the same earlier.) > Could cloud computing be a red herring? Banks and phone companies all give up > personal information to governments (Verizon?) and have been doing this long > before and long after cloud computing was a fad It's a matter of context. For data I'm deliberately sharing with some company - sure, cloud is fine. As I mentioned elsewhere, if the NSA wants to spend huge resources to break in to my purchasing transactions with Amazon, I may care as a citizen that they are wasting their money - but as a personal matter, it's not all that much of a big deal, as that information is already being gathered, aggregated, bought, and sold on a mass basis. If they want to know about my buying habits and financial transactions, Axciom can sell them all they need for a couple of bucks. On the other hand, I don't want them recording my chats or email or phone conversations. It's *that* stuff that is "out in the cloud" these days, and as long as it remains out there in a form that someone other than I and those I'm communicating with can decrypt, it's subject to attacks - attacks so pervasive that I don't see how you could ever built a system (technical or legal) to protect against them. The only way to win is not to play. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/8/13 1:51 PM, Perry E. Metzger wrote: > On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter > 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.) Yes, that is a possibility. Personally I'm still mulling over whether we'd want your little home device to be a Jabber server (typically requiring a stable IP address or an FQDN), a standard Jabber client connected to some other server (which might be a personal server at your VPS or a small-scale server for friends and family), or something outside of XMPP entirely that merely advertises its reachability via some other protocol over Jabber (in its vCard or presence information). > 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. I very much agree. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLQUgAAoJEOoGpJErxa2p9NUP/3R2p37pupeFB3GV5NJt1sN9 kOO+P9TXO8Ra3WXeQcNcwe43tVfpKlJIbHa9tZbs5Mvl6F2TSqChTxZ2ftS178Ul QAhX3SuztbPr7LUjROmmwLBVHr9k06LMVjSM4B5XFk3uGV+5IrTfpRkBLH7UB7vh 9mA21Zu/tGjUNPZBbHJIqXHhHMFTS4ewUznEwr4vT87xVkcG2yJ385IF/6Q22a1u n6hWuLPcWwABROIXRhZ/wDafEKnchUGiAICiGpAjd6Ngrc3gzvsOGPjcIdFS9sO8 SWO1W+AJQi6HlcnMrmlmlRJL/pBkQbOvV97/VozOKmwdP7a6LZ+OcRkpyy4HrV2C 5KBvYrl66G/G6WaWF9juRbjSvQLhpJ6CkSJ0vwfttCfI2oTmAGo/+d/L1V6Pdmv5 RYWoON6wyHTOTmvmewEcjHGzTKgae+u4BcbzZND1vpaoN4Wo5eXWQ5NkAUzK1INY NIz4kORhnHsGOfy8SCKV7WO6JQHFzFc7hZMZ8y0VkfozVK1N0IJRxPblWynI/wo6 xy3WtCWvAmCmDL0fm0SdVC3K85hJFD2kbPQWoqyKPq700PjE4/WJyL4/0Eu2cYa5 m9rB/vM5Cdkrv9LEJtZjQ7Ro0flV21P+rr2iZXVSXPVbzuj4K4oRGihcXwD9E/B7 +o+v/Ckzamfi1fpawnDk =ICV8 -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On Sep 8, 2013, at 3:51 PM, Perry E. Metzger 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. I don't see how it's possible to make any real progress within the existing cloud model, so I'm with you 100% here. (I've said the same earlier.) What's hard is making this so simple and transparent that anyone can do it without thinking about it. Again, think of the iMessage model: If Apple hadn't larded it up with extra features (that, granted, most of its users probably want), we would today have tens of millions of people exchanging end-to-end, private messages without doing anything special or even thinking about it. (Yes, Apple could have been forced to weaken it after the fact - but it would have had to be by sending an update that broke the software.) Apple has built some surprisingly well protected stuff (along with some really broken stuff). There's an analysis somewhere out there of how iOS device backups work. Apple gives you a choice of an "encrypted" or an "unencrypted" backup. Bizarrely, the "unencrypted" one actually has some of the most sensitive data encrypted using secret information *locked into the device itself* - where it would take significant hardware hacking (as far as anyone knows) to get at it; in an encrypted backup, this information is decrypted by the device, then encrypted with the backup key. So in some ways, it's *stronger* - an "unencrypted" backup can only be restored to the iOS device that created it, while if you know the password, an "encrypted" backup can be restored to any device - which is the point. (Actually, you can restore an "unencrypted" backup to a new device, too, but the most sensitive items - e.g., stored passwords - are lost as the information to access them is present only in the old device.) You'd never really know any of this from Apple's extremely sparse documentation, mind you - it took someone hacking at the implementation to figure it out. I don't agree, at all, with the claim that users are not interested in privacy or security. But (a) they often don't know how exposed they are - something the Snowden papers are educating many about; (b) they don't know how to judge what's secure and what isn't (gee, can any of us, post-Snowden?); (c) especially given the previous two items, but even without them, there's a limit to how much crap they'll put up with. The bar for perceived quality and simplicity of interface these days is - thanks mainly to Apple - incredibly high. Techies may bitch and moan that this is all just surface glitz, that what's important is underneath - but if you want to reach beyond a small coterie of hackers, you have to get that stuff right. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter 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. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
