GPG and Me | Hacker News Reader

GPG and Me

thoughtcrime.org

588 pointsjashkenas249 comments

A lot of the comments I've been getting are in the genre of "well... but GPG works."

Yes, GPG is a powerful tool that makes some encrypted communication possible. But is it really "working" if it's the tool we've had for the past 20 years, and we still ended up in a world where surveillance is so ubiquitous and privacy is so rare? Having used GPG, it seems more likely to me that there are only ~50k GPG users in the world because of the product, not because of weak desire or need for private communication.

I'm not suggesting that there's anything "better," but that it's really sad there isn't. GPG isn't ever going to be anything other than what it is now, and I don't think that's the future we want for ourselves.

We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol. The good news is that GPG has such a small legacy install base (literally on the order of ~50k users), that there's no reason to maintain compatibility with OpenPGP. When building new products, we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy.

You know you're one of only a few people in the world who is in a position to do that, right? Anyone else would (rightfully!) get torn to shreds on HN by tptacek or yourself. And I say "rightfully" because it is very likely that other people would screw up some central aspect to the security of any new product that claims security.

It's not just that, though. Anyone else with your knowledge but no standing would be scorched for saying what you just said. "Throw away the one thing that has proven to be secure and write our own protocol" doesn't go hand in hand with "serious cryptographers trust what this person is saying."

The truth is probably that either you do this or nobody will.

You should. The world would be better for it.

Is there a kick starter page for this cause that I can contribute to? Because I would.

I'm not going to back just any crypto project, but with the right people leading the charge I would get behind it.

https://whispersystems.org/blog/bithub/

(Unrelated to GPG, but this goes towards crypto projects by Moxie and other solid people.)

Go through my comment history. How many comments do you see? A handful? Yup. The reason there are so few is because, I only reply to comments I wholeheartedly agree with. And this is one of them.

> You know you're one of only a few people in the world who is in a position to do that, right? Anyone else would (rightfully!) get torn to shreds on HN by tptacek or yourself. And I say "rightfully" because it is very likely that other people would screw up some central aspect to the security of any new product that claims security.

This attitude is why GnuPG (and other PGP implementations) are in a position to be criticized by the Moxies of the world. Is there some particular reason why anybody outside of some recognized elite should be discouraged from at least trying to create a better, improved system? Yeah, they'll probably fail in a lot of cases, but if the world really wants a modern, easy-to-use alternative to PGP (a real alternative, not use-case-specific alternatives like RedPhone and TextSecure; encrypted/signed email is still a valid use case that both those things blissfully ignore, by the way), this sort of attitude - that anyone outside of a select few rightfully deserves to be scolded for trying to make better crypto - is lethally toxic to that goal.

Yes, there is a reason to discourage those people.

In between the time that a cryptographically illiterate developer releases their MVP 1.0 version and the time that it's discovered that their cryptography is fundamentally flawed --- a window of time that can stretch on for years --- actual people will rely on the tool for their security, not realizing that serious adversaries are reading their messages.

Most new cryptosystems --- a cryptosystem being "anything that uses a cipher, including when the cipher is simply AES --- are terribly broken.

Search for [decryptocat] for an extremely good example of what I'm talking about.

Developers who are new to cryptography that want to learn more about it and eventually use it in their own systems should start by learning how to exploit broken cryptography. If you can't exploit an RSA padding oracle, you shouldn't be designing systems that use public key cryptography. If you can't exploit a CTR nonce stutter, you shouldn't be using block crypto.

Developers who don't want to learn cryptography should work on improving the UX (UI and workflow) of existing cryptosystems. PGP could sure use some help, but even if you don't want to help with PGP, there's a huge green field of work to be done on browser TLS trust and CA user interface. Just as one example.

My point is that this attitude of "only people who have proven themselves as cryptography geniuses may dare to think about thinking about cryptographic protocols" also discourages the potential UX/UI/workflow/etc. programmers from participating, since it gives the impression that their contributions will never be "good enough" to be accepted. It also discourages potential developers of the crypto algorithms and protocols themselves from participating, even if they have gone through the (in your opinion) requisite experience of learning how to break existing cryptosystems, because of the fear that they'll just be burned at the stake by the rabid likes of Hacker News and Slashdot for daring to suggest anything new (these are the sorts of cryptographic programmers I'm talking about, not some "badass rockstar ninja" Macbook-toting YCombinator-funded Ruby.js hipsters manufactured in the heart of Silicon Valley like you seem to be implying).

This results in things like GnuPG being considered hard to use. This results in things like GnuPG struggling along with a single core developer and barely enough funding to support that developer (even now). This results in things like OpenSSL being horribly undermaintained, to the point where nasty bugs like Heartbleed are allowed to exist longer than they should because there is an insufficient quantity of eyeballs to find them and squish them. It doesn't take a rocket surgeon or a cryptographic guru to see that this is nothing but an awful situation for pretty much everyone involved.

what's a CTR nonce stutter ? Its not listed on the cryptography attacks wikipedia page: http://en.wikipedia.org/wiki/Category:Cryptographic_attacks

i think any 3rd party distributed crypto is only useful against weaker adversaries (weaker than the person doing the distributing). For p2p crypto designed and agreed to by the two parties, there are lots of options, starting with a 1-time pad, CTR mode hash based ciphers, etc...

That Wikipedia page is not very useful.

Hey Moxie, it intrigues me that the first thing you mention in your post isn't technical or even about UX (which is what most people in this thread are focusing on). Instead, it's that you're starting to dislike reading emails from the kind of person who would "voluntarily use GPG".

I know you said there's no unifying theme to these emails, but can you elaborate? Maybe something about security-obssessed lay people using GPG to send the most trivial of emails? Or something else entirely?

To quote another commenter:

"Way to take a dump on people who make an effort."

It's the same as people who voluntarily use Windows. It says something about them, that's all.

I can guess why you're being downvoted, but your comment is ironically correct. It /does/ say something about them! But what that is depends on who you ask. And that, again, says something about /them/.

Which says something about the downvoters.

Irony everywhere.

People are getting offended, but I could have replaced Windows with almost anything. Our choices say things about us. Getting back to the subject at hand, though, I assume 'moxie meant that people who choose to use GPG for casual conversation must be slightly masochistic and therefore slightly less likely to have something interesting to say.

... just like Windows users ;)

Yes, of course, but I'm very curious about moxie's interpretation of what using GPG says about the people who randomly email him; certainly more curious than constructing my own stereotype.

Get out of your bubble. Windows is ubiquitous. It has 90% of the desktop market share. There is no generalization you can come up with about that many people.

I think the OP meant that, given a choice, say, of getting a Mac or a Windows PC at work, you voluntarily pick the Windows PC.

That's also a false dichotomy, a dangerous one at that. Sort of like two party system.

> Windows is ubiquitous. It has 90% of the desktop market share. There is no generalization you can come up with about that many people.

'People who use Windows do not have both the intelligence not to desire it and the power to do as they wish.'

It might be people who miss the forest for the trees. Right now Moxie is working on bringing encryption to the masses. That involves a whole-product view, with empathy for the unsophisticated (think about a kid who's only computing device is a phone).

I know stereotypes often treat people unfairly, but the kind of person who has the dedication required to use PGP seems, to me, to often coincide with the people who find fault with everyone who hasn't had the dedication or focus to learn sophisticated software techniques.

And, if I were Moxie, that would be a source of constant frustration to me. The very people who have the ability to make things better -at best- don't empathize with the people they could help, and at worst harbor a bit of contempt for them.

Considering Moxie seems to be dedicating a large part of his life's work to helping average people, I believe the attitude I described could play foil to the inspirational messages he also receives. But I don't pretend to know him or anything.

> Considering Moxie seems to be dedicating a large part of his life's work to helping average people, I believe the attitude I described could play foil to the inspirational messages he also receives. But I don't pretend to know him or anything.

You may say that, but after the "we specifically work to make TextSecure impossible without Google Play because using Android without google is 'going back to the old broken desktop security model'" thing, I'm not convinced.

I'm sure moxie is good with crypto, but sadly, he's on different side of war on general purpose computers than I am. He's on the side of walled gardens and limits what can you do on your own device, and I can't accept that.

EDIT: and of course he would spit on GPG. For moxie, GPG is competition.

Moxie's stance on non-Play releases is not as extreme as you suggest:

https://github.com/WhisperSystems/TextSecure/issues/127

> When building new products, we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy.

Agreed 100%. I just don't have anything to offer in this space :(

Please do this! I'd love to be able to use encrypted communications as a matter of course, but just not enough of the folks I work with are able to get it set up. My world is filled with smart people, but only a small fraction are purely computer folks and to try and get a biologist to understand why it's interesting to have all emails encrypted is a losing task unless it's super easy.

What do you think that looks like, though? Is it TextSecure on the desktop, with file attachments? Is it Pond? Is it just email, but with a different crypto layer?

I feel like a lot of the things GPG aims to do are fundamentally hard. It's not the technology that sucks, it's the problem. I completely agree that the answer will come from thinking about user interactions first, but I'm not sure that the solution will look much different than a better GPG client.

I don't have a definite answer. There's the path we're executing on at Open Whisper Systems, but there are a bunch of other projects working in this area as well (Mailpile, LEAP, etc).

I think the problems are solvable, but only if we have a different design approach. So when I see projects trying not-PGP, I'm interested. When I see projects building on PGP, I'm less interested.

I'll take the opportunity to say that it saddens me that I still can not communicate using TextSecure with iOS users. It's been almost two years[1] since iOS support was "promised". TS is great, but we need to be able to communicate with iOS users.

[1] https://whispersystems.org/blog/sure/

Signal 2.0 was tagged on github 3 days ago and will bring the textsecure protocol to iOS whenever apple is done reviewing it.

If this is true, it's awesome. I've tried making contact between Signal on iOS with TextSecure on Android before, without luck.

Not the place :/

What do you think of Peerio?

Also, any vague timeline available for arrival of the desktop Signal version? What about video-chat support? Would that be possible with WebRTC? (although you should probably wait until ORTC is supported within WebRTC - v1.1 I think?) and then add ZRTP on top of it. Or is a desktop, Javascript version, just not secure enough for that to happen? What if you do it like Whatsapp's "web app", that basically only connects locally to the phone?

> It's not the technology that sucks, it's the problem.

This is my feeling as well. To optimize for security and privacy, it seems like it needs to be difficult by design. If it's too easy, it's probably less secure.

I'm not sure if anyone has given it seriuos attempts to make it more user friendly, though? Would be surprised if no one has, there should be a great opportunity here. Escpecially now that it has so much focus.

I also believe that some complexity is inherent to secure communication, so people are required to learn a little to properly use this. Hopefully, this will be taught in high school or earlier at some point.

However, I also (like Moxie) believe PGP is not at the sweet spot. It has too much complexity for the most popular use cases. Thank you Moxie and others who are searching for the sweet spots.

Peerio might work, but it hasn't been vetted too much yet:

http://peerio.com/

It's made by the CryptoCat author, so make of that what you will.

No linux support, no firefox support.

Literally the second tweet on their twitter account is 'Damn, it works. Got a lawyer who resisted all other methods to encrypt our comms with @Peerio. Big score for usability. Bravo @kaepora & co.' which kind of bugs me, too.

Back in the 90's I tried to use GPG, and I tried to pay for digital music. They both went roughly the same way.

Arguably it was easier to use GPG back then than it is now. Pine was my MUA and I had an easy to find public key. Now I have an iPhone, don't use Linux on my laptop anymore, and make heavy use of messaging products.

Here's what I have now that I didn't have then, 2FA. There's an app on my phone that makes it super easy so I use it. If I had to still carry around a separate RSA code generator I probably wouldn't.

Surely we can figure out a way to make encrypted email nearly transparently easy with the major mail providers, and the default mail apps on our laptops and and phones. Surely we can figure out a way to make a trustworthy distributed keystore.

Perhaps this will all change because before Snowden we were blissfully unaware and GPG was a cool toy unless your life was in real danger, post Snowden we're residents of a vast internet police state and my Mom knows how Target was hacked.

I have a strong suspicion we will figure this out, and soon. I wonder, are VC's are looking into funding easy to use consumer encryption?

>Perhaps this will all change because before Snowden we were blissfully unaware

Every time I see this in regards to email, I'm puzzled. Carnivore was known about in the 90s. Then there was the AT&T Room 641A in the 200s. So I don't know how people were unaware that state level actors could tap connections and record email.

Second, for this threat model, just forcing and validating TLS on SMTP gets you pretty far, does it not? You're then mostly trusting your email provider. And without trusting them, we get into user-unfriendly stuff like not being able to forget your password. (Barring some sort of breakthrough ideas.)

Seriously, has there been any good proposals that provide strong privacy (say, no one but the user can read the message) but aren't complicated or require users to do things they aren't gonna do: validate keys? PGPFone and ZRTP are great because you already have an "out-of-band" key auth mechanism in place, and it's fairly straightforward to check.

Re: "You're then mostly trusting your email provider. And without trusting them, we get into user-unfriendly stuff like not being able to forget your password."

Nobody should trust their email provider if they are concerned about the privacy of their email. The Job To Be Done, by an email provider such as gmail/yahoo/hotmail is to act as a mail store, and mta. A user should be able to rely on a local MUA for confidentiality. Admittedly, that shifts the level of trust from the Email Provider to the provider of the MUA software and the Local Hardware, which is why things like OpenBSD/Linux and (hopefully not firmware-tweaked) commodity hardware is so important.

What your proposing is currently limited to people that are more-or-less OK putting up with PGP. For everyone and their mom to use encryption, features like "I forgot my password and now lost all my email" aren't acceptable. Nor are things like "I've got to make a separate, verified, out-of-band contact to verify that I've got the right key".

I'm hoping someone comes up with a breakthrough idea here, something fantastic that enables real privacy with no inconvenience. But in 20 years, there's been essentially zero progress on that front. All proposals either violate Most Users' required features, or boil down to offloading trust to the email provider.

I don't see any way to protect users against forgetting their encryption passphrase, or losing their private key, without offloading trust somewhere. Except for backups, anyway.

It can be very hard to know whether you have the right public key, especially for people that you know only from online activity. And it's not uncommon to find multiple unrevoked keys, with the same email address.

But check out https://keybase.io/mirimir. You can easily get a GnuPG key that signed proofs in my profile here, on GitHub, and on reddit. Also, the email address in my key is linked to a Gravatar that StackExchange and other sites use. So whoever I am, you can be confident that I control that GnuPG key.

> I don't see any way to protect users against forgetting their encryption passphrase, or losing their private key, without offloading trust somewhere.

Private keys are obviously an issue, but I don't really get why passwords are considered so important.

I like to use GPG when I can for communicating with people, but most of the things I put on it are less private than what you would get if you got my computer.

I don't think passwords protect you if the attacker can install a keylogger (correct me if I'm wrong), so anyone with hardware access or malware isn't going to be stopped. You are only protecting against people that can read files from your computer but not install hardware/software.

I think for the average user the password provides little extra security while having a high UI cost.

My mom didn't know about Carnivore. I did because I worked at an ISP. My mom knows about Snowden. Thus the general public was blissfully unaware, now they are not.

To be technically precise what makes 2FA easy to use is that all services are web-enabled and issue you a temporary-long-term token (ie a cookie with a session id).

If you had to open an app on your phone at each login you'd get crazy real fast :)

I do like your analogy tho. Digital music is a breeze to buy nowadays. Moxie seems to appear as covertly saying its misguided to donate money to GnuPG so that it finally gets good, because, you know, not-moxie-made.

The.. what was it called? Redphone? Whisper? and various other projects - while very cool - didnt achieve even as much popularity as GnuPG (which in itself is far from greatly useable).

I know of one tech that has a chance right now and thats U2F/Fido. It allows for building a framework (being GnuPG or otherwise) around it that's both secure and works for everyone. Why? Because fucking gmail supports it that why. It has nothing to do with the actual tech. It has to do with support. It has to do with my iphone, android, whatever, working with it seamlessly. It a lot to do with "slapping a GUI" at the right places.

You say "Redphone? Whisper? and various other projects - while very cool - didn't achieve even as much popularity as GnuPG"

The Axolotl protocol that was created for Whisper System's TextSecure is now used, by default, by Cyanogenmod (10 million users) and the Android version of WhatsApp (more than 500 million installs from the play store).

I'd say Moxie's tech has been pretty widely adopted.

When can I have a compatible FOSS desktop client? I don't do 100% of my communications from my phone, and I never will.

If you can't do it on desktop, you can't do it at all. Mainly because some of us have real work to do.

If the only "usable" implementation is on a hard-to-physically-secure mobile device that uses a tonne of different uncontrolled network access points a day -- that's not really an option now, is it?

I feel you're missing open whisper systems' target audience. If you've seen how regular people use computers, their phone is the most secure device a normal person owns. Not the most secure if you're worried about targeted attack, but the best place to put a dent in cheap dragnet surveillance :)

You won’t have that until someone takes the time to produce such a client.

Its like saying notepad is a popular because its installed with Windows.

Even if you ignore Whatsapp and Cyanogenmod, you have 500,000 - 1,000,000 Textsecure installs according to the Play Store. That is on order of magnitude more than the GPG estimate of 50,000. In less than 20 years.

> Surely we can figure out a way to make encrypted email nearly transparently easy with the major mail providers,

What, Gmail? Yahoo? They exist only because they can read your plain-text email and serve ads against it. Most people get their email through free webmail providers, who have every reason not to make encryption easy.

Don't you think the time is right to build such a system?

Public awareness of privacy especially wrt mass government surveillance, identity theft and high profile corporate breaches seems that such an thing is ripe.

I am naively optimistic given the right implementation a consortium of stakeholders could do something meaningful.

Do you have any specific criticisms of GPG other than "it's old and it's not popular"?

What's your ideal vision of what end-to-end encryption for the common (wo)man should look like other than "not GPG"?

Two questions whose answers are nonexistent in your article.

Specific criticisms of GPG:

> the working hypothesis for privacy enhancing technology was simple: we’d develop really flexible power tools for ourselves, and then teach everyone to be like us... Instead of developing opinionated software with a simple interface, GPG was written to be as powerful and flexible as possible. It’s up to the user whether the underlying cipher is SERPENT or IDEA or TwoFish

I think it's self-explanatory why it's not good that users need to know about SERPENT, IDEA, and TwoFish.

> the fundamental architecture of PGP also leaves no room for now critical concepts like forward secrecy.

> a ballooning penumbra of OpenPGP specifications and notes so prolific that the entire picture is almost impossible to grasp... Mailpile had to write 1400 lines of python code just to interface with a native GnuPG installation for basic operations, and it still isn’t rock solid.

> journalists who depend on it struggle with it and often mess up (“I send you the private key to communicate privately, right?”)

UX failure leads to user uncertainty or insecure behavior.

What a better replacement looks like (from the comment here):

> Good UX requires thinking about interactions all the way down to the protocol.

> we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy

> UX failure leads to user uncertainty or insecure behavior.

I'd say user uncertainty and insecure behavior are, each, sufficient criteria to declare a UX a failure.

You list plenty of specific problems with GPG the UI and GPG the "API" (though frankly the fact that mailpile would write 1400 lines of python that wrap GPG rather than taking one of the independent library implementations of RFC4880 and bringing it up to production quality makes them part of the problem). But none of those specific problems are problems with OpenPGP the protocol.

Well, I was only quoting the article, but it sounds like he has a good point that the protocol doesn't support forward secrecy. I also tend to trust his judgment that it's too complicated, and/or the complication adds little value for "normal" users. I guess some of this can be isolated as an app/API problem rather than protocol, as you say.

Perfect forward secrecy is of course better than not, but I'm not convinced it actually helps a lot for realistic threat models. It means that when you utterly screw up and reveal today's treason you won't also be revealing last week's treason - but for someone who's using crypto for serious reasons, how often is it that last week's message would get you in trouble and today's message is innocuous?

Would a ground-up rewrite of OpenPGP have PFS? Of course. Is the functionality important enough to justify a new protocol? Not on its own, IMO.

Follow-up: on more thinking, I don't think it's possible at all without compromising important properties of GPG.

Thanks; for the first question, I suppose I should have read more carefully.

The second question, however, still isn't adequately answered; "we should be thinking about interactions" and "we should use modern things" are two of the most vague answers possible.

Apparently it's so hard to use properly that even Snowden screwed it up in the course of communicating during his leaks.

> The frustrating and ironic thing about GPG is that even experts make mistakes with it. Even, as it turns out, Edward Snowden.

> I now had Poitras’ permission to send Snowden her encryption key, but in his first email to me, Snowden had forgotten to attach his key, which meant I could not encrypt my response. I had to send him an unencrypted email asking for his key first.

https://firstlook.org/theintercept/2014/10/28/smuggling-snow...

Any encryption system has to exchange keys, and you can do it easily or securely, pick one. Failing the way you describe makes things cumbersome but does not compromise security.

The issue is that it seems like you want to replace GnuPG by something that does the same - but is made better, and that has your brand name on it.

That's very marketingish of you. Why not fix GnuPG instead? There's more than slapping GUIs to things!

Also, where is your 50K user base number from? According to my SKS keyserver traffic, it's much greater, even if i were to assume 50% of the traffic is non-human.. what the fuck happened to you man?

Also, if it's well done - I'm not against something different from GnuPG. I just disagree with the argument.

Which leads to this question:

which product are you going to announce in 6mo that would be so much better?

OK, GPG is crufty and hard to use, and the email protocol exposes metadata. So perhaps it is best to start fresh.

What do you think of the Dark Mail effort? And of Pond?

One of the biggest problems with GPG is keyex. Sure, we have key servers, but that's not really a secure way of doing things.

Secure communication is as much a cultural change as a technological one.

GPG at least has the web of trust, with all its privacy problems. Most technologies just use "trust on first use".

That doesn't actually solve the problem though. It helps in theory, but it requires the user to understand what they're doing to a level most won't.

There is also the cultural issue of just exchanging fingerprints. Only techies put them on business cards, and even then only some. It needs to be common action.

Well, at least they try to solve it.

Another approach for verification is employed by Threema [1]: The server verifies email addresses and phone numbers, so if the address or number is in your contacts you can have more confidence, represented by an orange dot next to the contact. If you verify the fingerprint by scanning QR codes, you get a green dot.

About fingerprints for the masses: I really like the visual fingerprints Peerio is using (basically bigger Github-style generated avatar icons).

[1] https://threema.ch/en/faq

GPG is way, way, way to complex for all but the 0.01% of people who are GPG experts. It's too complex for me - and I've read (and enjoyed) Applied Cryptography.

But, not having used it for a few years, I went to take a look again - list some keys, maybe SMS some friends to exchange fingerprints and sign their keys, etc... - I'm trying to recall what the relationship between PUB, SUB, UID, Key Fingerprints are. And how do I indicate that I trust a key and upload it back up to pgp.mit.edu?

And I consider myself a member of the 0.1% who at least understand the principals behind PGP/Public Keys/Private Keys/Web of Trust, etc...

So - if I'm having trouble understanding this without a couple hours of study, their is Zero chance that the other 99% of the population will ever be able to wrap their heads around the intricacies of PGP. Something else is going to have to replace it.

[EDIT - as an aside, I've spent the last hour trying to do a "gen-key" on my ubuntu host, and been prevented by lack of entropy - and yes, I've tried running tcpdump, tried egrepping every file on the system for a string, etc... Ended up on https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/706011 and the answer seems to be, "Find a machine that does have entropy, or install a hardware random number generator in your computer."

Please add this to the reasons why normal people never use GPG

Edit-2: It took about 25 minutes, but apparently between find / -type f | xargs grep wontfindme and sudo tcpdump -nnn not port 22, I managed to collect enough entropy to keep gpg moving forward. ]

apt-get install haveged

I'm not sure why you're being down voted.

haveged is an absolute essential for all servers

http://www.issihosts.com/haveged/

It's snake oil -- entropy isn't "depleted" in any meaningful way; once your kernel PRNG has accumulated enough entropy that you'd be comfortable using it to generate a crypto key it is not going to cease being suitable for that just because you continue asking it for random numbers.

/dev/random is an entropy estimating entropy pool

that means it will block when it estimates that you have "used up" all of the available entropy

you can check how many bits of entropy your kernel thinks are available easily

cat /proc/sys/kernel/random/entropy_avail

edit: i should have mentioned that there is some reason to argue against this behaviour but that doesn't change the usefulness of haveged for existing systems

Yes, but that's a reason not to use /dev/random, not a reason to install snake-oil products.

The random(4) manpage is unfortunately exceptionally misleading, and has sadly led to a small but non-zero numbers of products that try to use /dev/random rather than /dev/urandom.

Sadly, gpg --gen-key doesn't even give you this option - but that's (as noted above) another flaw in GPG.

> and been prevented by lack of entropy

This sounds like an implementation fail / lazy implementor. GPG shouldn't need more than 32 bytes of entropy (for keying AES-128 and then encrypting a 128-bit block of data repeatedly until you collect enough randomness.)

There has been a number of studies (http://www.2uo.de/myths-about-urandom ; I don't agree with everything but interesting reading anyway) showing that entropy from Linux random is not better than from urandom (once urandom has been properly seeded). For this reason, I patched my rndlinux.c GnuPG source code file to always use urandom. Makes key generation instantaneous. When a software is stupid, I don't want to install additional stupid software or comply with stupid instructions; I simply patch it.

I think that on linux, you ideally don't want /dev/urandom, you want a recent kernel and getrandom(buf, len, 0). From the manpage:

If the GRND_RANDOM bit is not set, then the /dev/urandom pool will be used. Unlike using read(2) to fetch data from /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will block (or return -1 with the errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).

Then again, that's probably not important if you interactively launch gpg on a desktop system that wasn't just installed a minute ago or so.

Entropy is a massive problem, especially on headless servers.

Timer EntropyD [1] can be extremely handy (as can the audio-entropy gathering)

[1] http://www.vanheusden.com/te/

What would be needed for adoption and ease of use would be for a registry to store public keys and salts... for webmail, a section of the message could be labelled as something like...

    [[SECURE_CONTENT abc@ez.im -> foo@bar.com
        BASE64-CONTENT
        =====
        BASE64-SIGNATURE
    ]]

The a browser or email plugin can then retrieve the public key for abc@ez.im and confirm the body was sent by who it says it was. Then if the user has already connected via the plugin, their private key is used.

For simplicity the registry will do email validation of its' users, it should issue a SALT so that PBKDFx(SALT + email + passphrase) is used to generate the private key... the public key is stored in the registry.

For more control, a given service entry in dns for peer-crypt registry for the given domain can be set as an authority. A distributed system could be used for confirming tokens combined with DNSSEC as a control system for greater availability.

There are flaws with this idea, but it could be something that can be made insanely easy to use, as well as adding a lot of security to email transmission without creating an all new infrastructure, only adding services on top of what exists.

For power users, they could set the public key without salt in the registries, if they wanted to manage their own, instead of relying on the generation mechanism, or to use/keep the same key across different addresses/providers.

>The a browser or email plugin can then retrieve the public key for abc@ez.im and confirm the body was sent by who it says it was.

Well, that's the issue, right? How does it do this?

If it's not weak desire or need for privacy then why hasn't the market successfully solved this? Moreover, where is the outrage at the lack of privacy.

Consider a separating the goals.

OTR is much more successful because it allows ad-hoc connections instead of trying to make authenticity guarantees. It encourages authentication, but the decision of when to invest that extra effort is left with the user. Fundamentally, OTR just offers privacy from eavesdroppers, and it does that well. Every other feature is extra. Even better, these new features (e.g. authentication) don't have to start from nothing. A big benefit of separating features is that is added later can leverage the existing infrastructure.

I personally believe the "killer crypto app" that will actually be adopted is a tool that is the opposite of OTR. It should only promise ad-hoc authenticates and do it in an generic style. I mean something that is somewhere between "gpg --clearsign" and 2channel/4chan style tripcodes[1]. In an ideal world, this needs to have a clearsign-style mode, so it can be used on existing forums. If the browser simply offers a "sign this" button next to textareas (no password, auto-gen they key and stuff it on a keyserver, just make it happen), it will be used. On the decode side, any blocks of text the browser sees that look like a signature get check, with the key pinned. That's it. Any features that allow nicer integration with email, forum software, etc, are nice but optional.

This provides a minimum, anonymous level authentication (forgery prevention), and the only UX the user should have to see is the "sign this" button and a loud "possible forgery" warning if a signature doesn't match the pinned key. It even works regardless of who is transporting the message (different websites, email, gopher, avian carriers) without needing an "identify provider". Upgrading this infrastructure of pinned keys into something more interesting can happen later on, if desired.

Would this work? I believe it's worth trying. It is clear that trying to solve all of the security needs in a single tool has not worked, and the one tool that got any adoption at all (OTR) has a much more narrow set of goals.

[1] http://en.wikipedia.org/wiki/Imageboard#Tripcodes

>We could try to slap a GUI on top of it, but I don't believe great products are made that way.

I'm right there with you on that one. So is most of HN I imagine.

But the Apple ][ really brought the PC home for so many more people than it's competitors purely because of it's relatively simple GUI.

Command prompts scare the average user.

The Apple ][ booted to the commandline, as did the ][+, //e, and //c.

At least the //e could boot to a disk without any interaction with the command line.

I guess that's why I will always be a C=> fan.

It's one thing to recognize the limitations of GPG. I think we all do. It's another to declare it an abject failure and continue to use it and complain.

Go generate a revocation certificate and push it to the global pool. You'll stop getting those disappointing emails.

But seriously, go build something better. I fucking dare you. We'd all be better off for it if you really did.

He does build something: https://whispersystems.org/

Whether or not that something is better, however, depends very much on the use case. RedPhone and TextSecure are designed for very specific use cases (phone calls and text messages, respectively), whereas GnuPG is designed to be general-purpose and universal regardless of use case. Most jarringly, neither of those programs address email or file encryption/verification, and thus do nothing in GnuPG's primary realms of usage; by comparing them, you're basically comparing apples and crowbars.

My mother literally did not know how to turn on a computer until a few years ago, but was able to use Signal on her iPhone after almost no explanation. My mother looked at me funny when I tried to explain GPG to her after the Snowden revelations started. But ever since I installed Signal on my mother's iPhone, I have been able to have private phone conversations with my mother. The significance of these types of distinctions between gpg and Signal are hard to underestimate when you extrapolate them to a societal level. My partner uses TextSecure/RedPhone with ease, and most of my friends use WhatsApp. I've only been able to convert a few of my non-technical friends, in contrast, into gpg users. Another way to think about this in terms of strategy: the means actually are the ends.

Almost as important as his crypto expertise, moxie's deep understanding of UX and especially barriers to entry and the network effect have concretely made the world a better place, and not just for people like us...but also (and especially) for people like my mom, my partner, and my (mostly non-programmer) friends. Thank you for understanding that their privacy is important and that their human dignity matters--and especially for meeting them where they are.

As a result, now it's not just my colleagues "in tech"--but also essentially all of my friends and family--who are with you!

Just a question, how do you know it's only your mother you are talking to? Have you verified the key she uses with the one you are talk to?

It usually goes something like "mom, what are the two words (short authentication strings) you see on your phone?" Sometimes she even asks me--we make jokes about the combinations.

And yeah, it's true that some of the Snowden docs reference ZRTP attacks & spoofing voice so it's not necessarily foolproof (or her phone could be owned etc.), but another one of the things my mother told me when I was a kid was "the key is to begin." And that's what moxie's done...

I am - roughly - a GPG fan. I've done classes on it, used it at work and at home, etc.

GPG is a terrible UX. Accidental use of GPG tends to fail open, and insecurity results. Futzing with different keys, rotating them, retracting them, etc, are grievous. I can't reencrypt old stuff to new stuff (e.g., a pw database) without spending a good deal of time thinking about attacks, file safety, etc.

I'm really a distributed encrypted email fan, I guess. I want to securely communicate over email to my friends and family, without having to do the GPG dance.

You say "cryptography of the 90s" as if the cryptography part of GnuPG was old and therefore unusable. This seems to be quite misleading to me.

Blaming "1990s crypto" is, IMHO, missing the point. Until we discover attacks against the ciphers there's no reason to throw them out just due to their age.

If you're referring to GPG's shitty interface, then sure. But how much of that is "1990s crypto" and how much is due to the fact that it's one guy working by himself and barely being able to afford it, for years?

GPG with Linux-levels of support would be an entirely different beast.

edit: oh sorry, are we not allowed to disagree with Big Names™?

>edit: oh sorry, are we not allowed to disagree with Big Names™?

Not when it comes to cryptography and HN. Moxie, Collin, and tptacek are the only 3 people that can say anything that isn't mainstream pop-crypto. Anyone that dares to disagree with them is clearly wrong and must be punished with downvotes.

I agree, and this attitude is one of the things that's holding progress in crypto back.

Should random software engineers experimenting with crypto claim that they've created a software package worthy of being used by dissidents and whistleblowers?

Absolutely not!

But should we be discouraging random software engineers from experimenting with crypto, and starting open source projects that may gain steam...and eventually, after years of use and audits, gain the standing and reputation to be used by dissidents and whistleblowers?

Again, absolutely not.

As it happens, I was just studying the CT-RSA 2015 conference agenda, I read that there is a conference talking about some form of oracles in OpenPGP and affecting several implementations. That would indicate that the RFC4880 format is fundamentally broken in theory AND practice. http://www.rsaconference.com/events/us15/agenda/sessions/176...

Well for one, he's blaming the protocols that are "90's crypto", not the cipher, but second, I think GPG does use some weak crypto as well, at least as options, and they never bothered to remove those.

HTTP is '90s tech. TCP/IP is '70s tech. There's nothing inherently wrong with that. 1400 lines of python that tries to pretend that an interactive program is a library is definitely a problem though.

How's about this: rather than a protocol-up rewrite, how about just writing a library-up rewrite? Write a ground-up implementation of (maybe a subset of) RFC 4880, with opinionated choices of default ciphers (a bit like NaCl). Make it a portable library that can be used on all the popular mobile platforms and from all the popular languages. That's a plenty big enough job, and would fix the concrete pain points with GPG without throwing out the good part.

> We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol.

What kind of concrete things would have to change at the protocol level? Plenty of good products conform to existing protocol standards, and a crypto protocol that has survived years of use in a hostile environment is worth its weight in gold. The talk of "modern" seems very handwavey as a reason to throw this out.

> GPG has such a small legacy install base (literally on the order of ~50k users), that there's no reason to maintain compatibility with OpenPGP.

I find it hard to believe there are only 50k users given that OpenPGP is built into the package-management infrastructure that every Debian user uses, and is required on Maven Central which virtually every Java system uses. Yes, these aren't people who actively chose it or are even aware that they're using OpenPGP - but protocols are like that; they're infrastructure.

And as for your 50k, that may be a small number but they're the people who really care about privacy. Snowden is among them. If you're trying to spread crypto, those are the last people you want to alienate.

> Write a ground-up implementation of (maybe a subset of) RFC 4880, with opinionated choices of default ciphers (a bit like NaCl).

That's what PBP does:

- Code: https://github.com/stef/pbp

- A short (9:03) talk by the author: https://www.youtube.com/watch?v=Kl_gLMef1mI

Thanks for the link, looks like an interesting project.

> HTTP is '90s tech. TCP/IP is '70s tech. There's nothing inherently wrong with that.

Sure there is. For one, we were talking about encryption protocols. Those are not encrypted. The one that is encrypted, HTTPS, sucks (the whole CA system). So after Snowden's documents came out I would've expected more people to say "it's time to get rid of HTTPS". That hasn't quite happened yet, and I'm disappointed by that. In case w

As for TCP/IP, again, not encrypted, and they need to be. In case we've forgotten, TCP/IP and HTTP is what made it happen for the Internet to become a giant spy machine. That to me means they are broken.

We need to switch to something like CurveCP, MinimaLT, Noise, etc, that is encrypted by default at the Transport or even the IP layer. If we agree "encrypting all the things needs" to happen, then the current state of TCP/IP and HTTP is horrible, and we're not moving fast enough to replace them.

The fact that we don't yet have a good encrypted by default alternative to TCP/IP and HTTP/S is what will also bring us a world of hurt when the "Internet of Things" arrives in a big way, along with self-driving "smart" cars that can be remotely updated (and hacked).

The CA system sucks but what would you replace it with? The only remotely viable alternative candidate is the OpenPGP web of trust, and, well, see the article.

Transport is the wrong layer to do encryption (much as I'd love to see more adoption of IPSec) because encryption and authentication are inextricably linked. Suppose you can confirm that you're absolutely, veritably talking to 174.16.23.46, and your messages can't be read by anyone but them. What good does that actually do you?

TLS is, despite all the problematic cipher suites, fundamentally sound infrastructure - which is why it hasn't been replaced. The same is true of OpenPGP. We don't need new protocols, just better implementations - an equivalent of LibreSSL for OpenPGP.

> Suppose you can confirm that you're absolutely, veritably talking to 174.16.23.46, and your messages can't be read by anyone but them. What good does that actually do you?

In the current post Snowden climate, can't we agree that this is at least a good thing? The good it does at the most basic level is protect your communications from prying eyes.

Does it though? There's no point encrypting everything twice at two different layers. And if you use an unauthenticated protocol running over IPSec, you can have a dangerously false sense of security.

> 1400 lines of python that tries to pretend that an interactive program is a library is definitely a problem though.

Yeah, +1 for this. The lack of a proper GPG library is very strange.

I'm in the process of writing a Python program that interfaces with GPG right now, and I was surprised to learn there isn't an official GPG library. The closest thing seems to be GPGMadeEasy [1], which is an official library wrapper for the interactive program.

Since I need low-level key manipulation (writing out a key with known values), what I've ended up doing is using the BouncyCastle Java library[2] via a separate Java command line program my Python program can call out to. It works, but it's painful.

So, yeah -- what would be the cost/benefit of the project lmm proposes to create a real, portable GPG library? It makes a lot of sense to me.

[1] https://www.gnupg.org/%28it%29/related_software/gpgme/index.... [2] http://bouncycastle.org/

Is anybody trying to implement identity-based encryption?

Perhaps it would be better to leverage your position and your knowledge and come up with something before you write up a post like this? As other commenters have pointed out, you're in a prime position to actually come up with a working concept instead of just writing your opinion about it.

I don't open a link to Paul Graham's site to read "Shit's bad, guys, and here are some fairly shallow reasons why I feel I can make that statement". I go there to read something that's been thought out by someone 'in the know'. Same goes for when your name is on a post about crypto. This was just whining.

That may be totally acceptable to you, but I don't think I'm alone in expecting more than just an opinion.

In case you didn't know, Moxie is already doing that https://whispersystems.org/

In any case, your point still stands, generally speaking.

Yes, I was referring to the post itself, which is essentially just complaining in the end. I am surprised it reached the top of HN, considering it really adds nothing.

Why 50k users? PGP/GnuPG is used to secure a _lot_ more than email.

Every Linux distribution signs packages with it. So that's at least 100M users right there. Several APIs regarding domain name and AS registrations is based on it. I know at least two financial systems that signs their messages with it. That's just mentioning a few I can think of right now. I'm sure it secures a lot lot more. It's used all over the place and it seems to do the job fairly well in most cases.

Is it suitable for signing email in 2015? I don't know. Things could certainly be improved. I know there are more suitable schemes for IM communciation. But the software and the underlying protocol is not something you can break in a heartbeat. It's important software.

Perhaps we need to speak more of the evolving use case in email?

You misunderstand, they are talking specifically about encrypted communication for the new use case. Think of it instead as trying to replace email for unencrypted communication, you need a different use case as the user base is too entrenched. In contrast GPG encrypted messages are a small community.

The fact that GPG is used for other things is fine, as it will still exist and can still be used for those things.

I think you are blaming a slightly arcane program for what is essentially laziness of the population. Every time I read a comment on HN stating how PGP isn't usable I cry a little bit inside. GPG in no harder to use than git or many other tools professionals use.

The difference being, its worse to make a mistake using GPG than it is to make a mistake using most other programs. In the end, you are securing confidential information, which will always be hard, unnerving and require concentration and care. And this is just inherent to the task, which is fighting an undefined, super-powerful, ill-meaning enemy.

Encryption is violence. The objective is to violently keep an enemy away from your jewels. Instead of using an armed guard at your door, you use mathematical forces which are impossible for your enemy to overcome. Imagine your enemy needs the cleartext to save his own life, how does he feel when he is denied access and unable to gain access? It doesn't matter if its a steel door or a block-cipher.

What people are essentially demanding when they want "easy to use crypto" is a self-firing and self-aiming rifle with friendly-fire detection. "Keep all my adversaries away but don't bother me about it."

That's not how conflict works. If you attempt to secure your communications from a state actor, you are engaging in a full-blown combat against one of the most deadly forces there can be. That conflict will always be demanding and unpleasant. GPG being "hard to use" will be the least of your problems.

But no, we want everything for free. Protecting yourself against the overlords should be easy and painless, almost automatic. The defendant shouldn't have to learn how his defense works or how to properly use it.

Seriously?

EDIT: And what I find unnerving about your post is, suddenly the people who put in the effort to use GPG are the bad guys? The 0.1% who actually take privacy seriously enough to go through the the trouble? Don't get me wrong, I almost never use GPG, not because it's hard to use (M-x epa-encrypt-region, anyone?), but because I don't want to experience the emotional distress related to struggling with a super-powered state.

I relly disagree that all is lost for PGP. Here's why it's a good idea to not just carelessly toss out the seemingly old and busted: https://blog.whiteout.io/2015/02/25/pgp-theres-life-in-the-o...

Couldn't agree more. I have public keys available and I understand the concepts at a high to medium level but if it's taken me as long as it has to get a grasp on it (And I still would need to do a number of google searches if I received an encrypted email) how can I expect all of my friends to ever get it? They want something that "Just Works" and so they gladly use (as do I) Facebook, iMessage, SMS, and Email. All unencrypted (Well iMessage is encrypted but I know they could easily view any messages they want). They still have password-reuse issues all over the place (my hands aren't clean either).

It's not that I don't care about privacy, I very much do, and my friends care as well (to a slightly lesser extent I would say and I'm willing to accept more to get to that point than they are). It's just that I am completely overwhelmed, only 1-2 of my friends even understand encryption at a high level and none of them expose private keys for communication. Even other developers I worked with got annoyed with OTR with adium/pidgin to the point I had to turn it off. It's not that I want to throw in the towel, I desperately want a solution, but even easy to use (what I'm looking for) "secure" communication tools get torn to shreds here on HN and so I haven't even considered trying to get them all to switch tools (even I thought it was possible, which I don't).

I guess what I'm trying to say is I'm not going to stop talking to my friends and my friends more or less refuse (due to complexity) to use encryption so what is the purpose of me even trying? The end result would be what? Maybe 1-2 people with which I can talk securely? Now I have to have 2 workflows and even if I have super-secure unique PW's, FDE (Full Disk Encryption, which I do use), and take steps to secure all MY data all of my friends are essentially leaking my data. So if the NSA/FBI/China/Hacker/etc want my communications they can just go after the weakest link, the people I talk to. It's very disheartening to say the very least.

I've considered blogging about this a number of times but didn't want to get destroyed here on HN (if I even posted it here, I probably wouldn't due to backlash) for being defeatist or get told how I am the problem. I am not a cryptographer and therefore am not qualified to even attempt to build secure software (if I even thought I was capable of coding up such a project). Even the tools that are easy to use that DO use tried and true encryption (Like PGP gmail/chrome extension, that's all well and good but what if I'm on mobile? Or on a friends computer? It's just too restrictive) are locked to a an OS/Browser/Device. I really do understand I'm asking for quite a lot (Cross-platform AND cross-device) but without those "features" there is no way I could get my peers to switch.

I'd love to have someone reply with how wrong I am how there is X tool/product/service that satisfies my requirements but I've searched high and low so I don't expect such a reply...

As someone who trains human rights defenders and journalists on this stuff...I couldn't agree more. Often things end up being an unfortunate tradeoff between trying to get PGP working for people and having to settle for something less. Particularly in the developing world, which lower computer literacy rates - this is a significant problem.

To be fair, at least Whisper Systems and the Guardian Project are doing great work to try to make encryption in various implementations work better for the average user. And let's be fair, groups like these and the LiberationTech community runs on a shoestring in comparison to even one large commercial tool.

For people like this I write a simple shell script that abstracts away all the complexities and shitty UI. Never tried working directly with libgcrypt, I just let the regular gpg application handle it. Decrypting incoming mail automatically, checking to make sure outgoing is encrypted before sending and even regenerating keys and signing them is just a few shell commands you can script away. Projects like Tails should have this instead of big clunky GUIs.

Interesting. Are you thinking of making the script publically available? I'm sure a lot of people would benefit from it.

I was thinking the opposite--most shell scripts seem to exist to show off arcane knowledge rather than document a task in the most straightforward way possible.

It's a hacky shell script for OSX to make the process almost invisible to the user without using in-house mail servers or writing network facing daemons. When users launch their mail app it also launches the script (and mail console applescript) that command line fetches mail, decrypts and inserts into mail.app db, looks through msgs for new public keys and extracts them, updates contacts automatically with GoogleCL and gpgtools, then starts offline mail client to view/reply as they normally would. The script then fetches outgoing mail, gpgtools encrypts it according to destination, verifies it and sends.

GPG key ID is automatically inserted into contacts https://code.google.com/p/googlecl/ so when the user deletes a contact the script reads the KeyID and removes it from the keyring as well. It had to be Google contacts it wasn't my decision. Nobody wanted to change their mail app workflow and they couldn't figure out gpgtools/gpg suite so this poor scheme was devised but it works.

The janky part comes when the script checks mail console logs to detect no connection errors when users req to fetch new mail (and suppress popup notifications of this) so they don't have to push a second button to do it outside set intervals that fetch automatically. For some reason it was important that no other buttons existed to fetch new mail. There's probably a Claws Mail plugin that can be written to accomplish all this too if users were willing to switch apps, mutt will do most of it automatically and can be abstracted to make it invisible, or script OpenSMTPD to do this.

GPG is an immense failure from the point of protecting person to person communications.

It is largely a success in verifying the identities of the software developers. The entire Debian ecosystem relies on GPG in largely successful ways.

Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication. It appears the PGP just can't be bootstrapped into modernity from a communication point of view. The only major innovation in authentication and identity has been threshold signatures which GPG could support.

> Peter Todd suggests that PGP drop encrypted communications as a goal and focus only on identity and authentication.

Identity and authentication are the biggest reason that PGP hasn't caught on with non-technical users - the web-of-trust is necessary to do distributed identity and authentication properly (under the current model), and the importance of out-of-band verification can be hard to explain. Authentication (as opposed to authorization) is hard, even without factoring in state adversaries.

The fact that the web-of-trust hasn't succeeded doesn't mean that another model won't, but I don't think it makes sense for PGP to throw out the one goal it already does incredibly well (securing communications) in order to focus on the biggest problem we haven't been able to solve in 20 years.

WoT works well for some things like #bitcoin-otc IRC trading channel but still most users aren't checking sigs.

I like how they wanted to completely remove identifying info and similar signature schemes from signify http://www.tedunangst.com/flak/post/signify

It isn't clear that we should want PGP to succeed from a communication point of view. It's clear that PGP has succeeded in protecting communications of a some subset of users for the last 20 years. Because of the lack of forward secrecy, it isn't clear that this would scale and how common key theft is.

My opinion is basically GPG for identity and Axolotl for comms.

There's no other model than the web-of-trust. And it didn't fail because it's hard to grap (it's really not), it failed because a) almost no one needs it and b) the tech is hard to use.

Imagining a world where the web-of-trust was succesful is not hard. It starts with everyone using Outlook instead of gmail. Then imagine Outlook having PGP support builtin. Then imagine in the contacts list, every contact was marked with a color, red, yellow green.

Whenever sending an e-mail to a red contact, Outlook would display a small one liner on top of the compose box "There is no identity information about the contact you are sending an e-mail to". (it doesn't matter that no one knows what that means, it's just a small nag that people understand is negative)

Whenever sending an e-mail to a yellow contact, Outlook would display the following nag line: "You have not verified the identity of the contact you're sending an e-mail to. Click here to resolve".

When the user clicks the line, they'll be asked to call the contact on the phone, or meet with them in person and ask them to compare keys. (Perhaps aided with some fancy tech like NFC or whatever)

Will people ignore the nag line? Yes. Will people click through the dialogs to resolve the nag line without actually verifying? Yes. Does that matter? Not as much as crypto-purists would have you believe.

There's always that uncle, niece or colleague that's going to be anal about it anyway. And if the web of trust is big enough, and the devices enabling the web are communicating, it will be very easy for the web to self-heal whenever corruption arises. Just imagine if whenever someone who purports to be your aunt sends you an e-mail, and your e-mail client automatically checks the key with everyone elses in your family.

The only reason the web-of-trust doesn't work is because it was never adopted and made usable by the important software developers. And that never happened because not enough people cared.

At the risk of being inappropriately snarky, to someone who is somewhat skeptical of WoT-based proposals, this reads like:

Step 1: the UI will be a mixture of meaningless and annoying to users, causing them to ignore and misuse it

Step 2: mumble mumble... self-healing corruption

Step 3: the only reason this hasn't succeeded is that people didn't care enough

It's exactly those parts in step 2 where I've historically fallen off of the WoT story. What does the UI do when my nontechnical friend has marked my key but his dad has marked it as untrusted? What happens when I lose my phone with my keys on it? How do we not end up in a situation where users see big scary warnings all the time constantly and they just learn to ignore them?

I think part of the problem that the OP is sort of addressing is that we've spent so much time trying to gloss over the first-line failures of PGP, in terms of even getting a key to begin with let alone giving it to other people, that we don't even know if there are practical solutions to the problems you're listing.

Every tool in this space suffers from the choices PGP implementations have made and asking what your uncle would do if trust conflicts occured when he's going to first be asked if he wants an RSA/RSA, RSA/DSA, DSA sign-only, or RSA sign-only key before he gets there, and then have to figure out what keyserver to send to and then....

Answering these high level UX questions requires having actual users.

Frankly, red/yellow/green is an excellent solution. Do I care now? No. Do I care when the secrecy is important? Maybe I'll not send things to non-green users.

It's not a pitch for implementing WoT. It's a thought experiment to show that it could be viable. It won't make anyone happier if that's what you want, security never made any UI more pleasant.

The system might send you an e-mail if someone casts doubt over the trustworthiness of a key. If you lose your phone with your keys, they're gone, just like when you lose your keys.

I never said big scary warnings. Just small reminders that what's happening isn't secure, like the green bar in your browser. Most of the time harmless, but informative when you need it.

> There's no other model than the web-of-trust.

SPKI & SDSI had a different model: rather than trust people to tell you who someone is, one trusts them to tell you who they think they are. That is, rather than me verifying that key 0xDEADBEEF belongs to the individual known to the town council of Lower Shroppington as 'William Morris' (which is inherently fragile: I may not be an expert at verifying identity documents, or at verifying those issued by Lower Shroppington; the individual before me might have a document issued by Lower Shroppington deliberately to mislead me; heck, who is the real William Morris: there could be more than one), I would just verify that this is the individual I call William Morris, and let you make use of that as you may. If Lower Shroppington wanted to, they could issue a certificate stating that they call him William Morris too.

It was a really smart way of doing things.

How might it fit into a modern email infrastructure? Easy! example.com could use key 0xBADDA451 use certify that foo@example.com belongs to the keyholder of the key 0xC0FFEEBA; .com could use key 0xFEEDBAC7 to certify that example.com belongs to 0xBADDA451; the root domain could use key 0x55378008 to certify that .com belongs to 0xFEEDBAC7; IANA could certify the ownership of the root domain; the ICANN board could certify the current IANA key; the previous ICANN board could certify the current ICANN board, and so forth.

What would you see in Outlook or Gmail? Your agent would display that the claimed sender email is valid. It might also try to find some path connecting you & good ol' Bill Morris, then show you that your buddy Steve's ex girlfriend Wilhelmina says that key belongs to Billy Morris.

Interestingly, this could even work for an email legitimately sent on William's behalf. All a normal user would care about is, 'this email is legit' (for some value of); us geeks could geek out as we wished.

So that's the authority model, or the 'tree-of-trust'. In a good trust model I think it can't be more than just a weighting or advisement over your web-of-trust, never your sole source of trust.

In the end a tree-of-trust rests on the fact that you trust the manufacturer of your laptop that they put trustworthy certificates there so you could verify the roots.

We're seeing the major browsers now turning that tree-of-trust into a web-of-trust by cross referencing domain certificates to see if there are duplicates or other shady things going on.

Perhaps I didn't explain well. SPKI/SDSI specifically isn't the authority/tree-of-trust model: although it could be used as the infrastructure to build an authoritative, tree-of-trust system, it could also be used as the infrastructure to build a web-of-trust system, and it can be used as the infrastructure to build an even less trust-requiring system.

> In the end a tree-of-trust rests on the fact that you trust the manufacturer of your laptop that they put trustworthy certificates there so you could verify the roots.

For hostname and IP address ownership, there is a central authority: ICANN. The problem with the CA model is that someone other than ICANN can lie about who owns a hostname. As for the ICANN roots, those should be publicly known and verified in the same way that any information is publicly known and verified (ultimately, it comes down to verification).

The problem with ICANN being a central authority is that knowing that I'm talking to the legitimate owner of 'apple.com' tells me nothing. It could be Apple Records or an apple farm or a guy who just really likes Apples for all I know. The CA system uses a ridiculously expensive, painful process to do ICANN's job for it, and still doesn't provide me the guarantees I need in order to do business online.

With respect to email, I can use a tree-of-trust system to guarantee that I can send email to the legitimate owner of an email account, but I cannot guarantee that said legitimate owner is the person I think it is (after all, ICANN in a very real sense owns the Internet, and could transfer anything to anyone). If I wish to, I could use an SPKI/SDSI system to ensure that I'm sending a message to the person who the person who the person who I think is Jim thinks is Sally thinks is Bill.

Which, really, is the only way trust can work anyway. What does anyone know other than what he has heard from others?

GPG still could be much better for those applications. For example, it is still impossible to do GPG multi-sig (e.g. have the application developer and the distribution release manager sign off on the binaries).

Can't you just create two detached signatures?

At the expense of lower validation speed and requiring every higher level protocol using the signatures to be aware of whatever signing scheme you are using.

The old adage is that perfect is the enemy of good enough, but the author is claiming that GPG isn't even good enough. I have to somewhat disagree. While the ideal product in this space would be as easy to use as clicking a 'Like' button, and just as ubiquitous, GPG works well enough for now.

The most sensitive use case for GPG has to be sending correspondence that, if decrypted, could put you in severe physical danger. If the choice is between life and death, relative freedom or torture in some black site dungeon, the choice is clear. Using GPG is preferable to death or torture.

This doesn't exactly seem like a ringing endorsement, but if these are the stakes, then you are probably willing to read the equivalent of 40% of Fahrenheit 451 to be secure. You are probably willing to learn to practice good opsec.

It would be fantastic if GPG were displaced by something equally trustworthy and secure, but more user-friendly, and I look forward to the day that happens. But I think that GPG is the best we have, and we should be appreciative of that.

I use GPG often and it gets the work done. It might be the author is not happy with the long process of using GPG and the shortcomings of the documentation. I think if GPG is integrated with more applications, it might have a lot more users.

Using X is preferable to death or torture.

That's what I call faint praise.

faint? I'd rather read 100 pages of man than die.

Seems like a meager price to ensure another 70 years of life.

http://en.wikipedia.org/wiki/Damning_with_faint_praise

The point is when "virtually everything" is better than death or torture, it's not saying much when that's how you praise using GPG.

You've missed out "Use GPG, but perform one of many steps wrongly, and thus face torture or death".

See also "deanonymizing alt.anonymous.messages"

https://ritter.vg/blog-deanonymizing_amm.html

If the potential to be rendered to a blacksite or tortured to death somewhere less polite isn't sufficient motivation for people to be careful, I'm not sure "security" is their biggest problem.

I don't think that the author ever disputed that GPG is a highly secure system when functioning, or that it is "the best we have". Certainly it's the best we have, and that highlights the sad state of affairs.

I think a lot of engineers make the mistake that regular people will be so won over by a new technology that they'll learn it as well as the engineers do. That isn't how it works. So far we still haven't gotten regular people to learn programming, though more people program than ever before.

Humans like simple. This is not a flaw. Software can do anything, and it is written for us. We should not have to learn a bunch of arcane commands, skills, and concepts unless there is no technical way around this.

Ideal encryption would have a quick initial setup, and then each message would have a sticky button for "encrypt?". Then whatever is required in the backend does what it needs to do.

Complex software that gets the job done is much, much worse than simple software that gets the job done. Unless things get so oversimplified that there is no way to verify correct operation. I agree that people need to learn about encryption, but there's a middle ground between no knowledge and knowing enough about it to use GPG.

The problem is that security and crypto specifically, is a complex beast, so often it isn't possible to abstract away the details.

You cannot expect to avail of the benefits of crypto without taking some time to understand how different protocols work, how public key vs symmetric key crypto works, etc.

I agree that the situation could be much better than it currently is, but people can't expect to be given everything for free; there mist be some effort from the other side, which I don't see happening today, especially with the widespread disregard for mathematics in the general public.

I have to say I really disagree. Why would someone need to know how different crypto protocols work? Do facebook users know how TCP/IP works? Or are they just given a series of user interactions required to make the computer do what they want? Couldn't we do this with secure communications software? I don't need to know why a certain crypto method is recommended, for example, if I know that a trusted party recommends it (say - Edward Snowden and Jacob Appelbaum).

We could have an open source crypto program with a set of basic modes for use. Maybe "mode 3" is good for basic interaction, while "mode 5" is recommended for whistleblowers but requires another step in the physical world, while modes 1 and 2 are deprecated because they were discovered to be vulnerable or weak.

The above is stuff a regular person can understand. Do they need to know how these modes work? Well, they need to know what input is required, but they don't really need to know how it works behind the scenes if they trust someone else to recommend the basic modes. Then it must certainly be possible to write software that walked a user through how to complete the required information. It could say "plug in your secure USB key now", then "type in your passphrase" and then "remove USB key to continue".

Really, I think engineers have a hard time seeing how easy we could make things. Yes that would all take a ground up rewrite and open source projects don't do well with that. Yes it would be easier if people would just learn, but that's a fantasy and we should understand that.

It must be possible to make a secure communications "wizard". Disregard for mathematics has nothing to do with it. People want to know what to do and they want to use as few steps as possible. Installing a handful of command line utilities and remembering a bunch of commands isn't the answer. One program with a simple graphical interface must be possible.

Actually this is not correct. There are now situations (such as in the United States) where merely using GPG puts you on a list of suspicious people. So not only is GPG not "good enough", but using it today makes your life worse than it was before. There are places where using GPG can lead to death or torture, even if the message is simply your grocery list.

In order for GPG (or its replacement) to fulfill the dream, it needs to be the norm rather than the exception. There are some companies who could prod things in that direction. GPG acting alone is absolutely not the future.

Besides, the cryptography isn't even very good. There is no forward secrecy, for example. I believe that email has to change at the protocol level in order to fulfill the promise that GPG (PGP) makes. And with so many interested in preventing the security of email, well, it seems like secure email is a dead end. And that's a real shame, because I love the idea of being able to securely send a message between two people on the Internet, using open source software and without trusting any intermediates.

> There are now situations (such as in the United States) where merely using GPG puts you on a list of suspicious people.

What's fun: using ssh might be similar.

> The old adage is that perfect is the enemy of good enough, but the author is claiming that GPG isn't even good enough

That's something you say while building it, so that you get something working built instead of debating what should built, or instead of adding so much stuff that you never finish. It's not something you say to discourage people from improving something that's already shipped.

>When I receive a GPG encrypted email from a stranger, though, I immediately get the feeling that I don’t want to read it.

This is an interesting case where a barrier to entry makes discourse less valuable. Perhaps the barrier makes people feel like they have to prepare a short speech in order to make the effort worthwhile. I certainly would rather converse with most people than listen to one minute speeches from them.

If you ready on, you'll see that his gripe isn't with the effort put into decrypting, but the subset of people who voluntarily use GPG.

Still, I don't think people should stop using it.

Ironically unsaid:

"People like myself for twenty years and nothing to sell."

I'm talking about the effort the sender has to put into encrypting.

Sorry but what is the actual point of this blog post?

GPG is just one guy. Who's practically beggared himself writing and maintaining the tool.

GPG is actually used by human rights activists, journalists etc. That, right there, is reason enough to celebrate it and NOT "kill it off".

I think the massive pile-on this is creating is really dumb, to be honest. So Moxie thinks it could be done better; that's great. He's good enough that he can "show, not tell".

Why waste time denigrating a project that's basically a labour of love for one guy that is actually tremendously important, even if it's "90's technology"? Old doesn't necessarily mean bad.

We need very good quality encryption software that is not really hard to use.

PGP is impossible for many people to use correctly. That means there is a bunch of -- often insecure -- software to fill the gap.

So the people who really need PGP/GPG have to struggle to use it and don't know if they've managed it or they use some other software instead that probably doesn't protect them.

It's not about GPG sucking; it's about the absence of anything sucking less than GPG.

It's not about activists and journalists being (more or less) able to use GPG; it's about the fact that nobody who doesn't face as deadly a risk as them would bother to use GPG.

I didn't feel any denigration reading him; rather, the statement that:

* We have new crypto needs, in wake of revelations such as Snowden's;

* GPG isn't an adequate answer to those needs, and isn't likely to evolve into one;

* Tech people don't realize that GPG is unlikely to morph into an adequate solution, and therefore don't bother starting an alternative.

Finally, I believe that a successful answer would rely on excellent UX and PR at least as much as sound crypto. I'm not aware that Moxie is an expert in these fields (although he might have more talents than I know), so it's not obvious that he's in a position of showing rather than telling.

> Why waste time denigrating a project that's basically a labour of love for one guy that is actually tremendously important, even if it's "90's technology"? Old doesn't necessarily mean bad.

In the world of crypto, where we've learned so much, yes old means bad. Almost always.

Why denigrate GPG? Unfortunately, because the message that it's not good isn't being widely heard.

How many NEW crypto projects are being created that start out by saying, "first we will use GPG"? I've seen lots. OK, you failed right there, right at the start. Don't do that.

How many crypto geeks STILL spout rubbish about how the PKI is totally busted and the web of trust is the future? Way too many. WoT is sort of like the year of desktop Linux by now. It's just a bad joke that too many people won't let go of.

The most serious and effective applied cryptographers I know about are all ignoring GPG and rolling new modern crypto protocols. I feel the same way as Moxie - if you build a product based on GPG then almost immediately you are less interesting than a project that's doing something new.

And FWIW I have the same sinking feeling when I get a GPG encrypted email. Sometimes I don't read it immediately, I put it off. Sometimes I have to put it off because I'm not near my laptop. And when I decrypt it, inevitably I discover that I could have guessed the contents of the mail from the subject line and identity of the sender. The encryption was largely pointless to begin with.

The future of encrypted messaging is not GPG. We need to collectively let it go.

I think it's mainly GnuPG's fault. There is no API, so developers can't integrate it into their applications. The only way is to pass arguments to gpg binary and interpret the output on STDOUT using regexes. The "libraries" that exist for Python and other languages all work like this. That is why they require you to specify the "The path to the gpg executable."

If GnuPG provided a real API, then there would be hope, because the actual OpenPGP specification isn't that bad if you only implement and use the bare-minimum features.

This is one of the reasons my company developed support to deal with PGP signatures directly in PostgreSQL, without using GnuPG: https://github.com/trustly/bankapi/tree/master/debian/postgr...

It's a bit funny it's now actually safer/better/easier to use PostgreSQL instead of GnuPG if you are developing an application which uses PGP, as your only option is to pass input to the gpg executable and regex it's output, which is hackish and not suitable for production purposes.

Creating a GPG alternative is hard. That's pretty much the only reason why it's still around. That, and the ubiquity of e-mail.

Sending encrypted/signed e-mail with GPG isn't hard when you're using things like Enigmail. Maybe the GUI could be a little friendlier, I don't know, but the encryption part isn't hard. Key management, now that's hard. Not just in terms of usage, but in terms of explaining it to new users.

On the one hand, both parties need to somehow exchange keys before they can communicate in a secure fashion. Doing this is hard, and if done wrong can leave you vulnerable to attack. That's why we verify key fingerprints. If there's an easy way to make this painless, I don't know it. Central authorities like what we've got with TLS/HTTPS are obviously a steaming pile of shite. Decentralized (like GPG) are difficult for users. What else is there? I don't know.

>When I receive a GPG encrypted email from a stranger, though, I immediately get the feeling that I don’t want to read it.

>the email was written by someone who would voluntarily use GPG.

>There just seems to be something particular about people who try GPG and conclude that it’s a realistic path to introducing private communication in their lives for casual correspondence with strangers.

Is it just me or is the implication here that anybody who uses PGP is usually a kook of some kind?

I think the implication is that GPG is so pathologically complex, awkward, cumbersome, and broken that getting GPG-encrypted e-mail means it's from someone who's so paranoid/obsessive that they encrypt all e-mail, even to strangers (when possible?) even when the tool is so awful as to discourage the average individual.

>someone who's so paranoid/obsessive that they encrypt all e-mail, even to strangers

That's pretty much what I meant, clearly somebody didn't like me bringing it up. I wonder why. I have to use PGP every day for my job, I don't feel like a paranoid/obsessive, so I resent the implication a little bit. It's a clunky piece of software, but it hasn't caused me nearly as much suffering as Lotus Notes.

Don't bother. While I have much sympathy for the average user and see several problems with PGP, the gen-pop here is creating way too much buzz around a tool that is working reasonably well.

And with respect to the PGP-user / character link.. this is just beyond stupidity.

Indeed, that argument is utterly stupid.

First of all, if he receives an encrypted email from a stranger, this is because he has a GPG key, too. So that stranger had every reason to assume that he's also a "GPG tinfoil hat".

Sarcasm aside, using GPG for minor stuff is not about paranoia, but about protecting minorities! This includes discriminated minorities as well as whistleblowers, investigative journalists, and so on. I for myself may not need that level of protection, but others do. Maybe even the stranger I'm writing to. The more encrypted communication we have, the less minorities spike out who really need that protection.

So encrypting everything is not "I fear", but a political statement. And that political statement is simply "I want encryption to become the norm rather than the exception, to protect minorities".

I appreciate the sentiment overall but I have the exact opposite reaction when somebody emails me with a GPG signed or encrypted email. I immediately think it's great that somebody actually cares enough to voluntarily use it. That the contents of the email are deemed important enough that they don't want it sent in the clear.

Curious as to how often this happens? I suspect had I ever received email signed, I would be excited too. But I think it might be due at least in part to the novelty of it. I'd bet moxie gets more than the average user and perhaps maybe even is a bit...jaded isn't the right word, but being entrenched in crypto and knowing the importance and knowing the barrier to entry...overwhelmed. Not by the process, but by the hill yet to climb.

This is a very interesting point, all the more interesting that it takes someone with Moxie's clout for the message to come out.

I've been in and out of the "GPG everything!" group over the years, and I definitely agree that GPG is a pain to use. I always figured this was because of the lack of proper frontends, and was hoping for the major influx of funding a couple weeks back would help it make progress in usability and infrastructure, but Moxie says that it's obsolete at its core.

But if we're to replace it, the replacement has to not only be at least as secure, but also standardized and embeddable. A webapp or Chrome extension (which Google's End-to-End is) won't make the cut.

Mailvelope has made some strong efforts in this area. Though only as an extension.

As a member of the encrypt-everything clique I have to say, though Moxie has a point, Gnupg is infinitely better than alternative of nothing at all. Until someone comes up with a solution that preserves its power and flexibility and marries it with a functional UX -- I shall keep using it

I kinda like the solution of embedding public keys in email addresses:

name+8znBcmtXJ2ZeSn7fWVCGfpQI9HnJH1pNBPK397SGrT8=@gmail.com

Sure, you'll never actually tell someone this, but it's short enough to copy/paste.

With modern ECC this is actually feasible.

Isn't IBE quite slow? And also it requires a third party for keygen and so on.

What is IBE and who said anything about it?

I was talking about EdDSA.

IBE is Identity Based Encryption, and it allows you to use your identity (name, email, etc.) as your public key.

There's nothing special about EdDSA compared to other digital signature schemes.

EDIT: Oh, I realize you were saying that ECC allows much shorter public keys than most signature schemes.

Yeah, that's an actual ECC public key in my example above.

I'd recommend going base32 instead of base64 (case sensitivity won't screw anything up) and not padding with = characters. I know not padding violates RFC 4648 but I don't know anyone who's used to a = in their email address.

Base32 would be too long, but maybe the equals sign could be elided, yeah.

Base58 it is, then (no non-alphanumeric characters so you can double click and it will select the whole string, no similarly-looking characters you could mistype (1 and l, 0 and O...))

(https://en.wikipedia.org/wiki/Base58)

I like the idea, but you'd be amazed at how many databases only allow 30 character email addresses, or javascript email validators that don't recognize "+" as a legal character.

I've always wondered if there was a way to transmit the public key in the SMTP envelope, to make it easier to share keys.

Someone has started building this:

https://github.com/diafygi/emailpk

Note that the article author is the author of TextSecure http://en.wikipedia.org/wiki/TextSecure It's not surprising that he prefers TextSecure over GPG in the context he explains:

"introducing private communication(...) for casual correspondence with strangers."

It's obvious that author prefers his chat for that. Still there are scenarios where the GPG wins over chat. But it's also true, most people would make serious errors if they'd try to use GPG.

I don't think he is trying to push the use of text secure over PGP, he has admitted that there isn't a replacement for PGP yet. He is just a forward thinker, hoping for a future where strong encryption is ubiquitous.. and not the state where PGP is today.

Articles (and the attendant discussions) like this are incredibly useful for me. I really appreciate HN for things like this.

Recently signed up for keybase to check it out. Read critiques (mostly negative) but jumped in anyway as I am hungry for something like it. I do not have a deep grasp of the arguments but I see the 'lipstick on a pig' criticism of slapping a gui on an aging infrastructure.

The practical problem with keybase for me is finding people to test it out with. I've added folks who don't know me and my friends couldn't care less.

There is a blindspot for me - I use ssh and rsa on a daily basis, many times a day. I do not know what I would do if I has to switch to something else. I do not know how to evaluate security options and know to know one is better than another.

We have very good infosec people in my company and have a standing weekly meeting to vet my sysops doings.

In any event will check out Whisper Systems and keep refreshing this discussion...

Just signed up for keybase and in the same position. Don't know anyone on the service to actually use it with.

Interested in testing it out with me?

If no one's taken you up on that, here's a message for you:

-----BEGIN PGP MESSAGE----- Version: Keybase OpenPGP v2.0.7 Comment: https://keybase.io/crypto

wcFMA5S7hsT55Ka3AQ/+K3YTd9aLF70PcDuDzUSBwt42I4UJdASvSzU9ljJZhxmh xn/XgzfuPVEqi75jhI20SfKJetR867leishDNU/XrynFCyJcr0ax6Q6BQes/w94d ErmBchxcYwFumB0i0tWMygmCUKgpL7W5bC26gB4AUdoPhhdJQnHYwiLvEv+e1G6I wFEA2/WzJlB+K+4v782zF7RhZaTA6OXl0noL6Nsoi2V/yufD5qKVnolx3RSHzdTd 1bSdS7lTCIQzvDmuLYvkophBL6Vb6Qa8IdwkLVxt+akr/W4oOxLaEE14HxS05OTO bN0R5yXzNNI7RWfU4cB3JKUMSKLGB4cBf+jEj1WyGCm04/9I1XgnNqFULE4RfHwG t8mqS1oeetfKlrzEx7NkXVn7mvITiYUzeH+M/DaTlnp5+Nb1FgQK1U54emIgEpmR qaG9JYDxZBtmBQ2gb3RtXndZFWQh7YifqaDFsUkJl4cdjXZ69WccvFRr+Vr3Ow1O m19lrHAFj4XZtsS9C1PNBejpdcfANoWjG+9Eitd6iliAo4nCG9jUi/6mIWRuamcs OS2uAAWMe1ZrfhwwU/x2+/QM6eGKU43DBLy9lmyFj2UgZKW1UokQg7iAp3Wd0f+Z SBEXNFsM3rPoYVb29boUcJtkA4CpArH36kIBv45A9u1c14uTUVRreGeLe1pqrsXB wEwD5S1urhQzgBEBCACk1jR8gIaMRKCsl7ofIjGr8PrrOYVCkNtpWjGsNnq+SFkG SUUekwzB0MfRVSdrkfVk/7Axrm0YGWqW9v12aNrrRLe8Vs/VJU9r2RRBgI164YbI UDxlGBJZhNnG1BxPVt1en1nH9ceEw4yq15giSxRMOhtlmpdv6Y0HIWzhnAb+Hc68 rxFq74j2wEfkHkIYJV7cOZtXy9WF0WHVgi0wIyiDHvV84KTO5HUv2qA1uJiqt3UU phq+lmFr3DzH7mcz2vLBW8r1AeFOd9VtRNVPkLEaVIjlCPGTYgr0hCfUX+JSf6PN 1VSRdogjcBu5Cqui60Fz9RKQvPCpX0NAUJpEZ30H0sEQATqCbZ/PF7nEqVHAOoH4 FK+Q6cR4+8iArPnUjr0lP0KWaQDJBghbYqQ8aUX37NUJaih7wae1b5WyBBCtwilI GowCJXwiD0kd7xUns61MhNDSn2K2ZPifHptJcv5QvODLkoJSHP4ylqCa9SrzyFNR gpRk3I31NIxZd7M5PT8fepQ75qTOgZ/v8ZTEd0HbPpjjRNJ3hMtIo7nmzPk54aD7 182jBWbXhiYiTTYEExnGwq+uDHoQjtGGBQzJegqeNex/q3Ba7Lf5RCbfFXQy3aDj JGRY6rZCQFbtcym2fjxeT9lRmHHeXA400zeLXgbqmmAKAcQwBtQQIF4Cg/cDNItN 6o5Jov0+pAm/NKKRWIXGJErGXsi0iTqJyl0anasbrQH6dnEXNbbMslIOtDl9CtKR N5Y+x+vJJKsOQaT6dJmQHZ19RxW4tickEr6zEu6IhB8ooMGMAjdq+tpRAF4+qKyK /yWUTIpp14deORe3aK7Hu0mA6H9dxDfwNwvat3Iv8R7YbsILdp7sFBPBlVLRLoBp BlYe7Eqroe7dCLg+v9Uw3Hpbu0yp3/BY64H3Qj9f7X3HQ+6nHQ0oQNS6XcwvJnKo JTV8lO263q0P7+Pti05SSs4= =gLgR -----END PGP MESSAGE-----

It seems that the biggest problem with encryption in general is that of incentives. Great UX takes lots of design and iteration, which means someone has to pay for all those designers and front end devs. However, when you want good encryption, user experience always comes after security, which means you spend the majority of your resources on the security, not the design. So, we end up with great security and terrible user experience. It's (painfully) rational.

Sure, every once in a while you have good security luck out and land a great designer (TextSecure), but that's extremely rare. The vast majority of security teams don't value design as much as security because they don't have the incentive to.

So how do we fix the incentives? Can we? Should we?

I think part of the solution is to get security teams to recognize that good user experience is a part of secure design. If the interface allows users to make mistakes that compromise security then the software has failed. You can blame users for making mistakes and tell them to read book-length manpages but that doesn't solve the problem. Most users don't want a swiss army knife and directions, they want a complete solution to a specific problem.

> However, when you want good encryption, user experience always comes after security

I'm going to throw down a gauntlet: encryption design that doesn't start with designing for the human users is already fundamentally broken. Why? Because it cannot represent a solid system. This isn't machines in the Matrix talking to one another: the needs of the human users are the only thing that matters.

Combine that with the past few decades of experience in software encryption systems, and we realize that this is hard to achieve. The non-adoption and misuse of GPG that Moxie speaks of, the train-wreck of passwords, and so on. It really feels like we've hit a wall, where there are no significant gains to be had unless these design problems are taken seriously. "Perfect" cryptosystems that have major real-world usability flaws are in fact worthless. Implementing new systems of this kind is a waste of effort and a disservice to everyone who vitally needs the services of a robust encryption infrastructure.

If you can't even get two machines in the Matrix to talk to each other securely, how can you expect to succeed with human error thrown in the mix?

That seems to be a straw-man which misses my point. I'm not saying that cryptosystem or broader security research is without merit; that's obviously false. Rather, the major problems with cryptosystems under large-scale adoption are limited not as much by technical encryption design, but by exactly the lack of human UX design that the parent post referred to. If your thinking about "end-to-end" stops at the computer and not at the human, that's become a rather enormous issue.

I think you're right that UX and good security are often at odds, but I wouldn't go so far as to say that they _must_.

I view the current state of security in applications a a result of two forces: 1) The human dynamics of the roles involved: The disciplines of security and user interface design overlap very infrequently, and very rarely done alongside one another, collaboratively; one always tends to drive the other. For user-friendly and secure communication software to be written in an open source environment, too many stars have to align. 2) The market value of data: Software which can be monitored, and data of its users aggregated, analyzed, acted upon, and sold is more lucrative than making something which is truly secure, even from the authors.

I believe usable encryption is possible, but I don't expect it to come from grassroots open source efforts, nor from the big market players. If anyone, I expect to see it come a collaboration between large non-profits (such as Mozilla, EFF), and universities. In the current environment, they're one of the few with sufficient resources, organization, and motivation to get it done.

I don't want GPG to get in the way of better, newer options. But even less do I want to read more about people burned by the incompetent engineering of lesser new alternatives.

Can we just declare a flag day and switch to TextSecure?

Yes, but not unless:

1. there are full-featured native clients for computers that aren't smartphones

2. it works with anonymous accounts, without needing a phone number

3. federation is open

Right now, TextSecure can't even fully replace OTR (for secure IMs), let alone GPG (for email <- real work).

To replace email, we might want named conversations as well.

Yea, remember that even in 2020 you would still be much better off using well designed 1990s crypto than things like Telegram or Cryptocat. And TextSecure is not a true replacement.

How about Chatsecure with Jabber and OTP? Isn't that a viable alternative too? Doesn't require you to use a phone number, so it works nicely on tablets or desktops (pidgin+otr), etc.

I'm sick of "opinionated software". IMO it's code for "adding more settings is hard". I'd prefer "sane defaults" as an operating mode, and maybe burying confusing settings behind a warning screen like about:config in Firefox.

Software that thinks it knows my use case better than I do is wrong.

In crypto options are dangerous, so it makes a lot of sense to be opinionated.

There are a couple alternatives to GPG being developed right now.

One is reop (https://github.com/tedu/reop). The cryptography is done by libsodium and it is well-written.

Another is NetPGP (http://www.netpgp.com/). The cryptography is done by the OpenPGP SDK. The NetPGP code is well-written but the OpenPGP SDK code looks like OpenSSL.

Both are promising and deserve everyone's support.

Reop looks exciting, perhaps as being exactly what a "fresh start" should look like.

I see the section on not supporting key revocation at all and it worries me, because it seems to me there should be some way to do so. But perhaps the key here is that this particular tool is not trying to solve the key distribution problem, which is a whole other kettle of fish? It is possible that PGP fails partly because it tries to do both.

But that does mean that a solution still needs to be found for that problem, even if you switch to reop.

> OpenPGP SDK code looks like OpenSSL.

I wouldn't be surprised to learn that intelligence services sabotage open source crypto projects by helping turning their codebase into an arcane mess, which scares away the million eyeballs which are supposed to make bugs shallow.

I've worked on OpenSSL quite a long time ago; I thought they kept it so messy in order to sell their expertise through consulting. At that time, only tinfoil hat folks would have believed that spooks would spend millions sabotaging everything and anything crypto-related... Now I believe that infiltrating open-source SSL / TLS / PGP developper communities is at least as strong a priority as infiltrating terrorist communities for them, so I'm utterly convinced they're trying, and I'd rather bet they succeed.

Reading this article over an unencrypted connection and viewing the resulting MITM attack is quite ironic:

https://i.imgur.com/hXNGb5l.jpg

GPG may be a failure, but HTTPS is not.

I'm eagerly waiting for something better to come up. There hasn't been anything satisfying so far, so I keep encrypting truly confidential communication with GPG, and it gets the job done.

When (if?) Google's End-to-End matures, it would be a game-changer for a lot of the less savvy users of GPG that I know.

https://github.com/google/end-to-end

Well, that is certaily an understandable position. I am very happy that such a software exists in the open source community, as unpractical it might be.

The trouble, however, does not start with the lack of UI design, or other impracticalities - for me it starts with the platform I choose to run a PGP type of software on.

Would you trust your Iphone, Android, Microsoft/Linux/iOS/Lenovo/Dell/et cetera computer with "really sensitive, mission critical" data?

I don't.

"The paranoid will survive" is a good sentence to remember. So I better install that PGP-etc on a offline unit and decrypt encrypt my messages there.

I'm not too sure. I am skeptical about the reality of replacing email any time soon, and more skeptical that a viable alternative for end-to-end encryption for email will present itself. If those two pessimistic assumptions hold true, then we're stuck with trying to make PGP easier to use. It's easier said than done, of course (I've tried and failed) but here's one way it could work: http://davidnoel.ca/specifying-a-pgp-client-that-your-grandm...

There's an interesting project that tries to replace smartphone IM application with an open alternative which builds upon the email infrastructure:

http://quickmsg.vreeken.net/

That could be taken as a starting point for how to make things more smooth for users.

GPG has been struggling with funding for some time now, but that's fixed: https://gigaom.com/2015/02/06/funds-flow-in-for-gnupg-author...

Also, to be fair, it's used widely by many infosec researchers/vendors/IC folks who know how it's done.

Is there a list of credible web of trust implementations with installed bases? Is there anything on that list using new Html5 crypto plus IETF JOSE?

> Is there a list of credible web of trust implementations with installed bases?

I'm not sure if this is what you're asking, but Debian developers are required to have their keys signed by a number of other Debian developers. So there is a comprehensive web of trust amongst them.

You can get the entire set of public keys from the "debian-keyring" package, assuming you trust your OS (and you use Debian or a derivative). And if you want to be signed into the strong set, find and ask a Debian developer (you probably have one reasonably local to you).

Debian is a good answer, but I meant alternatives to GPG, hopefully using modern crypto. Maybe Talko or some of the other secure comm apps? Anything open?

For 20 years nobody cared about crypto - how is it surprising that we have what we have?

For the future - progress does not come from just line of development, there needs to be many many experiments before we get good crypto. We need better UIs, and we also need many infrastructure improvements. I have not looked at the protocol itself - but it being flexible and having too many options is not really a problem - it is needed for the other layers built upon it to have space for experimentation. But the PGP related libs are really not good. I had once an idea for a Web of Trust related website - and I found out that there is no way to for example verify a signature without loading a full key-ring, that is loading all unrelated keys into the memory just to build the data structure used by the library. This is just one case - but it supports the thesis that the libs are a fossil from the last century. If we want better end user tools we need to give better libs for programmers to start the experiments.

I am curious as to to know what mail clients people are using with GPG. In OSX I am not a big fan of the native mail client at all but it seems thats the only approach if you want to use GPG. I am currently on a quest to find a decent mail client that looks good and works well and I am currently trialling Airmail 2 but its GPG support is buggy at best.

I have been using Thunderbird (with Enigmail plugin) for over a decade now. Never had any issues.

Other than using an email client application rather than a web application.

Enigmail is good though.

I used Thunderbird and Enigmail for a year or so. I later moved to Evolution for the better GPG experience (no flickering on opening the message as there is with Enigmail) and better GNOME integration. I used Evolution for another year, but its rough edges wore me down; I had to get in the habit of closing it if I wasn't using it, because it would noticeably slow my system down. It would take at least 5 seconds to open. Parts of the UI would often lock up and need a reset by switching between the panes.

I've been using Claws Mail for the past few months. It's simple, fast and stable, and GPG support is fine. That's all I need. It sucks for reading and writing HTML emails, but I'm okay with that. Parts of the UI are still rough (e.g. the main window isn't responsive while the "sending" dialog is open), but it's less worse than Evolution.

Thunderbird & Enigmail. 7/10 would encrypt again.

Mailpile (https://www.mailpile.is/). It's pretty bare-bones as far as a mail client goes, but it gets the job done.

mutt has excellent GPG support.

For encryption to be pervasive, it has to support all clients, on all platforms, without explicit user action. We can talk all day about the UX of tools like PGP but the bottom line is that the UX for email are mail client(s), and nothing else.

Strong crypto for emails has to work like https does for web browsing. Picture if people had to use some command line tool to generate and keep keys in order to do online shopping in their web browser. Compared to just using a (any) browser with https built in.

The amount of people that would want to use some native desktop email client for ALL their email work is likely even smaller than the number that use GPG today! If I couldn't read my email on my phone or on any computer it would have lost most of its value already.

I use KMail and the GPG integration is beautiful. But I can't speak to what KDE looks like on OSX.

In previous years I've had GPG/PGP configured, but not had anyone to write to or anything to write about.

We need entry-level e-mail clients to have GPG/PGP built in. Your post highlights the need to select a client which is why GPG/PGP has a niche user-base who send dull e-mail to Internet Celebrities who happen to share public keys. I mean my parents e-mail client, which would naturally be the default for their operating system (yes, Windows Live Mail), should have in-built GPG/PGP capability and the address book should auto encrypt any messages to me with the public key in my "contact" info, and decrypt any from me with their private key which is created and stored without them even realizing (as SSH does). It's hard to select an e-mail client anyway, but convincing my parents to select an e-mail client and/or plug-in, isn't going to happen.

I've been puzzled why fat clients traditionally have S/MIME built in, but certificates are complex to obtain, and don't have GPG/PGP with easy to create keys.

If you're not afraid of NCurses, sup (http://supmua.org/) manages GPG.

I use Thunderbird with Enigmail, but for some reason it wants to load up thousands of archived emails and crashes my computer. It is annoying as fuck.

While I really enjoy reading and sending encrypted emails, and think it's far better than sending sensitive data in the clear, I am surprised to learn that there are people who use PGP and don't hate it or have issues with it.

From what I have learned, security/cryptography is about protecting what needs to be protected for as long as is necessary (which is relative to the parties and data involved) - there is no such thing as "absolute" or "perfect" security/cryptography and probably never will be.

Based on that statement, "good enough" is "good enough" relative to the value of what is being protected. From my personal experience, while difficult for use by ordinary users, GPG has proven "good enough" (if not better) for most common business/organizational/personal uses.

That is not to say, that a better alternative/increased ease of use is not possible. Better alternatives are always possible (possibly hard), but it seems such an alternative has not yet presented itself. This leads me to believe that this is in fact an ongoing market and worldwide opportunity for those who have the skills to make alternatives real.

> When I receive a GPG encrypted email from a stranger, though, I immediately get the feeling that I don’t want to read it.

I don't understand why. Did I glance over it, or is it not in the article?

When I receive GPG encrypted email, I only have to enter my password and it gets decrypted. Simple as that. Same as when starting me email client, then too I have to enter a password to decrypt the login for the server. It takes only a moment really.

I don't receive that much email from strangers anyway, but the times I get GPG encrypted email from a stranger it's never spam, so it's surely worth the approximately three seconds to enter that password.

(For the curious, I use Thunderbird with Enigmail and kgpg as front-end to GnuPG.)

It's probably equivalent to receiving a letter written in green ink (British perception that letters written to media in green ink are more likely to be from what I'll charitably call fringe interestts)

Developer of phone-based crypto afterthoughts that give people a false sense of security and ignore the evidence that using phones is the worst thing you can do for privacy and security: "[my competitor] the most widely deployed message-oriented cryptography application in the open source world is crap". Well, yes and no. Forward secrecy is nice, but a world without forward secrecy and a workable standard when required is still arguably better than a world full of people throwing away insecure phones every six months while convincing themselves App1.2.3 makes them untouchably secure because n-marketing claims.

I think a major part of the solution is going to involve teaching people about public key cryptography in school. It isn't the sort of thing that anyone wants to bother to learn on their own. Without this essential understanding any attempt to get the general public to protect their privacy is doomed. Even if they somehow manage to go through the motions they are eventually going to do something to mess everything up if they don't know what they are doing.

Some tasks require understanding. This is one of those tasks.

How long would it take to vet something new? I don't know a lot about crypto but I get the sense that GPG is the gold standard for now. I agree that the interface is awful (and I feel bad for saying that after having learned of Werner Koch's financial situation) and it needs to be replaced. I wonder if some of the guts can be retained to avoid the bugs that come from starting from scratch?

I'm completely missing a discussion about federation. Sure TextSecure and iMessage solve UX in a great way. But what about business requirements that email/PGP does solve? More in our blog post here:

https://blog.whiteout.io/2015/02/25/pgp-theres-life-in-the-o...

When I imagine a world with an easy to use encrypted email system such that anyone could transparently use, I cant avoid imagining either a world sunken in spam, or a world where each individual no matter their computer skills" would have to maintain anti-spam systems. So we are back to square one regarding mass adoption...

I as a fairly technical person fine GPG confusing, despite being shown how to use it several times, and still have no idea whether it's working properly or if anything is actually being secured with how I've got it set up. Also, seems centric on the dwindling population of people who actually use email clients.

I'm not a programmer so I was hoping somebody could answer this question for me, why did Moxie choose to italicise the word python in this sentence:

"Mailpile had to write 1400 lines of python code just to interface with a native GnuPG installation for basic operations, and it still isn’t rock solid."

He means that you can do alot in 1400 lines of python, and if interfacing with GPG needs that much to be "not rock solid" there is something wrong.

One of the problems is the constant mantra: "crypto is hard--leave it to the experts", discouraging new tools from being written. Crypto is hard but there's a big community out there to help with auditing the codebase and fixing issues once a project gains traction.

Clever Marketing gig for TextSecure which has been rumbled by the third commentator on that page:

> Okay, since you want to play in the same league as OpenPGP: where can I find the RFC describing TextSecure? How many independent implementations of the TextSecure protocol currently exist?

There is Whatsapp, which is not compatible but uses the Axolotl protocol as well.

You can find the protocol on github.

I don't think that email is going to go away any time soon, so there doesn't appear to be a lot of alternative. I doubt that Moxie is suggesting that users send emails in plain text, so maybe email encryption needs to be reinvented.

I'm working on a GPG replacement that is designed to be super-easy to use. Not quite ready for prime time but if any HNers would like a sneak preview drop me a line. Contact info is in my profile.

> “I send you the private key to communicate privately, right?”

That could be fixed with a simple terminology change, call it the "secret" key rather than the "private" key.

Yes. This guy does not need GPG. But he needs a new haircut.

breaking news! </sarcasm>

ok. what's moxie selling next?

These rants are not very useful until one of the two geniuses (Green, Moxie) can come up with a comfortable solution to the core problem of key distribution.

And given that nowadays Green seems completely consumed by twitter while Moxie believes in fixing whatsapp, I wouldn't hold my breath.

Could you further ID "Green"? Do not know who that is.

Edit. Matthew Green?

Matthew D. Green, the "expert in applied cryptography and network security" who was invited to take a look at the Snowden-stash but declined because he was scared. Which is funny, because since Snowden he became some sort of web-celebrity always ready to tweet and comment on every little crypto/security issue.

Reply on news.ycombinator.com