1. 10
  1.  

  2. 6

    Even though I believe OpenPGP is dead (and dangerous), I’m willing to give credit where credit is due and recognize that Sequoia PGP doesn’t completely suck. sq(1) is significantly easier to use than gpg(1).

    1. 3

      Why do you believe it’s dead (and “dangerous”)?

        1. 3

          It’s probably a good idea to link also to this: https://articles.59.ca/doku.php?id=pgpfan:tpp

        2. 6

          The cryptographic community is moving away from PGP, for a host of reasons.

          1. The UX of GPG is a nightmare.
          2. As a result, the GPG documentation is incredibly lengthly. The gpg(1) manpage alone is 56+ pages, while age(1) is 1+. The OpenPGP specification spans several RFCs, while the age is a single Google doc.
          3. Until just recently, GnuPG only used weak KDFs, and it still defaults to KDF_ITERSALTED_S2K. age(1) has always used scrypt.
          4. GnuPG’s MDC authentication is broken. age(1) ciphertext is authenticated with ChaCha20-Poly1305.
          5. OpenPGP keys are not forward secret. There is an RFC draft (another one!), but it’s not without problems. However, age(1) keys are also not forward secret.
          6. OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.
          7. OpenPGP leaks metadata. age(1) only leaks its version format and public keys of recipients.
          8. The SKS keyservers are vulnerable to a plethora of vulnerabilities, thus killing the Web of Trust, killing the PGP Strong Set, and ultimately GnuPG ignoring all signatures coming from a keyserver. age(1) doesn’t and will not support signing or key distribution.
          9. The goal of PGP was to protect email, and it turns out, email can’t be effectively protected. Email is fundamentally unsecurable. age(1) is strictly for encrypting files to other people (or yourself) using their (or your) public key, and that’s it.

          GPG is fine for file encryption, although not without its warts and footguns. It really doesn’t offer you anything you can’t already do with age(1) for file encryption and ssh-keygen(1), signify(1), or minisign(1) for certificates, signatures, and verification.

          1. 6

            Sounds to me like mostly problems with GPG, not so much with OpenPGP.

            Hence Sequoia.

            1. 5

              I don’t think they’re entirely separate. Up until Sequioa, the OpenPGP standard meant using GnuPG. It’s not uncommon for lay GnuPG users to confuse the standard with the implementation. OpenPGP = GnuPG for most of the PGP community.

              Sure, there were other tools that weren’t frontends to GPG that implemented the OpenPGP standard, but they failed to gain any real traction from what I can see (I’m not sure PGP gained any real traction in the broader security community anyway). I think OpenBSD tried their hand at an OpenPGP implementation? I don’t recall what it is/was. I know they have signify for signing and verifying packages (which isn’t OpenPGP), but I don’t know if they implemented an encryption/decryption tool. NeoPG gave up due to the complexity of the OpenPGP standard and “competing” with GPG.

              And as mentioned in my original reply, I really like Sequoia. It’s just unfortunate it took the EFAIL vulnerability to kind of kick OpenPGP in the ass and see if the greater PGP community can’t do much, much better. The Sequoia PGP library, the OpenPGP CA web of trust, and 3rd party online identity proofs like Keybase and Keyoxide are definitely improving the landscape. Just the fact that Sequoia is taking the good parts out of the standard, while refusing to implement the footguns and “90s crypto” is enough to take note of.

            2. 4

              OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.

              This in particular is something I hear a lot, but I don’t buy the argument that this is inherently a problem. It makes sense that you would want to be able to decrypt files from 10+ years ago without having to try and compile an ancient version of encryption software. As long as the applications and tooling you use does not use these older ciphers and primitives unless you explicitly tell it to, then I see no problem.

              Sequoia even goes further than having sane defaults, by implementing a policy mechanism to decide which ciphers and features are allowed when invoked. This means the tool or application you are using will be able to ensure that Sequoia will not use any cipher except for the ones specified by said application/tool.

              1. 2

                This in particular is something I hear a lot, but I don’t buy the argument that this is inherently a problem. It makes sense that you would want to be able to decrypt files from 10+ years ago without having to try and compile an ancient version of encryption software. As long as the applications and tooling you use does not use these older ciphers and primitives unless you explicitly tell it to, then I see no problem.

                The problem is that standard doesn’t clearly draw a line in the sand on what is safe and what isn’t. E.G., modern cryptography is moving away from RSA towards ECC, due to the footguns RSA ships that ECC does not. Standards should be expired as vulnerabilities are discovered and modern replacements are agreed upon, and software should sunset support for the expired standards at new version releases.

                This is why age(1) is so attractive–it’s highly opinionated on its cryptographic primitives, rather than supporting cipher agility. If a catastrophic vulnerability is found in ChaCha20-Poly1305, it’s trivial for age to release a new software version that switches out ChaCha20-Poly1305 for a more secure cipher, with the clear announcement that you should migrate your old ciphertexts, and that support for older versions will no longer be supported.

                1. 1

                  Standards should be expired as vulnerabilities are discovered and modern replacements are agreed upon, and software should sunset support for the expired standards at new version releases.

                  I’ll back this up with an example. In this issue on GitHub, Filippo proposes deprecating and/or removing from the Golang x/ libraries (which are “officially supported” but not part of the standard library).

                  • Blowfish
                  • bn256
                  • CAST
                  • MD4
                  • OTR
                  • RIPEMD160
                  • TEA / xTEA
                  • Twofish
                  • XTS
                  • OpenPGP
              2. 2

                It appears you threat gpg and OpenPGP as indentical. This is not the case. And se of your arguments appear to just stream from the fact that OpenPGP has a multiple decade long history. Of course you will find outdated methods here, and of course implementations still support them, because users should still be able to decrypt their old data.

                Furthermore, I am not sure if sufficient satisfying Forward Secrecy with a heavily asynchronous communication medium (E-Mail) is possible. The conditions are different when compared with, e.g., Instant Messaging.

                1. 2

                  Unfortunately downgrade attacks are a real and annoying thing, as well as security issues in very old and not-often-used code. Throwing out that whole part and maybe providing a “gpg_with_old_stuff” separately if you really need it may not be a bad idea.

                2. 2

                  I definitely agree with you. But to be fair, age(1) does not have any authentication built into it. Which, while i love age in general, I think is an oversight, and why I don’t think it should be considered as a drop-in replacement for GPG for something like email encryption.

                  Also, keys are described as “ephemeral”. I don’t use GPG, but I quite like the idea of just putting a pubkey on my website and leaving it at that. Again, another reason why I don’t think you should use it for long-term email encryption.

                  Edit: I suppose I didn’t consider that some people say that you should rotate asymmetric keys frequently (e.g. SSH keypairs), in which case I suppose age’s small and ephemeral keys would probably be a plus.

                  1. 3

                    The meta-point of this post (mentioned by me in a sibling comment) is that PGP tries to do a bunch of stuff with one application, and is mediocre at most of them.

                    Back in the MC Hammer era from which PGP originates, “encryption” was its own special thing; there was one tool to send a file, or to back up a directory, and another tool to encrypt and sign a file. Modern cryptography doesn’t work like this; it’s purpose built. Secure messaging wants crypto that is different from secure backups or package signing.

                    1. 3

                      Yeah I totally agree with that, I’m firmly in the “GPG needs to die” camp.
                      But am I wrong in saying that the main purpose of GPG these days is [supposed to be] email encryption? My point is I don’t think age alone satisfies that.

                  2. 2

                    The UX of GPG is a nightmare.

                    Agreed but what would you expect from a software modeled after PGP 2.x released in the 90s?

                    As a result, the GPG documentation is incredibly lengthly. The gpg(1) manpage alone is 56+ pages, while age(1) is 1+. The OpenPGP specification spans several RFCs, while the age is a single Google doc.

                    You may be happy to hear that the OpenPGP specification is getting “refreshed” and consolidated: https://gitlab.com/openpgp-wg/rfc4880bis#openpgp-cryptographic-refresh-of-rfc-4880

                    For some people “google doc spec” is enough, others like legal protections that the IETF process guarantees. I think there are reasons why HTTP/2 or TLS are maintained at IETF and a google doc is not enough.

                    Until just recently, GnuPG only used weak KDFs, and it still defaults to KDF_ITERSALTED_S2K. age(1) has always used scrypt.

                    Yep, definitely. GnuPG should improve on that part. Still, storing private keys in software is a bad idea in general.

                    GnuPG’s MDC authentication is broken. age(1) ciphertext is authenticated with ChaCha20-Poly1305.

                    MDC was a product of its times and the work is underway for authenticated encryption in OpenPGP.

                    OpenPGP keys are not forward secret. There is an RFC draft (another one!), but it’s not without problems. However, age(1) keys are also not forward secret.

                    In some use-cases forward secrecy is a natural fit (like instant messaging) in others like long-time encrypted backups not so. Trivia: double-ratched protocols can be build on top of OpenPGP too: https://sequoia-pgp.gitlab.io/openpgp-dr/openpgp_dr/index.html

                    OpenPGP defines and supports old primitives, including RSA, DSA, MD5, SHA-1, IDEA, 3DES, CAST5, El Gamal, RIPEMD160, and many more. age(1) is highly opinionated, supporting only modern primitives of X25519, HKDF-SHA256, HMAC-SHA256, scrypt, RSAES-OAEP_SHA256, and the system CSPRNG.

                    Then how does encryption to SSH keys that are RSA-based work? E.g. I just tried age -R ~/.ssh/id_rsa.pub -a message and it worked just fine.

                    OpenPGP leaks metadata. age(1) only leaks its version format and public keys of recipients.

                    Interesting because OpenPGP packet containers contain version and key IDs too. And the link you added says just that so this similar to age?

                    The SKS keyservers are vulnerable to a plethora of vulnerabilities, thus killing the Web of Trust, killing the PGP Strong Set, and ultimately GnuPG ignoring all signatures coming from a keyserver. age(1) doesn’t and will not support signing or key distribution.

                    Web of Trust still works in small circles of technical people, for example see the kernel.org keysigning map. Note that even if SKS is broken it doesn’t mean that the WoT is broken since the signatures are “decentralized” (it’s possible to reconstruct it from SKS dumps). Some other distros use WoT “circles” like that too, see Arch Master Keys or Gentoo developer keys.

                    Age not supporting or even advertising any way of how keys can be retrieved or checked is avoiding an issue not a feature. I understand they don’t want to bloat the “main” project but this needs to be addressed somehow.

                    The goal of PGP was to protect email, and it turns out, email can’t be effectively protected. Email is fundamentally unsecurable. age(1) is strictly for encrypting files to other people (or yourself) using their (or your) public key, and that’s it.

                    Well, I did use age over e-mail the other day with a friend. It still leaked metadata through e-mail headers. Does it mean age is broken? Or if I say “no, PGP is only for file encryption” will the e-mail issue disappear? I don’t think so…

                    My 2 cents: PGP ecosystem has stagnated over the years. Other protocols, such as HTTP and TLS were properly upgraded to the XXI century and even got some exciting features (like Certificate Transparency). I believe it’s still possible to somehow modernize PGP and tools such as age show how it should be done. I just hope age, and signal, one-party-controlled solutions are not the last word.

                    1. 1

                      what would you expect from a software modeled after PGP 2.x released in the 90s?

                      Slow but serious improvements. Either by new commands and deprecation (like git switch) or by redoing the interface (ifconfig -> iproute2). It’s possible and was ignored.

                      Then how does encryption to SSH keys that are RSA-based work?

                      RSAES-OAEP_SHA256 was on the list.