3 ms·
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 pag
by aborsy 5y ago
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.
- tptacek 5y agoSSH 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?
- deknos 5y ago> 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.
- pabs3 5y agoDebian is planning on a custom replacement for OpenPGP along the lines of minisign: https://wiki.debian.org/Teams/Apt/Spec/AptSign https://wiki.debian.org/Teams/Apt/Spec/AptSign