Rnp: An OpenPGP Library in C++
rnpgp.com
rnpgp.com
If the S/MIME spec does not enforce (and it seems it doesn't even allow, not just does't enforce) Authenticated Encryption, then it violates "the cryptographic doom principle" and should not be used for anything except CTFs and cryptopals exercises.
If you work around its flaws pgp has great assortment of utilities thay work beautifully.
For encrypting backups, sending secure messages, signing packages, and securely sending files to people, there are materially better options. None of them look like PGP; that is, none of them have a multipurpose-tool design with a wide variety of cryptographic options. That PGP-style design has been discredited in the crypto engineering community, and new tools actively avoid it.
I’d bet that the majority of GPG usage involves checking the public key against the website of the other party (for example, against a fingerprint on a project’s site, or the person’s blog), and then maybe checking against another source posted by that person.
Keybase is just some syntactic sugar around the “check the person’s sites for their fingerprint”. But I’d argue that if we’re going to just use that as a validating mechanism, we might as well just use minisign or Signal, depending on whether I’m validating package signatures or trying to send a message.
For other cases, it's often sufficient to follow the 'trust on first use' model, keeping in mind you need to build up trust by initial interactions whose contents are not highly sensitive. In both these cases, PGP works fine, and I suspect if people just didn't worry about web of trust and followed that simple guideline, the resulting state of sending encrypted emails would already be much better than it is now.
The designs promoted by minisign and age work the way you talk about here, and have the benefit of using modern curve crypto, so keys are even shorter than SSH keys and even easier to move around, without all the ceremony PGP requires.
GPG supports ed25519 ecc identities, which can be used in SSH, too. Which shorter keys are you referring to?
And to once again repeat the question begging an answer: which alternative do you propose to independently create and manage a cryptographic identity?
I think you owe an answer to that question given how you criticize the de facto standard for it.
GPG supports ed25519. In some spec somewhere or other, and probably in a version of GnuPG as well, GPG supports everything. But in practice, GPG is RSA and CAST5 in CFB mode with PGP's archaic authenticator. And the impact of Efail was to email, the same way the impact of a memory corruption vulnerability might be to pop calc.exe (at first). But the flaw behind Efail was that GPG released unauthenticated plaintext to callers, which is something cryptosystems are meant never to do.
I've read the "Modern Alternatives to PGP" page by George Tankersley that has been frequently cited on HN [1], but all it gives for this is using nacl/box, and suggests Keybase's saltpack as a format.
I'm reluctant to install Keybase just to get their saltpack implementation, since I don't need anything else Keybase does.
It looks like I could easily write something using libsodium to meet my needs, and I've been told that libsodium is sufficiently high level that doing so would not be a violation of the "don't implement your own crypto" advice. Surely, though, there must be some simply tool for this already?
What I will say is that while this use case sounds super important (and it is important), it is not as universal as it sounds; the majority of "encrypt this file" uses cases fall into one of the exceptions I provided above, all of which have better tools than PGP today.
A good Google search to start with is [matthew green PGP].
At this point, the serious discussion to have is less "what's a critical assessment of PGP" (dozens have been made over the last decade) but rather "for a given use case, what's the best alternative?"
https://ianix.com/pub/ed25519-deployment.html#ed25519-hardwa...