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

2013-09-11 Thread James A. Donald

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)

2013-09-10 Thread Walter van Holst
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?

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)

2013-09-09 Thread Jerry Leichter
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)

2013-09-08 Thread Peter Saint-Andre
-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
 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

  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