Hacker News Reader

Comment by aborsy | Hacker News Reader

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.

View on HN

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 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

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.

> 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...

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.

Reply on news.ycombinator.com