Live data from Hacker News

Encrypted email is still a pain

incoherency.co.uk

371–380 of 450 posts

Re: Encrypted email is still a pain

#371
post #170

Earlier quoted context omitted.

> The emerging consensus among experts "conseunsus"? a few blog posts about some bad user experience with GnuPG / the PGP ecosystem is, at best, just an (re)emerging topic on HN, not the end of email encryption. OpenPGP implementations may not be the easiest encryption software out there (its usability issues have been discussed for two decades now) but that's simply because PGP was not designed to be used by the lai…

The hardest problem, IMHO, has been key management. How do you get+trust the other's key? I think a combination of keybase + a useful client can help, but the reasons listed in parent are pretty convincing.

TOFU works within a number of contexts. Though not all.

Generally, out-of-band or reference-based (e.g., third-party vouching) of identity.

Web-of-trust is useful but IMO ultimately a tool of limited use, and presents numerous issues with data disclosure, as it is an independent and public validation of social networks. Often who knows who is more critical than who says what to whom.

PGP-over-email unfortunately leaks massive amounts of metadata.

Re: Encrypted email is still a pain

#372
post #365

Earlier quoted context omitted.

Wait: which one is that?

Singal, nee TextSecure, I'd assume. Edit: Crap, I mean WhatsApp, which _uses_ Signal's protocol now.

Gotchya. Re-reading Thomas's comment, one of that set at any rate.

Re: Encrypted email is still a pain

#373

Do any of these keyservers perform email verification? It would go a good way towards some kind of verification that a user's GPG key corresponds to their email. Otherwise, anyone can generate a key with any email address and push it up to the servers. The standard way of verifying it (key-signing parties) is somewhat difficult.

To me a more useful model is the one implemented by keybase, where a number of proofs are provided, tying a specific key to the user's online identity (e.g. github profile/HN profile). Many times I want to "communicate with the persion identified as X on site Y" and this allows that to occur.

I've seen keybase and 1) cannot understand it or 2) understand its use-case.

I don't associate online identities with my primary communications, generally.

Re: Encrypted email is still a pain

#374
post #93
post #87

Earlier quoted context omitted.

If you are an active target of a tier 1 state, your endpoint will be compromised, your decrypted communication will be read, and no cryptosystem will prevent this.

Furthermore, if you're using PGP to evade a state-level adversary, the odds are overwhelming that you've own-goaled yourself many times over: * You keep plaintext archives and drafts of your messages, because that's a fundamental feature of email clients going back 3 decades. * You use a server-mediated PGP provider like Protonmail that has your security one surreptitious Javascript injection on an XHR call away from…

I disagree that these aren't intrinsict to any messaging system. Those are intrinsic problems of any electronic data storage and transfer system. Data tends to deleted or public, as Quinn Norton says.

I've been thinking this problem through for a while, and I'm starting to think we simply need to have a different mindset for thinking of electronic data as for hardcopy. I'm leaning toward "data physics", in the sense that there are different "rules of physics" which apply -- a metaphor, though close enough to the truth:

* Data have effectivley no inertia. They can move anywhere at the speed of light.

* Data violate the principle of location. Information can be in two (or more) places at the same time.

* Data can be exfiltrated without awareness of the subject. Most especially when held on third-party systems.

* Encryption isn't a safe. If you lose a safe key (or combination), you can drill it out. If you lose an encryption key, an entire corpus is no longer accessible. This has absolutely massive implications from a user-support standpoint, as such key loss will be an everyday (or, at global scale, every second) occurrance. Which means some sort of reliable, useful, but still sufficiently safe, and cheap key recovery system.

Essentially: you can be compromised at any time, by any number of actors, without notice. There may be some ways to address this, but throwing more crypto at the problem may not be it. "Canaries" or fictitious entries and sentries (URLs, emails or phone numbers which should never be contacted, but which if they are, you know you've been had), might be part of that.

Another realisation I had a while back was that as much as this hits the ordinary citizen, it's as much a concern for those in or near power (finance, politics, military, journalism, business, etc.) as well. See open speculation that the White House has been compromised, quite possibly by multiple intelligence operators from multiple nation-state, and possibly other, actors. Including those of the United States itself.

Which is to say: media change the societies in which they operate, and always have. Elizabeth Eisenstein made hay with this in her 1979 book The Printing Press as an Agent of Change, though I'm finding her 1968 paper prefacing that work a more concise and sufficient summary of the principles: "Some Conjectures about the Impact of Printing on Western Society and Thought: A Preliminary Report"

http://www.journals.uchicago.edu/doi/pdfplus/10.1086/240164

Re: Encrypted email is still a pain

#376
post #356

Earlier quoted context omitted.

You would still leak unencrypted headers, which in SMTP are numerous and interesting. A client could minimize the useful content of the message headers, but you're always going to have at least the envelope headers available to every intermediate mail host. I do not know enough to be sure about your point about forward secrecy. You may be right.

> you're always going to have at least the envelope headers available to every intermediate mail host. Sure, so any intermediate server would see who was talking to who. But that's the case with Signal et al as well isn't it?

Currently, yes.

Re: Encrypted email is still a pain

#377

Earlier quoted context omitted.

>I think that one's home computers can probably handle the load of searching all of one's own data. You seem to be implying that I have one computer at home. I mostly use the computer in my pocket, but sometimes I use "my" computer in "My office" at home. Sometimes I use "my wife's computer". Many people I know have a computer attached to their tv. I'm looking into putting a computer in my garage. Someday I'm likely…

Ideally we might have one server per person. There's no reason, really, why I shouldn't be able to run my webmail, media store, calendar, lightly-trafficked blog, etc. from an RPi sitting at home and just use them wherever I like. I used to do this with Owncloud, and Sandstorm has done some cool work in this field, though ISP's of course make it challenging. Also, it does raise the risk of everyone contributing to ma…

[deleted]

Re: Encrypted email is still a pain

#378

Earlier quoted context omitted.

>I think that one's home computers can probably handle the load of searching all of one's own data. You seem to be implying that I have one computer at home. I mostly use the computer in my pocket, but sometimes I use "my" computer in "My office" at home. Sometimes I use "my wife's computer". Many people I know have a computer attached to their tv. I'm looking into putting a computer in my garage. Someday I'm likely…

Ideally we might have one server per person. There's no reason, really, why I shouldn't be able to run my webmail, media store, calendar, lightly-trafficked blog, etc. from an RPi sitting at home and just use them wherever I like. I used to do this with Owncloud, and Sandstorm has done some cool work in this field, though ISP's of course make it challenging. Also, it does raise the risk of everyone contributing to ma…

Related : Cloudron.io has made some huge progress in making it trivial to set up a mail server.

Re: Encrypted email is still a pain

#379
post #7

Encrypted email is pretty much over in 2017. The emerging consensus among experts is that it's not worth the trouble, or, worse, incapable of doing much more than generating a false sense of security. That's for a bunch of reasons: * An enormous installed base of clients that won't do encryption, meaning that at best you're attempting to tunnel encrypted messaging over an unencrypted transport. * A protocol that leak…

But is the problem email, PGP, encryption, the idea of secure online communications, or what?

The installed base of clients could be pinned on the failure of vendors to support encryption on email: Microsoft, Google, Apple, Yahoo, and others.

The protocol issues are indeed serious, and are a prime reason I argue for SMTP itself to be retired, as it should have been 20 years ago. The problem has been in coming up with an alternative protocol.

Browser clients can all be addressed through the browser (Google, Microsoft, Apple, and Mozilla being ~98%) and apps (Facebook, and a handful of other sites).

You don't mention mobile, but that's the platform of the future, with 3 - 7 billion users, and two vendors (Apple and Google) could address the situation there for 99%+ of all users.

Message archival will continue to be an issue regardless, though there may be ways around this.

The problem with the email alternatives is that none seems to be both open and a sufficiently flexible tool that it can address a sufficiently broad set of emails uses.

I'd really like to see discussion of specific properties any replacement protocol ought have.

I'll start:

1. Encryption-default-enabled.

2. Open standards, open source, free software. (BSD/MIT license as a standards-fostering implementation.)

3. Metadata protection.

4. Federated at client, server, and directory (e.g., addressing) layers.

Re: Encrypted email is still a pain

#380
post #305
post #7

Encrypted email is pretty much over in 2017. The emerging consensus among experts is that it's not worth the trouble, or, worse, incapable of doing much more than generating a false sense of security. That's for a bunch of reasons: * An enormous installed base of clients that won't do encryption, meaning that at best you're attempting to tunnel encrypted messaging over an unencrypted transport. * A protocol that leak…

It is an absolute violation of my expectations for you to say that a browser cannot meaningfully implement crypto.

[deleted]
Post reply on HN