Hacker News Reader

You know, I've been having this conversation ever since PGP first came into existence. And much as I love the idea of encryption, and despite having invested lots of time in arguing for the right to encrypt and to share encryption algorithms etc. etc. I've always had to admit that if you're not a geek who loves computing for its own sake then encrypting all your email is a massive pain in the ass, whose costs substantially exceed the benefits for most people. Given that this argument has been going on for 20 years and that hardly anyone encrypts their emails on a daily basis, I'd say that the empirical evidence is that your solution, while clever, is Not Good because it doesn't meet people's actual needs.

Stop telling me why you like it and build something that's easy for other people to use. In your pursuit of technical excellence you are completely ignoring the importance of network effects on adoption and the disutility of standing out from the crowd by your use of super-solid encryption. Nobody wants to maintain a collection of public keys for every single person they know. No matter how bad things get politically there is not going to be a sudden mass awakening that will cause everyone to start using public key encryption for email, or we'd have already seen it take off like wildfire in politically repressive jurisdictions.

It's. Not. Going. To. Happen.

The fact that Osama Bin Laden didn't use PGP should be the final nail in its coffin.

That the NSA said GPG was gsme over for mass collection in the Snowden lesks should be a reason for everyone to try to improve its UI.

thats a pretty terrible argument. And how it follows for your own logic is beyond me.

That the NSA cracked, backdoored, or intercepted most providers people trusted but couldnt beat GPG isnt an argument for GPG being secure? I think it's quite an endorsement for GPG given most people's adversaries will be weaker than NSA.

1) I don't take the snowden leaks as gospel, sorry. 2) Even if i did, "most peoples adversary" is a meaningless phrase at this point, and also used quite often as a rhetorical feint to take down someones arg. And given the profound unification of the security state across seemingly all lines, its also dead wrong. Technically everyones adversary is the NSA, as long as data is shared surreptiously and , more and more, openly and legally between TLA's, state, and local LEAs. 3) GPG may be an excellent tool, the first time you use it, but if you transmit anything encrypted you are automatically targeted, another point directly from the snowden docs, no? And since virtually no one is going to use one time devices and farraday cages unless your model of communication is "I just have to get this one message out, then I'm good" its worse than useless, given that it will only make you more of a target.

"1) I don't take the snowden leaks as gospel, sorry. "

Don't take them as gospel. That's faith. Review the evidence they're true from U.S. governments' reaction to them to what similar malware was found by third parties. Once evidence is in, then you have reason to believe them and then in stuff such as GPG by extension. And the leaks didn't say anything about faraday cages. Just that they had to rely on the extremely-limited resources of TAO... such as targeted attacks on specific sites/configurations/endpoints... if the target used something strong.

the idea that "evidence" comes from the govts reaction is just weak, its just a terrible argument. Extrapolating from that is also largely a mistake. Any number of possible interpretations of the docs themselves and the responses by the state could and have been made, each of which could point to mutually exclusive conclusions for toosl mentioned in the docs. This isn't a particularly novel argument (my arg, I mean) either. I wasn't pulling the faraday cages from the docs themselves, as well, I was positing that as an extreme example of data security.

Your comment is its own best response to itself.

except that its ....not? You don't have to treat the snowden leaks as gospel, you know that right?

Even the government stopped denying their truth, especially after the drip feed of info caught them in baldface lies on several occasions. Also, if the info wasn't genuine, why would they be so upset and calling Snowden a "traitor" etc?

Additionally, this wasn't even the first time any of us had heard about this sort of thing. Ever heard of Room 641A? The Snowden leaks aren't exactly implausible or unprecedented.

I don't know if you are genuinely unsure of their veracity or just making a rhetorical point, but it's not a point of contention in any serious debate forum I know of, even among intelligence community sympathizers.

These are good points but I'll nitpick on one of them: we already maintain a collection of emails, phone numbers, etc. for everyone we know, and a public key is just one more data point in the contact list.

That's true.

Seems like a great use case for a password management company to add address book management and/or develop an email client.

Totally agree; it's just been my experience that crypto specialists don't care about UX any more than UX people care about crypto.

Whoah. Hang on there. Crypto specialists aren't the people lobbying loudly for PGP-encrypted email in 2017. They're the ones who made the world's most popular messaging application double-ratchet deniably encrypted by default without the userbase even noticing.

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.

Does WhatsApp have reproducible builds yet? Do we know that the app isn't storing the keys somewhere else?

> Does WhatsApp have reproducible builds yet?

WhatsApp isn't even open source, so no, it doesn't have reproducible builds. (Signal is open source and does have reproducible builds).

> Do we know that the app isn't storing the keys somewhere else?

No, but WhatsApp is still strictly better than either email or SMS. Even if you don't trust Facebook, that still only leaves three parties that can compromise the integrity of messages (you, the recipient, and Facebook), as opposed to the uncountable number of parties that can passively observe email or SMS in transit.

I'm sorry, I undermined my own point in pursuit of a witty syllogism and I don't want to give the wrong impression that the crypto in apps like Signal (which I prefer) is somehow second-rate.

I'm hoping Apple will lead the way. They have enough devices in the wild that could force others to adopt over time. They did it with floppy drives and optical drives. I don't see why they couldn't do it with encrypted e-mails. With their stance on no backdoors, they could raise their privacy profile for consumers and increase sales of iPhones at the same time.

> "consensus"? 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.

Well, tptacek is himself an expert. As he's the founder of a successful security consultancy who has friends among academic cryptographers, I took his comment to mean the belief among himself and his peers.

It's ultimately an appeal to authority, but it's a useful data point. Maybe there are different "circles" of security/cryptography experts, and tptacek runs in a different one from others who haven't given up on email, but I suspect he would have said that if that's the case.

>As he's the founder of a successful security consultancy who has friends among academic cryptographers, I took his comment to mean the belief among himself and his peers.

Security consultants are who you should trust the least when dealing with security. They aren't interested in reliable, easy-to-use and widespread security. They are interested in difficult, interesting security that breaks and needs consultants.

And all developers purposefully write spaghetti code while sysadmins hide passwords and secret configurations, all for job security.

Do you truly believe everyone is so cynical? Of course there are some bad actors, in all jobs and all domains. But not everyone—I'd argue the majority of people—are just out to screw everyone else.

Security consultants don't need to engage in sabotage to keep job security. User incompetence is adequate.

Let’s say that what you wrote holds true. Who should we trust then, when it comes to security advice?

Why use PGP anymore when you can use Keybase and the next generation of key management?

Instead of having one master key for your identity, the paradigm is changed:

Identity is a set of claims "X on domain A is Y on domain B". That's it.

"Domain" can refer to a server-based service such as reddit, or a client app on a device.

Such proofs are easy:

1) For public identity on sites which don't support this scheme, X simply signs something with their private key for A, and posts it on A at a URL only they control (such as an About page or a Facebook post). Presumably, X and A had to cooperate to do that. Now, to prove "you are X on A", you simply claim your your identity and the url to check, and sign it with the same private key. The verification proceeds by checking the https url for the actual claim. You hold that key. If A wants to revoke your identity proof, they just delete it from eg your profile. Each site A has to be supported individually by the client lib though, because "urls you control" are different on each site.

2) For private identity on sites that cooperate, there is a huge variety of things you could do. Everything from oAuth 2, to the signature scheme above, except the user id X on A can be different for each relying party B.

So the claim "X[B] on A is Y on B" is a private claim - others can verify it only if they identify themselves as B (eg X must be logged into A and using https on A and B and doing cross-domain communication using iframes).

They can't satisfy these conditions unless they spoof B's SSL certificate and trick X into visiting their site via a poisoned DNS. And in that case they can just find out that X is X[B] on A. Very limited privacy leak. They still can't decrypt or sign anything as X on A.

This is the scheme anyone can implement and use. It should be standardized IMHO somewhere.

Planned to say this as well. The Keybase model is working well for me, and there's nothing special about that network: similarly implemented alternatives could probably strengthen one another.

There is an RFC extension for OpenPGP that does just that: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-00

It's implemented in Android OpenKeychain.

I would love to be able to use Keybase to send encrypted email. Sadly currently Keybase does have a email as a main property on the profile and fetching it from the GPG is not very cool.

I really want to be able to type Twitter, Hacker News or Github names into emails.

You can just use Keybase to distribute PGP keys though, right?

I've been using email since 1992 in a huge variety of work, study and personal contexts. I installed PGP now and then in the '90's out of curiosity but never sent a single encrypted email as I never came across any recipients with it installed. I have never had anyone request email encryption. I don't know what the expert consensus is. But the user consensus is that PGP is invisible, and will never be used outside of a few tiny niches.

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.

>How do you get+trust the other's key?

Snail mail + several other out of band methods. Or you can exchange a one time pad, physically.

This also raises the question: With a walled garden like Signal/Wire/etc, how do you get+trust the other's key?

Their convenience comes at a cost.

There are mechanisms to use out of band communication to verify a key:

https://github.com/WhisperSystems/Signal-iOS/wiki/FAQ#can-i-...

https://support.wire.com/hc/en-us/articles/207692235-How-can...

Yup, and I've done these. But you can do similar things with PGP public keys, too.

I don't understand. You've verified a Signal key but still felt the need to ask the question With a walled garden like Signal/Wire/etc, how do you get+trust the other's key?

What cost were you talking about then?

Sorry if my earlier comment came off as rude. I was just trying to say that the walled gardens aren't really that much better than plain old PGP, and in practice they tend to lull people into a false sense of security.

I think too many people are way too trusting of shiny new apps with a pretty UI. If you don't do the extra work of verifying the key, you're effectively letting the service provider act as your one and only CA.

If you can verify a Signal key fingerprint, you can verify a PGP public key fingerprint.

I didn't think it was rude, it just contradicted your other comment.

I still don't see what cost you were speaking about. Mistakes with PGP are at least as likely as mistakes with the shiny easy to use GUI.

One idea: send them a signal (hi, this you?) then immediately dial their number and confirm.

Ideally dual channel. Send them a message on their mobile phone, call on the home phone (if they have one).

If you care about the physical identity of someone: web of trust.

At some point, you'll have to ideally meet at least one person in the flesh to exchange keys and verify their identity. After that point, it's possible that others you are trying to communicate with might be within your web of trust. If not, you'll have to go through your keysigning procedure again.

  https://www.gnupg.org/gph/en/manual/x334.html

Some organizations facilitate keysigning:

  https://wiki.debian.org/Keysigning/Coordination

But that might not be necessary for you. For example, I don't necessarily care about the physical identity for some of the people I communicate with online. If I see in e-mail archives that person is using the same key to sign their mail for the past N years, I'll use that key to encrypt to them. Similarly with commit signing and such. In that case, I just care that my message is reaching the intended recipient.

I communicate with a number of GNU hackers. Package maintainers upload their signing keys to Savannah, and sign each of their releases with that key. If I simply want to know that my message is reaching that maintainer, I can get the key that way.

But if I want to know that I'm actually speaking to the person that the maintainer _claims_ to be, I'd want to use the web of trust. They could very well be an imposter!

> After that point, it's possible that others you are trying to communicate with might be within your web of trust.

The problem with the web of trust is that it simply doesn't work: the fact that I know you means nothing about whether I trust you to vouch for others. The fact that I trust you to vouch for employees of Acme Widgets means nothing about whether I trust you to vouch for members of the a political party.

PGP's usable despite the fact that the Web of Trust is kinda a misfeature.

>The problem with the web of trust is that it simply doesn't work: the fact that I know you means nothing about whether I trust you to vouch for others.

Actually it means a lot. That's how trust works in the real world as well.

You don't know any deadbeats you trust less than a random person selected from the population at large?

The "web of trust" is not about trusting everybody you happen to merely know.

It's, and the name is kind of a hint, about knowing those you trust -- it's a web in that there's higher level trust (people you personally know and trust yourself), secondary trust (people trusted by those you trust), etc.

And in cryptography it's even more specific: https://en.wikipedia.org/wiki/Web_of_trust

It's not in any way about trusting someone just because you know them.

Point, but I'll refer you to my following sentence: 'The fact that I trust you to vouch for employees of Acme Widgets means nothing about whether I trust you to vouch for members of a political party.'

The Web of Trust assumes that I trust anyone to vouch for everyone (interesting, TLS — itself also a product of 1990s crypto-thinking — makes the same assumption). But I simply don't. I don't trust my nearest & dearest family & friends to vouch for every identity I care about. But I do trust some of them for some identities.

I trust myself to validate possession of any key. I trust my employer to validate possession of keys related to its work, but not keys related to, e.g., my family or my blog. I may trust one of my brothers to validate keys related to his immediate family, and maybe I trust two of my brothers to jointly validate keys related to our family, but I don't trust them for work, or my blog. I may trust my blogging co-admins to validate keys for roles in the blog, but that doesn't mean they get to validate keys for identities at my employer, or validate keys on behalf of my parents or children.

I could use different email addresses for each identity (I-the-employee, I-the-son, I-the-blogger), and have each identity trust only those who are pertinent to it, but that makes PGP more, not less, difficult. And it's certainly not the model that PGP advocates.

If you don't trust that individual to vouch for others then they are treated differently in your web of trust: set their trust level to "none".

If you refuse to place trust in anyone, then no, the web of trust will not work for you. But it works for many others; it doesn't make it broken. The purpose of key signing is to verify that a person is legitimately who they claim to be---_that_ is what you are trusting in your web of trust: that someone has verified their identity in a means consistent with accepted protocols.

If enough people say "this person is who they say they are" by signing that person's they, then you decrease the odds that the person is a fraud.

> If you don't trust that individual to vouch for others then they are treated differently in your web of trust: set their trust level to "none".

Whom in the world do you actually trust to vouch for everyone else in the world? For me, at least, the answer is 'no-one,' — which is why neither XPKI nor the Web of Trust work for me.

> But it works for many others; it doesn't make it broken.

I suspect that no-one (older than, say, four years old) trusts any other human being or organisation to vouch for every other human being and organisation, and thus that the WoT is in fact broken for everyone — but that most folks just try to ignore that.

I have confidence in certain people that they will follow a given protocol to the best of their ability. They're not vouching for someone: they're indicating the successful completion of a keysigning protocol.

But again: you don't have to trust a single person. As more people sign Alice's key, it's increasingly unlikely that Alice fooled every one of those people.

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.

There are federated options for messengers, the fact that the current darlings aren't is not a mark against the option itself. Riot exists.

Can you find a security expert RECOMMENDING email? That would be a better example of how it's not a consensus, like you claim.

For those(like me) who are looking for the famous reference Implementation Vector, it got a rename[0] to Riot[1] lately.

[0]Rename: https://medium.com/@RiotChat/lets-riot-f5b0aa99dc8e#.3toozs7...

Homepage: https://matrix.org/docs/projects/client/riot.html

Riot might be a great platform for doing business, but it's pretty useless for any other kind of activity. If you're a political activist having an app called 'Riot' on your phone or computer is not going to look good to anyone in law enforcement.

well, it's FOSS; someone could maintain a fork with a less controversial name (I hear 'vector' is up for grabs O:-)

"having an app called riot" is the absolute least of an actual activists concern when selecting something to help them communicate. One of the most well known leftist platforms for email is riseup.

I'm aware of that, and I think flagging yourself by choosing such a branded platform is the height of stupidity. Maybe my social circles are just more privacy-oriented.

As far as I can tell, encrypted email is still how you reach out to CERT, security teams at distros such as Ree Hat, Debian and so on?

These people might not be crypto experts, but hopefully many of them are security experts.

Gpg is also how most mailing list communication is (clear-)signed - and that coupled with public archives does give a way to verify that the person that controls the key that signed release notes for this package these last five years, is the person that will be able to read this zero-rated report that is critical. (It says very little about said owners real identity, or his or her legal name)

What does FreeBSD, OpenBSD or Oracle recommend for sending sensitive information to security@<company|project>?

That said, modern email suck.

Mutt (possibly with "not much") might "suck less" - but we need many more, better (graphical) email clients. I think Fastmail's work on a json-based client protocol is interesting (not because it's json, but because every blank staring IMAP-client writing developer keep saying that there are terrible horrors laying in ambush for the unwary).

Opera had a nice, new-ish, fast mail client. Other than that I'm unaware of any serious effort to make a new, modern, easy to use IMAP client. Let alone an open source one. Or one that doesn't beg to expose library bugs by rendering html, images etc in-line - or ignore user privacy by loading external resources that enable user tracking.

I've been contemplating writing one for quite some time.

> every blank staring IMAP-client writing developer keep saying that there are terrible horrors laying in ambush for the unwary

Oh, my, yes. Lasciate ogni speranza...

Whilst you focus on "consensus" as the key word, I focused on "emerging" as the key word. Perhaps "a few blog posts" is where this consensus is emerging.