Hacker News new | past | comments | ask | show | jobs | submit login
Cryptography Dispatches: Hello World, and OpenPGP Is Broken (buttondown.email/cryptography-dispatches)
160 points by FiloSottile on July 7, 2019 | hide | past | favorite | 70 comments

Can we stop saying that pgp is busted and just talk about how the keyservers are the problem with how people decides to exchange keys ?

I don't use key servers. So when I get an encrypted message from my friend I have no issues.

Allowing a third party such as a key server to play some role in veifiing the authenticity of a key is basically broken from tht start, and has nothing to do with pgp it's self.

OpenPGP is broken in the sense discussed in this newsletter: the keyserver system interacts in a catastrophic way with GnuPG's naive key parsing code, and OpenPGP's deployment at scale depends on keyservers.

OpenPGP is broken in other ways! But this is a headline given to a particular current events story about OpenPGP.

Then there is no need to say OpenPGP is broken.

Once you hand off the validation to a 3rd party that does nothing to validate other than a voting system of other people then you are done. You basically put your PGP keys on reddit and decided the key is valid because it made it to the front page.

PGP may be many things, but it is not broken, and saying so is blaming the tool for a obviously bad use of it.

It is obviously broken. Your objection is that it isn't comprehensively or irretrievably broken, and while I disagree, I don't have to litigate that, because the narrower sense of the word carries the article.

I don't think you can fall back on this being an "obviously bad use of the tool", by the way, since it's a pretty core use of OpenPGP. I don't use keyservers either (or didn't, when I still used PGP, which I actively avoid doing now), but I'm outnumbered by the people who do.

What do you use for secure communication in lieu of openpgp?

Signal or Wire, magic-wormhole. The obvious stuff.

And yet all of those bypass the hard part of validating the sender. These again trust the service.

PGP is more than simply encryption. It provides a means of trusted identity.

End to End encryption is pointless if you have no way to validate that a message came sender. Relying on automated systems for key exchange will always suffer from this problem.

That "means of trusted identity" doesn't work, to a first approximation nobody even attempts to use it, of those that do, a vanishing fraction "succeed", and their reward for doing so is the adoption of rickety 1990s encryption. Among practicing cryptography engineers, "web of trust" is a punch line, not a goal.

The lucky PGP users stick to the command line, which is so clunky that they'll use it rarely. The less fortunate will use PGP email clients which are so poorly thought out that they just last year managed to exfiltrate plaintext to attackers.

Signal use in the real world dwarfs that of OpenPGP; it's almost certainly many orders of magnitude.

I am not trying to win a popularity contest. If you care about secure messaging, and want to be sure you about who you are talking to -- then you have to use something like pgp.

I don't think the number of people using something invalidates a technology's technical merits. All we now have is a bunch of people thinking they are secure to one day have a very rude awakening not if, but when their communications are compromised at for the sake of popularity and ease of use.

Most of the arguments against PGP are about clunky clients, and such, this again is not a argument refuting the technology. Meanwhile the new systems solve the ui problems by dropping the most important part of encryption -- the ability to validate.

So for me, I will stick with gpgp and the like.

The only people who agree with you about the need for PGP in serious secure messaging are members of the PGP cheering section. They're an old and venerable social organization dating back to the pre-HMAC CFB-mode cryptography in PGP itself. I have nothing bad to say about their justified and ancient society other than that they are wrong about everything involving cryptography and that they recommend tools that get people hurt.

People who care very deeply about these problems and who have studied them more carefully than almost any message board commenter have evaluated PGP and Signal. Among secure messaging and cryptography engineers, PGP is alternately either amusing or an unfunny hindrance to progress. Signal, on the other hand, won the Levchin Prize at Real World Crypto.

Don't use PGP.

PGP is a protocol, there is nothing wrong with it. If you want to complain about good PGP based apps that is a entirely different argument (and it think that is what you are arguing).

Signal is not a protocol, it is a application. It uses open whisper (or some mutation of it) as its underlying protocol. That being said, you are still relying on trust provided by the signal servers that they properly authenticated your phone number. A phone number is a super weak way to verify identity. Lucky signal does provide a way to verify you are actually talking to who you are via the safety code process (in person or out of band). So the end result is Trust us first, then verify later. While most PGP applications require zero trust until verification by means of key exchange.

After all that there is nothing stopping anybody from making a application that works just as signal does but based of PGP, and being just as secure as Signal using PGP. The problem is people who understand this know that using PGP chained with a week service phone number base validation invalidates using the entire point -- so they don't. I personally think that is a mistake. As PGP is way better in the long run because it can be used for more than text chats, and video calls.

> tools that get people hurt.

People hurt them selves using tools improperly.

Both of those statements are false.

There are clear things wrong with the PGP protocol. PGP predates authenticated encryption (let alone modern AEAD ciphers) and the hacks PGP came up with to authenticate ciphertext resulted both in stripping attacks and, indirectly, in the Efail attack from last year. It was also Signal's linear packet based key format that resulted in the GnuPG/SKS attacks.

Signal is a protocol; in fact, it was "Signal Protocol" that won the Levchin prize. Signal also doesn't verify identities with phone numbers.

These are just basic, fundamental factual problems with your claims. We're not even getting close to serious comparisons between the two systems; we haven't even talked about forward secrecy, compromise repair, modern primitives, complexity, and UX.

> Signal also doesn't verify identities with phone numbers.

In practice, the only allowed implementation does.

It finds your contacts based on phone number, it allows them to use any keypair, and it allows that key to change at any time. It shows a light grey item in the chat when the key changes, just "your safety numbers have changed" and then you continue chatting like nothing happened.

Even if you were paranoid about checking for the light-grey changed safety number message, there's practically no way to avoid it. There's no built-in way to back-up your keypair and then load it onto another phone, so you can't avoid needing to have your friends accept new keys whenever you get a new phone, or factory-reset your phone.

Maybe you want to fork the open-source client and fix some of these glaring security deficiencies ... nope, they don't want your fork connecting to their central servers. Federation is for silly nerds, no thanks.

Further - recent GPG's crypto implementations are not currently compromised, it's disingenuous to conflate the issues with mail client plugins and keyservers and the old constructions used 15 years ago with recent RSA keypairs.

GPG signatures are used to verify authenticity of debian, ubuntu, and arch linux packages, and these systems do not use keyservers. I've used gpg for a scripted system just for coworkers at my office. (We exchange keys and validate fingerprints in person in the office.) It works. It is not vulnerable to any currently known attacks.

You can't do any of that with Signal! Maybe signal's algorithms are the bees knees and will last for decades but it's just not a useful tool. It allows peer keys to change at any time, and encourages or even requires it!

If anything, I'd expect you to be promoting Keybase, it is "modern" and also does a lot to solve the key distribution and continuity problem ("for real users" you might say), that Signal does not do.

It's very frustrating to see you appeal so much to authority and say "my cryptographer friends and I all just laugh at silly geeks who don't trust Apple and Facebook and OpenWhisperSystems" and really not offer anything that could replace GPG as a tool for us "silly geeks" to use for practical purposes. We could chat with each other and feel good that Moxie's modern crypto is being used and not care when keys change, but that doesn't accomplish anything technically useful for us.

> Both of those statements are false. Pop on over to wikipeida, you will how wrong you actually are.

>> "Signal uses standard cellular mobile numbers as identifiers" >> "The applications include mechanisms by which users can independently verify >> the identity of their messaging correspondents and the integrity of the data >> channel."

That is what I described, its trust us first, and maybe verify later if you think of it.

>> "Open Whisper Systems introduced the second version of their TextSecure Protocol >> (now Signal Protocol)"

Looks like it is Open Whisper, just V2 and renamed... Well maybe TextSecure.

> hacks PGP came up with to authenticate ciphertext resulted both in stripping attacks and, indirectly, in the Efail attack from last year.

A quick look at Efail shows clients were at fault and the fix was fix was patching clients. I can assure you my email client had no such issue. So again, you are blaming something on PGP that really just involved PGP. If Signals code has a bug in it too can leak encrypted messages after the client decrypts them.

> key format that resulted in the GnuPG/SKS attacks

Again you are back on keyservers, a method of offline verification to a 3rd party.

> Signal also doesn't verify identities with phone numbers.

Yes it does, unless you do the second step of verification, which is not done by default. Have you used signal before? When I installed it on my phone magically people I knew showed up base off -- what is that? A phone number.

And again Wikipedia - " Signal uses standard cellular mobile numbers as identifiers, "

> These are just basic, fundamental factual problems with your claims.

You keep conflating things with PGP that are not PGP, thus I have to refute insane statements that don't have to do with pgp, but things like email clients, or now how signal actually works. You thus far have just said I am wrong, but yet not described how any of this works. Yet I am here pointing to and describing in great detail how you are wrong. Simply saying I am wrong, and not demonstrating it does not make you right.

> We're not even getting close to serious comparisons between the two systems;

You are right, because you are talking about end to end encryption and I am talking about the importance of verifying who you are talking to. Signal fundamentally solves a different problem that PGP is attempting to solve -- and it does so giving up some very strong benefits that PGP brought to the table. Signal is amazing if you don't want onlookers to see your message, not so good if you want to authenticate the sender (unless you go through the extra steps, in which case it is the same cumbersome process as pgp keys.)

In any case, i don't have any more time to spend on this. If you chose to reply I will read it but I am done because think we are going to come to a agreement.

This is just a series of non-sequiturs.

imagine arguing PGP security with tptacek

Imagine feeling like someone's opinions are unassailable because they're knowledgeable about a subject.

As I've mentioned before, AEAD was added to the RFC bis and a number of implementations support it.

If you need ultimate privacy and true end to end encryption , PGP is your tool. You can use over channels you don't trust, e.g. you can easily send PGP messages over Signal or other messenger you can't verify. Only people to discourage use of PGP would be gov reps, as you can choke messenger company to give you a tap to messages, but if someone uses PGP over it, tough luck.

If someone solved the UI/UX problems with gnupg, and came up with a more elegant method of exchanging/validating keys (or even just an alternate keyserver infrastructure with better properties), wouldn't that solve the problem?

Edit: how about a response instead of a downnvote, anonymous detractor?

EDIT: guidelines

As a note, I think there are probably better crypto technologies these days, but none of them do what pgp aimed to do, but rather we have a bunch of smaller tools that do small parts that pgp did. I am not going to send you a singed file over singal, and I think it is silly to have to use a alternative means of sending the file that will either remove the ability for authenticity, or require me to do the authentication dance again with you.

PGP suffers from bad tooling, and further suffers from the relentless onslaught of people who want fancy electron or phone apps that can only do a small % of what pgp would allow.

Final note, I think something better than PGP could exist, but nobody has made it yet. In either case, validating keys will always be a hard problem and any attempt to automate it will result in false sense of security. While end to end encryption will keep on lookers from viewing your communications -- you just might find out one day you are talking directly to the people you were trying to hind your communication from.

First, the guidelines ask you not to talk about downvotes. You can find out more about that by reading the guidelines.

Secondly, Signal sends files just fine, and does so more securely than GPG. If you don't want to use Signal to do that, you can also use Magic Wormhole, which also works better and is more secure than PGP.

> Don't use PGP.

How else do you recommend to independently establish a verifiable identity?

Would you happen to know if you can send stuff using Signal to someone whose phone is offline? You do seem to be able to do it using Wire but I would rather avoid it as the device verification seems broken.

Sure. Messaging via Signal (or via any other modern mobile messaging app) is designed to be asynchronous and doesn't require all participants of a chat to be online at the same time.

Signal has perfect forward secrecy though. I am unsure how that could be achieved if phone 1 sends a message, the phone gets disconnected and then phone 2 connects to it.

For an explanation on how Signal achieves forward and future secrecy, see https://signal.org/blog/advanced-ratcheting/ (or https://signal.org/docs/specifications/doubleratchet/ for something more detailed).

You seem to be defending PK cryptography instead of OpenPGP.

Well, I always ignore the more grandiose claims - since there is currently no alternative for GPG, and installing Electron apps for Signal or Wire (which then use a single centralized server) really isn’t a viable GPG alternative

But even if you don’t agree with the argument that federation is dead and we truly need Electron apps (with eternally outdated Chrome instances) for secure communication, still you have to admit that PGP is arcane, the cryptography is not modern, and people by and large are ignoring the “web of trust” system. PGP needs a dramatic overhaul, at the end it won’t really be PGP.

(I am not sure if there isn’t a double ratchet system working in federated way. Jabber with OMEMO/OTRv3? Matrix? I don’t know)

Matrix uses double ratchet crypto and is federated, yes. Encryption is not on by default yet due to UX problems, though. It's supposed to be solved soon.

I wouldn't say the web of trust aspect is broken but non-scaling personally. Key servers and others are "compromises" in a way that can lead to being compromised.

If you don't have an effectively auditible trail of knowledge to be able to tell if someone attempted trickery then it doesn't serve the full purpose - but that doesn't scale well.

That's ok, pgp is also terrible to use on the command line so we can complain about that.


Isn't keybase.io trying to solve this?

They decided to bolt on sending cryptocurrency to people they haven't KYC/AML'd instead.

keybase.io also decided that PGP is terrible and made their own ASCII armor format (that is arguably much better than the horrible abomination that PGP likes to produce).

Basically unless you plug your GPG installation into keybase or do other GPG specific things, it's not using PGP/GPG at all and instead their own format.

No, it's a choice. It's "pretty good" privacy to exchange encrypted comms via Keybase vs. plaintext. And, yes, if it were existentially important than direct key exchange would be better.

> At least at some points we need proper transactional behaviour and Sqlite implements that by talking a temporary copy of the database - not an option for large keyrings.

I don’t understand how GPG maintainers think they can implement something better (function and performance-wise) than a proper database engine. Also I don’t think GPG will ever need to handle keyring lager than 140TB [1].

[1]: https://www.sqlite.org/whentouse.html

I’m pretty sure SQLite doesn’t implement transactions that way anyway. That’s a pretty bad misunderstanding of how it works. I suppose it’s easy to think you can do better than SQLite if you think SQLite is really bad.

SQLite never implemented transactions that way, neither in undo nor WAL mode.

Someone might have misunderstood how undo logging / rollback journals work. Only pages to be changed are recorded in the rollback journal, not the entire database.

Very nice article, I'll definitely subscribe!

> For example, it was never clear to me whether signing a key meant that I’d verified the person’s identity, or that I then trusted them to verify other people’s identities.

Signing means you verified identity. Trust to verify (also called ownertrust) is controlled by a different setting and you can trust someone to verify other keys fully or marginally (or not at all if you know someone is controlling given key but does not verify others well). See this excellent post for details: https://www.linux.com/learn/pgp-web-trust-core-concepts-behi...

I think he understands that in general. The problem is that, in practice, the "web of trust" depends on significant numbers of users trusting other users to verify still other users on their behalf, which is in practice something most people are (or should be) loath to do.

I think we need to rely on this at some point, though. If my friend Alice introduces her friend Bob to me, that's my only way of determining that when Alice is talking about Bob, it's this Bob and not a different Bob.

I actually don't think there is a problem with the concept of a web of trust per se. It's a fact of life. I think that the software doesn't help you use it appropriately. Even if Alice says that a person is Bob, I should not be fooled into thinking that it really is Bob, or that Bob is trustworthy. All it says is that when Alice talks about "Bob", she means this person who we're calling "Bob". If "Bob" then introduces me to "Cathy", we shouldn't be fooled into thinking that it really is Cathy. However, it's still very useful to know that Cathy is Bob's friend who is Alice's friend. If Alice tells me to talk to Bob's friend Cathy, I can be totally comfortable talking to the "Cathy" that Bob introduced me to.

Just to make a more concrete example, imagine that you have a problem with your software. You contact the company that supplies it and somehow determine that the person you are contacting is really operating on behalf of the company. They refer you to second line support. It would be incredibly useful to know that the second line support person you are talking to is, in fact, the second line support person you've been directed to and not a man in the middle. You don't care who that second line support person is. Maybe they aren't using their real name. Maybe they are an illegal immigrant. None of that matters to you. All you care is that they are the person you were directed to. And if they direct you to third line support, you care that the person you are talking to is the person you were directed to.

People get hung up on the wrong things with PGP IMHO. They check people's passports and include photos in their keys, etc, etc. I mean, great if you are the government trying to ascertain if a key really belongs to a citizen, but completely useless for most practical purposes. All you care about is that chain.

The kernel of the conceptual problem with this web-of-trust feature is in another Filippo post[1]: when I sign someone's else's key, it is difficult (in practice: impossible) to really know the provenance of that key. The signer could have gotten the key from a keyserver (in which case you now transitively trust the keyserver). Or they could have gotten it from a random email saying "this is my new key". You don't know; the basis for trust isn't there, or rather, to the extent it is, it's only there across strong, short paths in the graph of key signatures; it doesn't scale out to the whole "web".


I'm definitely not arguing against that. I think keyservers are one of the worst things to ever happen. PGP's implementation of the web of trust is hugely flawed. I'm saying the concept is still incredibly useful. I get frustrated when I see suggestions that we should abandon the notion signing other people's keys because users can't be trusted to do it properly.

I think the author of the article you link to is mostly right. Long term keys don't make much sense most of the time. A key that's signed by a million people is useless. I only care that it's singed by the people who are relevant in the context for which I'm using it. Relationships change too. If I've got a key from level 1 support to a level 2 support person, I can't trust 6 months later that the level 2 support person still works at the company. You need to have a context to describe the link in order to understand it. PGP (and by extension GPG) are absolutely horrible in that regard.

I find it ironic that the author says that the best way to reach them is by their Whisper number. This is what frustrates me. We exchange "horribly flawed implementation" for a central trust broker -- who may or may not be trust worthy.

This is a very useful way to think about a/the web of trust. Thank you; I am sure I will use it later.

I still think this is a problem of public key servers being a broken idea, rather than PGP itself.

It's 20 years since I've been to a key signing party, but there are still several small circles of trusts where I have very good ideas about the trustworthiness of each member and of the overall circle.

I still trust the crypto that PGP (and OpenPGP) uses. (With the caveat of no forward secrecy unless you try to handle that yourself).

I'm not entirely sure I've _ever_ trusted a key server provided public key, beyond the use case of trying it to open a conversation in which I can verify (to whatever level is needed) whether the person on the other end is the person I am trying to communicate with.e

If only distributed signatures included trust levels -- then you could at least attempt something like that. Though unfortunately trust levels are themselves incredibly coarse and subjectively determined (does "I trust fully" mean "I checked 6 forms of government ID" or "I know this person by their handle"?).

To be honest, I think Keybase has the only workable solution to this problem for modern online personalities -- tie it to directly to your other identities online such that you would need to break into many accounts in order to fake someone's identity. And individual users can decide for themselves what threshold of trust they have for someone.



Every two other week, someone writes that openGPG is broken. Guess what they want to say is that if you use PGP in certain ways, it's broken (keyservers, addons like enigmail and so on). But nobody has ever been able to demonstrate that it's broken if you use it correctly. I'll stick with openGPG.

Is that a fork of openPGP or some other product that is based on the same specs? I could not find anything meaningful for openGPG.

That's because it doesn't have open in its name, it's called GPG or GnuPG.

It's another product based on the same specs.


OpenPGP is not a product, it's a standard.

Maybe you're thinking of https://sequoia-pgp.org/ or https://neopg.io/ ?

To be clear: this is a subhed from Filippo's email newsletter (which you should subscribe to), relating a news item about the ridiculous SKS/GnuPG-key-handling fiasco from last week; it is not a comprehensive summary of all the ways in which OpenPGP is broken, despite the title.

OK, we've restored the full article title.

>it is not a comprehensive summary of all the ways in which OpenPGP is broken

Is there a comprehensive summary anywhere?

This article by the same author is perhaps not comprehensive, but a good place to start: https://blog.filippo.io/giving-up-on-long-term-pgp/

Except that the article is only about one particular reason the author finds PGP use uncomfortable. It doesn't deal with any "brokenness of PGP" at all.

Or at least a list of topics/keywords to search for to start learning some of the other ways?


Could you please not be snarky or post unsubstantive comments on HN?


Just wanted to say thanks for making the awesome cryptography newsletter! Really enjoyed reading this.

I've seen the link from this article before about alternatives to PGP and it bugs me for two reasons. One is the implication that everyone should write all software in Go. The other is that when you swap out one system for half a dozen, you now need to identify yourself half a dozen different ways. That seems confusing.

> I don’t believe in invasive tracking

And yet, I see 'utm_source=cryptography-dispatches' in the URLs!

It is tracking, but it is not invasive.

I've mostly been able to avoid PGP, but one workflow that I haven't been able to find a decent alternative for it Git commit signing.

Does anyone know good alternatives in this space?

Linus himself has expressed his opinion several times that signing every commit is useless. His posts here explain it a bit: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

Well yes, signing every commit is useless. He did not however, at any point during that exchange, express the idea that commit signing is a useless activity. And that is what I was referring to.

Currently Git seems to be very much integrated with GnuPG and the same goes for GitHub's UX sprinkles over the signing feature. That is what I'd like a decent alternative to.

I considered using OpenBSD's signify but it does not integrate as nicely as GnuPG signing so I'd basically be rolling my own mechanism (which is fine I guess, but feels subpar)

For the record git signing can also use X.509 certificates but from what I see it's still managed by GnuPG.

Signing every commit can be useless, but signing the releases seems to be important and useful, mainly if the developer releases compiled binaries.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact