Hacker News new | past | comments | ask | show | jobs | submit login

That is the single most common misconception around PGP, and it comes up every time:

(Open)PGP is first and foremost a flexible packet format (and other specs), and GnuPG is more of a CLI "library" to interface with it -- all of it. You can build something that hides metadata, you can have forward secrecy, and encryption always-on by default with PGP (and GnuPG). You can use it for whatever trust model you want, neither OpenPGP (the specs) nor GnuPG prescribe a certain model. It provides building blocks. It just happens that no good client exists and no more high level specs were written that use it, which is highly unfortunate. The client in this case here used to be "Enigmail" (a wrapper around GnuPG), and now is built-in since plugins are not allowed to be as powerful with the new browser architecture that Thunderbird piggybacks on and this was the only way to bring PGP to Thunderbird users. Also, there are some more modern libraries nowadays for standard use cases around PGP.

Signal was able to move faster since it did not exist, did not try to build things in an open and collaborative fashion, still refuses to work in any open way. Its founder Moxie even openly argues against standards [x]. I am not saying he does not have "a point", but in the long run this will lead to just more silos and ultimately technical stagnation, and for me goes against the ethos of "a public and open inter-net." (and the learnings behind it. 'Those who cannot remember the past are condemned to repeat it.')

That said, I do agree with your comment on a pure end-user level. It still makes me sad to always see this confused and not acknowledged better in places like HN, where people "should know". Technologists can defend and strive for the most promising long-term solution and "proper way to do it", and at the same time recommend "the best of the bad that is currently available". Even if it is confusing sometimes.

Just to give an example, there are plenty of high security use cases that require using smartcards. I'm very grateful that the OpenPGP standard and GnuPG exist that (can be made to) work in such cases. Signal does nothing in that space, rightfully so. But you are comparing different fruit to each other, which is kind of unfair.

[x] and still calls himself an "anarchist". You would think those know better...




I understand that PGP doesn't have to be used with email. That is why I haven't commented on PGP, I'm saying that I think encrypted email is a bad idea, regardless of whether you use PGP or something else. We're posting in a thread about Thunderbird, an e-mail client :)

I agree that one great weakness of Signal is its centralization, and that decentralization is a great strength of email.

For a decentralized encrypted communication channel, Matrix may become a good option now that it is encrypted by default, but I haven't studied carefully the quality of its encryption beyond that yet.

Regardless, I really do think a new protocol is required for secure communications and that email won't cut it. If Signal or Matrix can't do the job for some applications, we'll just have to try again. I cannot recommend email for secure communications, and in any situation where security matters, I have to prioritize people's safety. In terms of security, the best that is available in the realm of encrypted email is not and cannot be good enough.


For future reference, statements like this:

> I used to love [A], but I now think [B] is a bad idea.

will lead many people to think that you consider A and B to be essentially the same thing. In the specific case of PGP and encrypted email, this is a category error: you are implying (perhaps unintentionally) that PGP’s only use is for encrypted email.


Fair enough, I've updated my top comment with an attempt to clarify.


> GnuPG is more of a CLI "library" to interface with it

It abjectly fails at that. It's just awful to interface with.


Agreed. It has been long overdue that alternative OpenPGP implementations exist that try to address some of the peculiarities of GnuPG -- most of which are [still] there because its founder wants to preserve compatibility at all costs to support some of its long-term institutional users. And, yes, dealing with these peculiarities should not the responsibility of end users, but of further abstraction layers built on top of it (of which there are only a few, and all of them focused on the email use case).

The constant confusion between OpenPGP (the standard) and GnuPG (one implementation) has led many users to look elsewhere, which is unfortunate, but has also led many developers to look elsewhere, which is just sad.

Yes, trying to work within the existing standardization bodies can be very painful and disheartening, but the few people who try and survive in that space can use every good soul willing to assist.

The OpenPGP community has done hundred times more than Signal for the state of security on the Internet, and I'm sure it will continue to do so. Signal is great, and pushed the limits quite far (and still does), and I'm very grateful that it exists and use it every day.


The OpenPGP community would do more for security if they listened to serious cryptographers and began recommending better solutions.

See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html for more on that. And it isn't hard to find lots and lots of cryptographers agreeing with the thesis.


People in this industry use OpenPGP because it's flexible and amendable to almost any usecase you can think of. "Better solutions" are usually indeed better but are also so specialized for their purpose to the point that they can't be easily used for any other purpose.

OpenPGP is used to secure everything from simple messages and email to authenticating OS updates for most servers today.

Should they use something more specialized now that it exists? Sure, but that an argument for PGP not against it; PGP is useful in situations where no specialized solutions exist or are inadequate.

Until something comes along that can cover every situation where OpenPGP is useful, I can't see people stop using it (much to the dismay of the 5 vocal crptologists that keep arguing against it).


It's telling that the most common example of a widespread use of PGP (modern messaging applications exchange more messages in a day than OpenPGP has ever exchanged) is software update schemes, because software update cryptography is both a solved problem (just use signify) and doesn't have network effects; it's a "trust anchor" application.

At least with PGP email, you can make the argument that PGP sticks around because people don't want to recreate contact lists. But even that argument doesn't apply to update.


Backup, archivization, password managers, the list is long. Duplicity has many users: http://duplicity.nongnu.org Pass is also pretty popular on HN: https://www.passwordstore.org Both use GPG.


I use pass and I would switch in a heartbeat to a fork of it that used ssh keys or something similar instead of gpg. For something so amazingly simple and useful, its dependence on the klunky mess that is gpg key management is an anchor that weighs it down.


Key management is a burden in every cryptosystem. I'm using KeePass and can recommend it, it works well.


Would you know if it failed?


If it would "fail" and there would be no consequences so I could't tell if it failed or not - would it make a difference?


If the failure were discovered by you a year later, realizing that all you thought was protected was in an adversary's hands.

I'm suggesting that "seems fine so far" is not effective at evaluating solidity of cryptographical usage.


> software update cryptography is both a solved problem (just use signify)

Well, just use TUF [1] and in-toto [2] ;)

[1] https://theupdateframework.io/

[2] https://in-toto.io/


Note that TUF is great for things with multiple contributiors (think npm or pypa).

For the simple case of "a single publisher publishes update for a single product", TUF is an overkill. Something like signify or seccure will be way easier to set up and use.


signify is nice when key distribution, revocation, and rotation is handled for you... but how do you do that securely for many different publishers on a single repo?


OpenPGP is used to secure everything from simple messages and email to authenticating OS updates for most servers today.

And for MOST of the places that it is used, it gets screwed up in some way that makes it not as secure as the people using it thought that it was.

Stop and think carefully about that statement. And repeat it to every person you meet who thinks that they are solving their problems with OpenPGP.


What do you mean by PGP "not [being] as secure as the people using it thought that it was"? Can you mention something specific?


Here is something specific.

Due to the complexity of the PGP system, there are a plethora of downgrade attacks. Where something that was supposed to be at one level of security can be tricked into doing something much less secure. See https://twitter.com/xmppwocky/status/1291144278953955328, https://mailarchive.ietf.org/arch/msg/openpgp/JLn7sL6TqikUf-..., and https://www.eff.org/deeplinks/2018/05/pgp-and-efail-frequent... for three different examples of such attacks against PGP in recent years.


The first one appears to be some sort of joke.

The second one is just yet another person discovering that the MDC check can be stripped off a message.

The third one seems to be just EFAIL which is not a downgrade or any attack really against PGP.


What industry do you mean by "this industry"? Just... computing?

I didn't know OpenPGP was used to authenticate OS updates for most servers today. Can you give me a place to find out more about that; are you talking about a specific OS?


Packet managers on pretty much every Linux distribution use GPG for verifying packages.


It's used to digitally sign software, not encrypting.


What is a good non-email use case for the PGP format?


Any usecase forwhich no specialized solution already exists. Source code signatures and Apt/RPM packages are good examples of this.


What does OpenPGP bring there? At least GnuPG has the benefit of being a tool that's present on many system and which is capable of verifying signatures.

If you're not using GnuPG, you can pick any format you want! What does OpenPGP add? Everything I can think of is a negative.


OpenPGP is the standard, gnupg is a implementation.


Right, so why talk about the standard when you mean, specifically, GnuPG?

If you want an explanation of why GnuPG is dangerous for anything besides email, let me know. But parent post was very specifically NOT about GnuPG- it was about OpenPGP.


because gnupg is not the only implementation.


Yes, that's what I said, and why I was asking!

What does the OpenPGP format bring to the table, BESIDES HAVING A COMMONLY AVAILABLE IMPLEMENTATION IN GNUPG?


It's the generic term.


It is used routinely on the dark nets by pasting encrypted messages into web forms.


Who said that it's for a user to interface with directly? mutt interfaces with it perfectly fine, and mutt's PGP UX is also fine.


This is a weird argument. By your logic, there's practically no cryptosystem PGP can't be; after all, it's an omnibus standard to which people routinely add extensions for new algorithms. Want a double ratchet? An elliptic curve triple handshake? The "building blocks" are all there, all you have to do is use PGP's "flexible packet format" to carry them.


This is an interesting interpretation of what he stated.

What I got from it is that the strength of PGP is in its flexibility and that it gains that flexibility from being standardized and open.

Of course you can extend PGP (or any protocol really) to include cryptographic handshakes, but that's besides the point.


(Open)PGP is first and foremost a flexible packet format

That makes an even better case that PGP is not much of a modern secure system generally, rather than it just being bad for secure email.


Because packet formats are bad?

I don't understand what you're trying to say here.


Flexibility in cryptography is often very bad and opens doors to downgrade attacks or things like JWT’s alg:none issues.

https://www.imperialviolet.org/2016/05/16/agility.html

“Have one joint, and keep it well oiled.”


The linked article is all about protecting data in flight like in the TLS case. PGP is all about protecting data at rest. The two applications are fundamentally different.


I think you're misunderstanding the general complaint or maybe not the complaint but how general, rather than specific it is.

At the top of the thread someone says 'PGP has all this ancient cruft and also isn't good for email/email is maybe unsecurable anyway'. The PGP-enthusiast response to that is 'No problem! You see, PGP is so flexible, you can build anything out of it, including maybe an actually-secure system of some sort'.

This is a fundamentally inadequate response and we've realized it's inadequate and don't really design secure systems like that anymore. In fact, this class of concern has permeated almost all aspects of contemporary software systems design rather than being something narrowly limited to 'crypto algo agility is bad'. Here's an example/illustrative timeline that doesn't have anything to do with 'data at rest'.

1998 Netscape: Behold our cross-platform, cross-language super-toolkit for building super-extensible Enterprise Groupware apps. Also one of them is a web browser!

2015 Mozilla: [belated forehead slap] This is a terrible way to architect a web browser that has any hope of offering end-user security.


How do you do a downgrade attack on, say, an encrypted backup?


I guess I don't understand how that's a response to anything I've written in this thread.

Edit: I'll expand the quote from the original thing a bit if it helps:

(Open)PGP is first and foremost a flexible packet format (and other specs), and GnuPG is more of a CLI "library" to interface with it -- all of it. You can build something that hides metadata, you can have forward secrecy, and encryption always-on by default with PGP (and GnuPG). You can use it for whatever trust model you want, neither OpenPGP (the specs) nor GnuPG prescribe a certain model. It provides building blocks.

This is a huge 'nope'. It's, by this point, an uncontroversial, well-understood nope. A known-nope, if you will! The only people who don't seem to think so are PGP people and that, in itself, is rather telling.


You can't just "Nope" this issue. You need to come up with some sort of rational argument. The PGP people have been dealing with the data at rest issue since forever. It is a bit presumptuous to just write off all that acquired wisdom without reason.


I have come up with a rational argument, you just refuse to address it at all. Your argument boils down to 'the PGP people are smarter than everyone else' which I think isn't really even a rational argument.


There is no reason to appeal to authority here when a simple koan can provide enlightenment. I will repeat it one more time:

How do you do a downgrade attack on, say, an encrypted backup?


No. We've got a threadful of arguments here in which you simply refuse to engage. You don't get to superciliously demand Socratic satisfaction, wave around your list of logical fallacies and mumble oracularly about koans and enlightenment. You have to make an argument otherwise what you're doing is simply rude preening. It's fine if you have nothing to say. You don't get to (at least, publicly) pretend you've actually said anything and that it's everyone else who has to meet your precise terms of discussion. Sorry.


This all started when you said something to the effect that "packet oriented formats" were bad. When asked to clarify you switched the topic to how flexibility in cryptography was bad because it could lead to downgrade attacks. I pointed out that downgrade attacks were not really possible in a data at rest application and that the article you linked to was about data in flight applications.

That's it. That's the actual arguments to this point. Then you just said nope.

You are not claiming that logic and facts are irrelevant here, are you?


you switched the topic to how flexibility in cryptography

I never said that. You're replying to someone else.


Because flexibility brings bugs, and bugs in cryptography means breach of security.


Because a flexible 'format' or 'model' or whatever with which you can construct insecure systems or (hypothetically) secure systems, is not really useful, it ends up being inherently insecure.


> Moxie even openly argues against standards [x] and still calls himself an "anarchist".

On the face of it, that sounds like exactly the position an anarchist would take...


If you believe in abolishing hierarchy and institutions where they have no legitimacy, _all_ you are left with is communication, community, and open standardization as practiced in anarchist bodies such as the IETF.


> anarchist bodies such as the IETF

That's an incredibly... unconventional read on the IETF.


Not really. I know very little about both anarchy and the IETF, but voluntary organisation (as in opposed to wage slavery) and a democratic governing of the group is very much in line with many anarchistic schools.

Edit: language fixes. English is not my language of choice for discussing things like this...


Anarchists would be philosophically opposed to top-down, mandated standards, not standards in general.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: