GnuPG used to ask for your support to help protect online privacy | Hacker News Reader

GnuPG used to ask for your support to help protect online privacy

gnupg.org

241 pointselvis70144 comments

> Fortunately, and this is still not common with free software, we have now established a way of financing the development while keeping all our software free and freely available for everyone.

> Our model is similar to the way RedHat manages RHEL and Fedora:

I looked around the website for a bit and didn't find a blog post or anything indicating what they've replaced the donation revenue stream with. Have they been employed? Are they doing consulting?

I'm confused as well, it's not clear from that post what the new structure is, or how sustainable, or if there are back-up plans. It just says, that there is a new structure essentially.

I'd appreciate it if someone helped me understand, or get more context.

https://gnupg.com/ via https://gnupg.org/service.html

This is good news. Just using gpg isn’t good enough. Knowing how to do it properly is most important.

I hope more companies throw money at these guys.

Maybe they can even document some of their learnings doing deployments in a blog sort of system to give back to the community.

I support some form of FOSS guilds, in moderation; that is, there is knowledge that is documented but not necessarily full, complete tutorial and discussion casually provided. Obviously many companies do this explicitly themselves now with "community documentation" or "public core" and then many other media assets that are not shared widely. This is natural and obvious, with caveats that fairness is inherently difficult, and you can't please everyone. Security practice is certainly the sort of world where that guild behavior can go badly, and many will complain, sometimes falsely. So it goes in the real world.

Corporate and government users have been free-riding FOSS to ridiculous levels, in my view, and I welcome some way that actual practitioners can self-organize and at least survive. As opposed to say, divorce, substance abuse and what amounts to financial suicide, which I have seen happen to real people with good intentions and bright minds.

“ GnuPG.com, Düsseldorf, Germany Offers commercial grade support, customized development, porting to new platforms, help with integrating GnuPG into customer projects, code audits, and more. GnuPG.com is a brand of g10code GmbH; owned and run by GnuPG´s and Gpg4win´s principal authors.”

There is certainly a need for consultants to help organizations do PGP-style security well. And it doesn't look like they're transforming GnuPG into an open core product model with critical components only available commercially.

So, this seems good? It doesn't look like they've been bought by anybody (e.g. a VC) who's going to require the sort of rate of return that can only be attempted (and probably not achieved) by doing things incompatible with GnuPG's role in the open source ecosystem. Not every company has to be huge — GnuPG can have outsized positive impact on the world while remaining small and sustainable.

"GnuPG VS-Desktop" has been approved by the BSI for encrypting secret files/messages in the German government (VS=Verschlusssache) so I'm guessing that's where most of the money is coming from.

How is that a government contract at all? Sounds like a bullshit handout if anything, and I’ve seen pretty dumb government contracts before.

Well whatever works!

The german government appear to have fairly widely realised that the available options are support open source, or provide free intel to the US.

So instead of using the open source tool themselves they find a reason to capitalize the stewards, hm alright

Don't vote for them if you don't like their decisions.

I’m not a voter in Germany and I didnt say I didnt like it

(at the part you replied to)

The BSI is great though, they know what they are doing. Also the German government supports Open Source projects financially [1] and one of the states is planning to go full open source in its administration, so you'd think they are interested in keeping these projects alive

[1] https://prototypefund.de/en/

https://gpgtools.org/support-plan maybe?

Is this one of those things where you could technically pay for Winrar, but perhaps should never admit to doing so?

Here is the blog post with the details of how they started making enough money in the recent years:

https://gnupg.org/blog/20220102-a-new-future-for-gnupg.html

GPG is severely hampered by two issues:

1. a lack of good support via an API/libraries (the standard way to communicate with it seemed to be shelling out to the binary and trying to parse its output for a long time)

2. terrible UX, especially around the trust model - web of trust is great in theory and for geeks but doesn't work well in practice, and the terms used to explain it invited dangerous misinterpretations (to mark a key as trusted in the sense of "I verified that this fingerprint belongs to that person", you're expected to sign it, NOT mark it as "trusted" - the latter actually causes all keys signed by that key to be trusted, making it a "CA").

These may be addressed by now, but I think this is too little too late.

I dont think those are addressed now. I needed gpg for the first time recently. After fiddling with documentation and weird terms, approaches etc I decided it is not worth whatever it does. My time would be better spent if I learned how to knit or something.

Very confusing post. It doesn’t explain how they are now making money--which is probably relevant for some folks to trust them to protect online privacy.

They used to ask for donations. They still do, but they used to too. /s

rest in peace, Mitch

I think they did explain it, although I had to read it a few times to find it. If I understand correctly, they're charging for "the actual binary of the MSI installer for Windows and client specific configuration files." It sounds like they're doing so under the name "GnuPG VS-Desktop." I think it's related to selling services through https://gnupg.com/gnupg-desktop.de.html, but I'm not entirely sure.

https://gnupg.org/service.html

> Those with SEPA donations, please cancel them and redirect your funds to other projects which are more in need of financial support. The donations done via Stripe or PayPal have already been canceled.

This is a nice turnaround from 2015:

> Werner Koch wrote the software, known as Gnu Privacy Guard, in 1997, and since then has been almost single-handedly keeping it alive with patches and updates from his home in Erkrath, Germany. Now 53, he is running out of money and patience with being underfunded.

https://www.propublica.org/article/the-worlds-email-encrypti...

https://news.ycombinator.com/item?id=9003791

Recall that this was in the wake of Heartbleed, a vulnerability that exposed our dependence on OpenSSL, another critical, and chronically underfunded project.

The project got a nice boost after that article, leading to this Ars Technica story about the windfall:

> Given the ramshackle state of massive GnuPG code base, it's not clear what's the best path forward.

http://arstechnica.com/security/2015/02/once-starving-gnupg-...

https://news.ycombinator.com/item?id=9011138

Nonetheless, a fundraising campaign followed just two years later. It turns out that $150K isn't actually that much of a windfall.

Comparing the list of CVEs for major cryptographic software OpenSSL, OpenVPN, OpenSSH and GnuPG implementation of OpenPGP, GnuPG has stood up pretty well for three decades:

https://www.cvedetails.com/vendor/4711/Gnupg.html

The main shortcoming of OpenPGP standard is lack of modern authentication. It has MDC, which works in most cases, but isn’t best practice nowadays. There is an update to RFC4880 in progress, RFC4880bis draft, which is presumably considered by sequoia-gpg. The file format is also apparently disliked by some people, but end users care about results. If RFC4880bis is standardized, the gap between OpenPGP and alternatives is closed. Then, using a heavily audited standard and code is preferred.

I read GnuPG is used by organizations requiring high security, eg, intelligence agencies, NSA, state-level actors (presumably shadow brokers etc), banks etc.

It’s still good to have competing options. But let’s focus on facts.

> GnuPG has stood up pretty well for three decades

Make sure you also look for libgcrypt, which had a lot of cryptographic weaknesses in the 2010s.

https://www.cvedetails.com/vulnerability-list/vendor_id-4711...

This does not look like an especially reassuring track record! People should keep in mind that GnuPG is a legacy C codebase. Nobody would implement a tool like GnuPG in 2021 the way GnuPG is implemented; we accept its implementation because of path dependency, not because it's especially sound.

I don't think your supposition that GnuPG is beloved of "NSA and state-level actors" really qualifies as "facts". The industry standard "secure email" system for banks is simply a TLS web interface that you post your emails to; banks don't use PGP for secure communications. I haven't, of course, worked for all the banks, so if you've got a counterexample, please provide those facts for us to evaluate.

Obviously, the documentation of a proposed design for AEAD support in an RFC doesn't close the gap --- users care about results, as you say, and so what matters, to the exclusion of all else --- is what the installed base of GnuPG clients supports. Which is why Sequoia's years of support of (I think?) EAX mode AEAD encryption hasn't moved the needle for the moribund PGP ecosystem.

It’s relatively common for banks to exchange files with financial partners that have been encrypted with pgp.

Like, I know intellectually that this must happen, but my experience (which tilts much more to investment banks, to be fair) is that an FTP server with plaintext files is much more common.

I can confirm that banks do this. They do ftp as well but to exchange credentials they’ll use PGP. The hardest part is identity verification which is often done with a phone call.

It’s hard to meaningfully define and measure software security. One needs to also prescribe a threat model, provide other information, etc. This could take pages.

If you measure software security track record by the number of known CVEs per unit time per unit task per LOC, the track record of GnuPG/OpenPGP is about that of OpenSSH/SSH and OpenVPN; see the site I linked. I think most people would agree that OpenSSH is secure (although SSH is a similarly dated protocol).

The fact that a security product is used by organizations dealing with highly sensitive information in fact correlates with the quality of that product. The security researchers in these organizations review, vet and recommend that software, compared to alternatives.

GnuPG dutifully implements OpenPGP. OpenPGP has shortcomings I noted, but their impact on experimental results has been low; see the list of registered vulnerabilities.

There is a lot of critical software and applications written in memory unsafe C (Wireguard, Linux network stack, LUKS, popular password managers, etc). They are well regarded, despite being written in C.

The use of GnuPG by important organizations is stated in GnuPG’s website. The examples I provided are well known and may be found using a search engine.

Correct me if I am wrong about what I stated.

SSH is in fact not "similarly dated" to PGP! SSH roughly tracks the maturity of TLS (I'd say SSH is generally a step behind TLS, but not several steps); neither is completely mired in the 1990s. The same isn't true of PGP, which is. That's to be expected: GPG is a global ecosystem of direct, interoperating peers, where both TLS and SSH can upgrade incrementally in islands of new implementations, which gradually expand and agglomerate until the worst of the O.G. designs can be disabled.

By way of example: if you build a new fleet of machines, it's very likely that your SSH sessions will use 25519 curves and a Chapoly AEAD.

OpenPGP is, for this reason, pretty much irrelevant. You can ratify any bit of modern cryptography you like in OpenPGP standards, but because everyone in the PGP ecosystem expects to be able to communicate with everybody else, you'll only be able to use the lowest common denominator of whatever widely-installed old versions of GnuPG support.

You could, of course, refuse to interoperate with people speaking CAST5-CFB or whatever, and form a clique of Sequioa PGP users using EAX and, I don't know, P-curve ECDSA? But at that point, you're only going to be able to communicate with a tiny subset of PGP (itself a tiny subset of all secure messaging users). Why bother with PGP at all at that point?

> Why bother with PGP at all at that point?

Because if sequoia is good enough from a security standpoint with standards and implementation and ux experience, people and organizations will switch from gpg to sequoia, for example perhaps at debian.

and if organizations/projects like debian switch, developers will switch, and developers are multipliers and users will switch at one point as well.

Debian is planning on a custom replacement for OpenPGP along the lines of minisign:

https://wiki.debian.org/Teams/Apt/Spec/AptSign

Since OpenPGP is normally used in offline and stateless applications like encrypted email and encrypted files there is no need for some sort of session oriented authentication. The content itself is signed and thus authenticated. So the MDC is not normally needed either, it is just an integrity check for the edge case of unauthenticated encryption. The only time the alleged deficiencies of the MDC come into play is when doing symmetrical encryption.

This article covers this in more detail:

* https://articles.59.ca/doku.php?id=pgpfan:authenticated

So if OpenPGP never gets upgraded authenticated encryption no one will care much.

This is good; donating to GnuPG was not an especially effective way of protecting at-risk users, and it's better that the project be supported by the niche userbase (apparently: the German government) that actually uses PGP in 2021, rather than trying to make a social cause out of a (pretty controversial) file format.

I think there are multiple reasons it's good. It's good for security as you've articulated.

It's also good as an example of sustainable open source development via the consulting model. We've seen a lot of hand-wringing about FOSS funding lately. It may not be as flashy or high-profile as VC-funded open core projects with all their ubiquitous marketing, beautiful websites, and submarine PR. But it's a way to make a living by exchanging useful value in exchange for moderate fees, rather than asking for charity or signing up for an unsustainable investment deal.

I agree. That seems like the real story here, and it's good that the top of this thread is still about the funding mechanics at play here and not another endless relitigation of the (contested) value of PGP itself.

(Not that I've shied away from that downthread.)

I've always found it annoying that there isn't a properly supported python package for gnupg. There were like two or three forks that were maintained properly but each one had its "time". It's very confusing for people to begin with using PGP since you have to understand which one to use and the history and why they all exists. A lot of fuss if you ask me.

Most of the Python packages for GPG just shell out to gnupg, which is not really the greatest API.

We can use stronger terms here --- whatever else you think of PGP, the shell-out stdio "api" for PGP is dangerous (GnuPG will release unauthenticated ciphertext to "callers" of that API, with a warning you need to catch). This API was responsible for the Efail bugs --- which were horrible --- a few years ago. Don't ever do this.

Agreed, but the problem here isn't provided by the caller, but it's by the python package that claims it's an api to GnuPG.

How is that any more dangerous than a "real" library doing the same? Your code would still have to check whether the message passed the integrity check or not, just like it has to look for the warning on stderr. I can't imagine why doing a stream search for i.e. "WARNING: Verification failed!" is any less secure than checking result.verificationPassed (assuming the CLI messages won't change, which they won't since they're basically an API).

Real libraries wouldn't do the same thing.

You could just as easily say a "real" command line interface wouldn't do the same thing.

Of course, it might make more sense for a library, "real" or not, to default to raising an exception with no output, not just a warning - especially for a security-critical application. But it's not like we've never seen unsafe defaults in a library before, even a crypto one.

Then again, it does make sense from a UX standpoint: I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.

This is really not a CLI vs DLL issue - it's a default settings issue. And in this specific case, the unsafe option actually follows the standard more closely - it does not, after all, mandate integrity checking. Mybe it should, but that's a different conversation.

(Disclaimer: I'm not very knowledgeable with GPG, I assume that the warning means that the message hasn't been properly signed.)

> I'd rather see "message could not be verified", followed by the decrypted content anyways, rather than not get any output. I know not to trust it, so knowing what it says is useful in terms of threat identification.

You would know not to trust it, but it would be very easy for a novice user without an understanding of the implications to assume that it's just a minor error ("tech sometimes throws errors, but it works anyway, so why worry?"). But it damn sure is not!

My suggestion would be to print an elaborate and strong warning about the implications and provide an option to look at the message if you really know that it should not be trusted in the slightest.

This is how browsers handle TLS certificate issues and I'd call it a lot safer than showing the website anyway and displaying a small warning with some technical jargon.

That's the exact problem. They claim to provide an API but at the end of the day under the hood, thats what's being done. It really annoys me.

There's a package called PGPy. It's a python implementation of PGP. BSD-3-Clause licensed. https://github.com/SecurityInnovation/PGPy When testing it out GnuPG compatibility, I just had to add the --rfc4880 when encrypting with GnuPG. Then PGPy could decrypt it using the private key generated by GnuPG. PGPy supports key generation and encryption too.

Isn't it weird that some companies are willing to pay for just the brand? Or - is it perceived as a form of corporate sponsorship?

> Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses.

They’re paying for a Windows installer. Building Windows code from source is not something most Windows users are capable of.

But can't you just build an MSI installer from sources, then distribute that to users? Like you can build .deb/.rpm or flatpak packages on Linux?

You can, but then you won't have any support and any integration stuff the commercial one might

Without the government certification, that's worthless if you need a certified solution. Hence, those companies will pay.

well then, redirect your funds to sequoia-pgp.org then. they make a good alternative, which is more secure than gpg. several former gnupg developers work on that as werner did not want to work on citrical issues back then.

Is PGP a zombie technology that won’t ever die because there are organizations that have nailed their identity to it?

(For everything you think you should use PGP for please use Age - https://github.com/FiloSottile/age)

Is calling the main player in a space a zombie technology a zombie promotional strategy for unknown upstarts? Seems like such an old pattern.

Calling age an unknown upstart is a weird take.

age is hardly a complete replacement for GPG

A "complete replacement" for GPG would be a dumb idea to begin with.

You want a specific tool for each of these use-cases. Choose one from the list for each use case.

1. Private messaging: Signal, WhatsApp, Cwtch

2. File encryption: age

3. Encrypted backups: age + a Reed-Solomon encoder for catching flipped bits

4. Digital signatures: minisign, signify, OpenSSH signatures

The problem with GPG (and with PGP in general) is it tried to do too many things. Complexity is the enemy of security.

>Encrypted backups: age + a Reed-Solomon encoder for catching flipped bits

I fear that I might of caused this idea. I have as a result added the following footnote to the article that I suspect is the cause[1]:

>Please note that the single flipped bit here is not a realistic example and that in practice damage tends to encompass one or more media blocks. Such blocks tend to be multiples of 512 bytes.

I am afraid that someone might actually implement this...

[1] https://articles.59.ca/doku.php?id=pgpfan:agevspgp

I don't read your wiki, so no, you were not the cause of it.

This list item was prompted by a private discussion with friends.

> 1. Private messaging: Signal, WhatsApp, Cwtch

WhatsApp’s record over the last decade does not inspire confidence, and the issues raised this year alone are quite serious:

https://wikipedia.org/wiki/Reception_and_criticism_of_WhatsA...

It still uses better encryption than Telegram, Threema, and several other products that market themselves as "private messaging" apps.

So don't use WhatsApp. That's a reasonable decision to make! I don't ever opt into it or recommend it to people (though I'd happily use it in preference to PGP email, which is doubtlessly the most risky secure messaging implementation on the Internet, arguably even more dangerous than simply using ordinary plaintext email with Google Mail).

Thank you! I was unfamiliar with both age and Cwtch. From what I can tell, Cwtch is also a linear messaging system. Are you aware of any software offering secure non-linear (hopefully threaded) messaging, i.e. a secure e-mail replacement? It does not have to be MIME, SMTP, IMAP based like PGP, but preferably support for similar branching conversations and archiving and hopefully with support for multiple users. I love Signal but I find that finding old messages, or groups with more than a few people and branching conversations is a lot less pleasant than e-mail. And thus Signal is not currently a replacement for e-mail for me but a great addition.

It didn't try to do what you put on that list. It didn't do messaging; messaging programs used it. It didn't do backups; backup programs used it.

It's just a foundation-sort of program that does encryption and signing of arbitrary data, using one format for keys, and allowing working with those keys whether they're in the same computer or in a smartcard/hsm. That simplifies key management, since it allows you to have one Yubikey with your PGP key on it and do basically anything crypto related.

But what I believe someguydave was referring to was stuff like smartcard/Yubikey support, not different uses of encryption and signing.

> But what I believe someguydave was referring to was stuff like smartcard/Yubikey support, not different uses of encryption and signing.

https://twitter.com/FiloSottile/status/1474941666545086465 ¯\_(ツ)_/¯

age can't sign, though. It's not as useful. You can't use it for authentication, for instance. You need a separate program with a separate key and its own separate yubikey support.

This is a good thing. Separate tool for separate use cases.

Bug jedisct1 if you want YubiKey support for minisign.

I'm fine with PGP, thanks.

Enjoy your vulnerabilities

I was more thinking of the extensive support GPG has in many email clients on many platforms for supporting encryption and signing use cases, as well as key management.

Eh, it's pretty new, and new cryptosystems are often more likely to have vulnerabilities. It's still safer than PGP, but that's not a high bar. Hopefully over the coming years it will become more widely used and scrutinized with few vulnerabilities reported, in which case it will then be more clearly safe to rely on.

Never heard of Age here. I looked, seems like it is brand new?

It's been around since 2019, and has been discussed heavily on Hacker News.

You're trying to tell us that software from 2019 isn't new? The majority of the software that I use on a daily basis is minimum a decade old, and I don't think I'm alone.

It isn't brand new, no.

Yeah, and it is supposedly a software related to cryptography. Has it been audited at least? They are promoting it so much, but GnuPG has been around for a while now and loads of people have used it. What about Age? I feel more comfortable with GnuPG.

What is your bar for "audited"?

I've reviewed both the design and implementation for age in the past and only found nitpicky things to improve (mostly related to HKDF).

I can take a fresh look and make a pretty PDF on paragonie.com if you care so much.

I am sure audits could help Age either way. :) I am just saying that it is still fresh as opposed to GnuPG. This is what people typically call "battle-tested", when the software has been used by a zillion of people for some time. Of course I cannot speak about Age much, this is the first time I heard about it.

GnuPG had been battle tested for almost two decades before Efail was discovered and disclosed.

Yeah, but does this help Age?

Only to the extent that it shows you can't simply compare the vintage of two systems and declare the older one safer by dint of battle-testing.

I am not saying it is safer because it is older, but it sure has been under more scrutiny than Age. That said, Age might be safer regardless.

Can you describe the upside of this “more scrutiny”, since per the above it doesn’t seem to have made the codebase safer?

So, it's brand new. Got it.

Hell, I have shirts older than the language it's written in.

In 20 years, I might not even be able to find a working compiler to build it, after the shiny-object crowd moves on to something else.

You know what I'll still be able to decrypt? An ASCII-armored, GPG encrypted, TAR archive.

Personally, I am not interested in the latest evolutionary improvements on file formats. Evolution produces a lot of interesting things; most of them are dead ends. What I want is the cockroach of file formats. The coelacanth.

> So, it's brand new. Got it.

No. Brand new means completely new. Something that's going on 3 years old isn't brand new anymore.

A more appropriately term is relatively new. Civilization is relatively new compared to the age of the universe. Age is relatively new compared to modern computers.

But neither civilization nor age are brand new.

You will be able to decrypt a file produced by age. All the cryptography there is standard, you'll have a compatible library in whatever language you'll use in 20 years, if you think the first party Go and Rust implementations won't survive.

Using common libraries, I can create a python program to decrypt a file produced by age in a few hours, I think.

Serious question: how read into work on cryptography engineering and secure messaging do you feel you are? I'm trying to get a gauge of what it means to be "brand new" for you. What cipher constructions are OK? The CAESAR finalists? The AEADs Rogaway surveys in his papers? The ones GnuPG supports?

It seems weird to me to gauge someone’s understanding of “brand new” for cryptography software by measuring against primitives and constructions. To me at least, those are not the same thing. Even if a piece of software contains cryptography I will still also evaluate its age as a piece of software simply as a proxy for maturity and stability of the feature set.

Is this intended as an answer for my question? Because it doesn't help me gauge what the parent commenter sees as "brand new".

No it was a comment trying to indicate that I found your question odd, and ask why you think your question is useful? Do you believe there is a single notion of brand new that can be applied across all categories? Is the age for brand new milk the same as for software or for scientific results or items of clothing? Or do you believe that for the categories of software and cryptographic theory the notion of brand new is equivalent?

Frankly in my reading of your question you come across as very arrogant, where you use the guise of a “serious question” to show off your knowledge cryptography.

Thanks for sharing, but this isn't responsive to anything I'm asking or saying.

Thanks, I am sorry for taking your time.

I also agree with adament. It may not be responsive to your question but your question doesn't read in good faith and many of your other comments in this thread read as pitiless war against an opponent you've decided is your enemy.

There have been many articles written that push back against the narrative a small cohort of security people push that GnuPG and OpenPGP by extension should be avoided at all costs. Personally, I find it has stood the test of time admirably and that its "multi-tool" functionality unlocks features I use almost every day like a web of trust in Keybase and using it as an ssh agent. I actually don't want another tiny tool in age. With Sequoia the future of PGP looks bright.

I also have never heard of Age. Then again, I don’t actively keep up-to-date with the world of cryptography (other than from a PKI/X.509/TLS perspective) . As a system administrator, I only use GnuPG to check the signatures of software packages and to exchange passwords with other sysadmins.

This thread has been both interesting and educational.

PGP (and its de facto reference implementation in GnuPG) is not the main player in this space, unless you define the space down to a point so small and idiosyncratic that it doesn't really have meaning in an broad discussion.

It's both. GnuPG has very poor UX and it's also so old and so well-known that it kills a lot of the "unknown upstarts". I think on balance GnuPG reduces the security of network communications and the appeal of a web of trust PKI because it's presented as "the main player", people try to use it, realize that the UX is garbage, and become disillusioned in the technology behind it.

Has it been independently audited at all? I looked around and didn't find anything about it.

It's probably maybe fine, and of course code can change at any time, but with software focused on security, it would seem more necessary than, say, an audio player (excluding improbable situations).

Either way, It's nice to see a GPG alt written in Go.

There's also a first-class Rust implementation.

That would be Sequoia-PGP: https://sequoia-pgp.org/

No, Thomas was talking about rage. https://github.com/str4d/rage

Thanks for the correction. I hadn’t heard of that project.

Too late to edit my comment: I had misinterpreted “a GPG alt” as meaning a GnuPG alternative implementation of OpenPGP. Only after reading the parent and other ancestral comments did I realise that Age was the project being discussed and that it’s an alternative to OpenPGP – not just GnuPG.

The only thing PGP did correctly, and very well, is the concept of persistent identity. Keybase recognized this and uses PGP as the toehold, then from there, created a secure auditable chain of NACL keys. The PGP 'web of trust' and non-repudiability nature of PGP messages each failed for good reason.

Consider, for the age and minisign/signify use-case: https://gossamer.tools

I haven't heard of this before. How does it compare to Sigstore?

(Also, the use case here is clearly much, much narrower than for age and minisign. Which is good, assuming the problem it solves is the problem you have, but should still be noted.)

Whoa, sigstore maintainer here. I've never seen or heard of Gossamer before. It seems very similar in design!

Gossamer is a 2017 design of an idea that was first published in 2015. However, it was exclusively focused on the PHP community from its inception, so it's unsurprising that nobody's heard of it.

What ecosystems are out there where I can flick a switch and say 1. "automatically install signed releases" or 2. "automatically install releases signed by multiple identities"?

Are any of the big language-specific ecosystems capable of that? (npm, crates.io, composer, PyPI, CPAN, Maven, rubygems, etc.)

Nothing really yet. Containers got relatively close with Notary V1, I'm focused on fixing that here in sigstore right now. I think Python, Ruby, and NPM would be great targets to go after next!

It's not quite flick a switch, but with maven you can specify which keys you trust to sign which of your dependencies (anything published to maven central is required to be signed). E.g. here's one of my libraries: https://github.com/m50d/tierney/blob/master/free/keys.proper...

Is there a straightforward way to use attestations to gate automatic updates?

For example, it would be nice to delay automatic updates of WordPress plugins and themes until after there is more than just the uploader's identity as a single point of failure guaranteeing that the update is genuine.

(Obviously the perfect way to do things given enough developer resources is to review all code yourself before installing manually, but it would be nice to improve situations where those resources are not available.)

Yes: https://github.com/paragonie/libgossamer/blob/master/docs/tu...

The intention was to allow security vendors to offer code reviews of open source dependencies, and you can choose which you trust. This mechanizes Linus's Law and ensures there's an audit trail with "many eyeballs".

This seems like critical prerequisite infrastructure, which is fantastic — although not yet what I was asking for. As far as I can tell there is not yet a way for individual WordPress installations to actually benefit. However, it seems that work is underway: https://gossamer.tools/project/wordpress

> The intention was to allow security vendors to offer code reviews of open source dependencies

What I care most about is just quorum publishing where multiple independent identities sign a release, so that an attacker has to compromise multiple trusted identities to execute a supply chain attack. I'm not too excited about reviews beyond that. The main thing is to upgrade collective ecosystem security by hardening automatic updates.

Solving the problem you care about requires doing what I just said. :)

And, yes, there is a lot of work necessary to get WordPress to use Gossamer. I can't guarantee a deadline right now, but 2022 looks hopeful.

Gossamer looks similar to Google's Trillian which is written in Go.

https://transparency.dev https://github.com/google/trillian

More specifically, Trillian is analogous to Chronicle, which is what Gossamer uses as its underlying ledger. But yeah, there's a lot of similarities. You're on the right track. :)

I'm a bit confused; if we assume that web-of-trust isn't viable, what exactly is good about how PGP does identity?

> non-repudiability nature of PGP messages

Huh? Unless you're signing it (in which case of course it's not deniable, it's a signature) it has no such nature.

Do you care to elaborate on those good reasons that the web of trust "failed"?

This PGP-style concept of persistent identity is almost always the opposite of what you want from a secure messenger, where meta-information about who's exchanging messages with whom is often just as valuable as the message content itself. When the NSA identified Reality Winner communicating with The Intercept, they didn't so much care about what was in those messages; once the link was established, they had better ways of extracting the rest of the information they wanted than trying to defeat a cryptosystem.

> When the NSA identified Reality Winner communicating with The Intercept, they didn't so much care about what was in those messages; once the link was established, they had better ways of extracting the rest of the information they wanted than trying to defeat a cryptosystem.

Which is surely a strong argument for having keys that are standalone and portable across different communication media, rather than having them be coupled to accounts on particular services (or, worse, to personal information like an SSN or phone number).

sequoia is better :)

Age doesn't do signing.

Fortunately, minisign does.

age doesn't replace everything PGP does, which is good, because PGP does too many things. It just replaces the use case of file encryption (which itself is arguably too general; it's perhaps best to think of age as a good fallback for encryption use cases that don't have a better domain-specific tool). See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

This is the second link to "The PGP Problem" here. I will only post my critique of that anti-PGP rant once:

* https://articles.59.ca/doku.php?id=pgpfan:tpp

The thread on that post:

https://news.ycombinator.com/item?id=27181576

Obviously consider the source, but: I think that thread is better reading than the article.

Age doesn't do signing because PGP's signing mechanics have been one of the biggest fiascos in popular cryptography (to this day, mainstream PGP use via GnuPG doesn't produce authenticated ciphertext, due to confusion on the part of PGP's designers on the distinction between authentication and signatures). In day-to-day encrypted secure messaging, durable signatures are one of those things that sound great but are actually the opposite of what you want.

The most widespread practical use of PGP's signature capabilities are for package systems, where the actual contents of the package aren't confidential to begin with; PGP is only being used to sign. But PGP signatures are clumsy and archaic, and there are better tools to get the same capability without PGP's baggage --- notably the "signify" scheme that OpenBSD came up with and that minisign implements.

> due to confusion on the part of PGP's designers on the distinction between authentication and signatures

I'm not sure where you're heading when you think that the general populace would be any less confused about that.

Can you reword this? I'm not sure what you're saying here. Are you asking me to go into more detail on the difference between a signature and a message authentication tag?

Confusing the two is perilous.

https://blog.cryptographyengineering.com/2016/03/21/attack-o...

Age isn't a complete PGP replacement (and doesn't try to be). Agree, it's a better tool for the use-cases it covers.

Age can't authenticate when encrypting to a public key because it doesn't support signatures. So don't use it in this mode unless you know what you are doing.

Most people should just use GPG for stuff like this.

That’s the whole point.

Cryptography tools should do one thing and do it well. Most of PGP’s problems stem from it including the kitchen sink.

If you need signatures, use minisign.

The requirement for signatures to authenticate public key encryption is inherent. OpenPGP includes it because it is for all practical purposes mandatory. It isn't some sort of useless frill.

This is public key cryptography 101 stuff...

Nobody should be using GnuPG casually; if you're still using it in 2021, you should have a really clear reason for doing so. You're virtually always better off using any other well-known tool. The reasons you've provided in the past for defaulting to GnuPG --- such as its avoidance of authenticated encryption being a good data recovery mechanism --- have, to put it gently, not seemed especially informed by cryptographic best practices. It seems like more of a social cause for you than an engineering decisions. Which is fine as far as it goes, but it'd be better if you were clearer about that.

I use it indirectly with pass (passwordstore.org), which is one of the few security-related pieces of software I like. Do you have an opinion on that? I've never heard of age before, but it looks like a pass-like interface to it could be ejected in a few hours if one were so inclined.

Is the antipathy towards GPG based on it being too easy to misuse/misapply, or is it because it's broken when used properly?

I've heard nothing but good things about pass. There's also a pass that uses age now, which is I guess what I'd use if I was in the market for something like it. There's a point at which you're asking so little from your cryptosystem --- as is the case with local-only CLI password managers --- that it doesn't much matter that you're using PGP. I don't, like, recoil from .pgp.asc files! The place you really get in trouble with PGP is when you try to use it on email.

There was a link posted elsethread ( https://news.ycombinator.com/item?id=29715664 ) which reviews a lot of the issues with PGP: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

there in fact exists a pass-like interface for age: https://github.com/FiloSottile/passage

>The reasons you've provided in the past for defaulting to GnuPG --- such as its avoidance of authenticated encryption being a good data recovery mechanism --- have, to put it gently, not seemed especially informed by cryptographic best practices.

That greatly misrepresents my position. Generally I prefer that things follow some sort of open standard. For offline capable, stateless encryption that leaves the OpenPGP standard. I have spent some time looking at it and judge it to be completely OK and worthy of use. I was even inspired to write a series of articles about it in an attempt to counteract the misinformation that I have seen:

* https://articles.59.ca/doku.php

Reply on news.ycombinator.com