On Sep 8, 2013, at 1:47 PM, Jerry Leichter <leich...@lrw.com> wrote:
> On Sep 8, 2013, at 3:51 PM, Perry E. Metzger wrote: >> >> 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.) 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. Transport encryption (regardless of its security) is no solution either. The fact is, to do business, education, health care, you need to share sensitive information. There is no technical solution to this problem. Shared data is shared data. This is arguably the same as the analogue gap between content protected media and your eyes and ears. Encryption is not a solution when the data needs to be shared with the other party in the clear. I knew a guy one that quipped "link encryptors are iron pipes rats run through". If compromised end points are your threat model, cloud computing is not your problem. The only solution is the Ted Kazinski technology rejection principal (as long as you also kill your brother).
_______________________________________________ The cryptography mailing list email@example.com http://www.metzdowd.com/mailman/listinfo/cryptography