Remix.run Logo
stackghost 2 days ago

Well, how about the fact that gnutls allowed passive cleartext recovery attacks to go unpatched for about 2 years?

How about the fact that GnuPG is predicated upon the web of trust which has been demonstrated not to work, encourages misuse in the form of long-lived identities which discourages key rotation, has no ratchets nor forward secrecy, has multiple internal key parsers, and a littany of vulnerabilities involving authentication and downgrade attacks?

GNU is just organizationally incapable of producing secure code. These tools are not good tools. GnuPG in particular offers absolutely nothing that another single-purpose tool doesn't do better, but for some reason people get emotional and mount all kinds of irrational defenses of it. GPG is not good. It is broken at a fundamental level.

CarpaDorada 2 days ago | parent | next [-]

>Well, how about the fact that gnutls allowed passive cleartext recovery attacks to go unpatched for about 2 years?

They patched it when they became aware of it in <https://gitlab.com/gnutls/gnutls/-/issues/1011>, it was not "allowed" to go unpatched.

>How about the fact that GnuPG is predicated upon the web of trust

No it is not, the web of trust is one mode of operation out of infinitely many that you can come up with, it's not forced upon the user. It was evangelized for a long time until the keyservers got DOSed. In retrospect obvious, but also gnupg is more-or-less an "activist" project -- big corps and govs are against encryption for the masses by and large. Had it had institutional backing from the beginning (which it never got) it'd have a much more robust model for users to work with.

>encourages misuse in the form of long-lived identities which discourages key rotation

You can automate key rotation with gpg. The long-lived identity argument can be seen as a strength too, short-lived isn't always better.

>a littany of vulnerabilities involving authentication and downgrade attacks?

I'm not aware of these; do you mean that GnuPG is not secure by default in its algorithm list? It chooses compatibility over security, but you're free to change the configuration. I think it's too harsh to say that GnuPG is inadequate because of that.

>GNU is just organizationally incapable of producing secure code.

I don't see why that'd be true, anyone can contribute to GNU so there is nothing inherent about GNU that makes its projects insecure.

>GPG is not good. It is broken at a fundamental level.

Works for me! I use it to sign my git commits and tarball releases, and with gpg-agent I get to authenticate to SSH servers.

stackghost 2 days ago | parent [-]

>Works for me!

Hey, so long as you're cognizant of the fact that everyone credible thinks GPG is at best a security LARP, do what you feel is best.

worthless-trash 2 days ago | parent [-]

What better options are there, if you're aware of these weaknesses i'm sure you're aware of better options.

fmajid 2 days ago | parent | next [-]

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

CarpaDorada a day ago | parent [-]

This is an anonymous blog, and the author conceals their identity, which is already an issue for me. Let's look at the alternatives to PGP that the blog recommends, I will paraphrase:

1) Sign software with sigstore.dev

The issue here is that you delegate trust to places like GitHub or other OIDC providers. You also have to trust Fulcio and their CAs. <https://docs.sigstore.dev/about/security/> for details. Maybe you don't want to do that, in part because you're not guaranteed that the service will remain free, or perhaps you're more serious about security than GitHub.

1-alt) Sign software with minisign.

Maybe I don't want to use Ed25519. Maybe I want to revoke the signatures. There's many issues one may have with minisign.

2) Signing git tags/commits

Advises to use SSH, no explanation why. Advises Ed25519, why not Ed448? The explanation to not use RSA is by linking to <https://blog.trailofbits.com/2019/07/08/fuck-rsa/>. I will only quote one thing from this article:

>RSA was an important milestone in the development of secure communications, but the last two decades of cryptographic research have rendered it obsolete.

You can't say it is obsolete when it is still in use. I'm not sure what the author(s) mean by "obsolete", but it is not true that RSA is obsolete. (If Ed25519 breaks but RSA doesn't, who will be obsolete?)

3) Sending files between computers

Here it recommends Magic Wormhole. That's shocking to me, I don't understand why it is recommended. Why not rsync? If you look at the 2016 presentation for Magic Wormhole <https://www.lothar.com/~warner/MagicWormhole-PyCon2016.pdf>, the pitch is that it is especially useful when the computers are unrelated. How often is that the case? Rsync is a much better solution for anyone who wants to transfer files between servers they have access to.

4) Encrypting Backups

Here they recommend tarsnap as "the usual recommendation", I've got to say, it's definitely not the usual recommendation.

5) Encrypting Application Data

They say to use Tink or libsodium. Tink has many implementations in each language, (how does that help security?) and libsodium doesn't support RSA, two things on top of my head that may be deal breakers.

6) Encrypting Files

They recommend age; wishful thinking as most people do not use age. In fact most people do not bother encrypting files, and it is not something that is done often. The author likes to talk about footguns, well there's certainly many footguns to file encryption. This is where the most analysis is on this blog article too, but this is a niche case.

7) Private Messaging

It recommends Signal. What about e-mail?

>(Unless you’re legally required to use PGP because of a government regulation… in which case, why do you care about my recommendations if you’re chained by the ankle to your government’s bad technology choices?)

It comes off as know-it-all.

Let me close with this: Cryptography is infamous for debates. It never ends, and many people have ended up with egg on their face for their claims. Tread carefully and don't rely on others too much!

stackghost 2 days ago | parent | prev [-]

More in keeping with the Unix philosophy of doing one thing and doing it well (GnuPG in particular does a mediocre job of many things), the best move is to replace it with a suite of single purpose tools.

For example, signing commits with minisign or signify.

CarpaDorada 2 days ago | parent [-]

>For example, signing commits with minisign or signify.

These tools don't work well with git or the git forges, and they do not work at all with fossil. (Obviously signify is a good choice if you're using OpenBSD.) Furthermore they lock you in entirely in their choice of algorithm, Ed25519, which may not be what you want (Why not Ed448?)

As far as adoption goes, and adoption is hard to get going, GnuPG is what is used in Linux the most...

stackghost 2 days ago | parent [-]

"Github supports GnuPG signatures" does not contradict the statement "GnuPG is trash". I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.

tapete 2 days ago | parent | next [-]

> I will not engage further, it's obvious you are not interested in honest discussion of the technical merits.

Well you are neither, all you do is throw unobjective flames around ("gnupg is trash") and post various claims about bad security without backing them up, implicitly demanding that other people do the leg work of disproving your accusations against the GNU project.

Are you working for Apple by any chance?

stackghost a day ago | parent [-]

>Are you working for Apple by any chance?

No, my background is in aerospace and I'm currently in grad school planning to pivot into a different field.

CarpaDorada 2 days ago | parent | prev [-]

The issue is mostly with git itself, e.g. take a look at

  git cat-file commit HEAD
to see something like:

  tree <tree-hash>
  parent <parent-hash>
  author <author-name> <author-email> <timestamp>
  committer <committer-name> <committer-email> <timestamp>
  gpgsig -----BEGIN PGP SIGNATURE-----
   
   <ascii-armored RFC9580 signature>
   -----END PGP SIGNATURE-----

  <commit message>
You can view an example of the structure of this ascii-armored signature here <https://cirw.in/gpg-decoder/#-----BEGIN%20PGP%20SIGNATURE---...>.

You can add a patch to git to support more signature types than just OpenPGP. You may then be able to move mountains and get GitHub/others to join in the validation. Finally, if you can find bugs/exploits in GnuPG, you should report them and you will definitely get credit and recognition for them. They are not trivial to find.

fmajid 2 days ago | parent [-]

Git has supported SSH-based signatures for a while now, including those backed by FIDO hardware keys.

CarpaDorada a day ago | parent [-]

FIDO would be for authentication, not signing. It also supports SSH (and X.509, see <https://git-scm.com/docs/gitformat-signature>) but it does not support minisign or signify. There's a git module for signify, <https://leahneukirchen.org/dotfiles/bin/git-signify> but don't count on it being widely supported.

worthless-trash 2 days ago | parent | prev [-]

What was the CVE for that cleartext downgrade attack ?

stackghost a day ago | parent [-]

For gnutls? I believe it was this one: https://nvd.nist.gov/vuln/detail/CVE-2020-13777

It was not a "downgrade attack", it was passive cleartext recovery.

worthless-trash 19 hours ago | parent [-]

Ah, my mistake, thats why I couldn't find it. Thanks for the link.