Any standard I can replace PGP with, that has wide secure hardware element support? e.g. tptacek suggested signify which is awesome, but software only.
You'll have to do some legwork, because discussions of PGP on HN quickly become unproductive; PGP has a very... "engaged" user subculture.
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?"
No. Pgp still has a purpose to serve. Don't just parrot what other people say we should do with pgp. Just because it has some flaws doesn't mean all of the benefits it provides are rendered null.
If you work around its flaws pgp has great assortment of utilities thay work beautifully.
It does not in fact serve any real purpose, at least not in new systems --- or rather, the very few purposes that it exclusively serves are bad purposes.
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.
What's the materially better option for encrypting files for myself? I currently do this with "gpg -v -ear tzs@...". I want a public key system for this so that I do not need to enter a passphrase when encrypting.
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?
This really is a problem. If you're not making a backup, and you're not archiving something offline for long-term storage, and you're not encrypting in order to securely send the file to someone else, and you're not encrypting virtual drives that you mount/unmount as needed to get work done, then there's no one good tool that does this now. Filippo Valsorda is working on "age" for these use cases.
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.
PGP definitely has a problem with verifying identity behind keys, but I think that problem is overblown for a lot of purposes. Most of the emails people send out are to people they already know, and for those it is usually immediately obvious whether the person behind the key is the person you know in real life.
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 biggest problems cryptography engineers have with PGP don't have much of anything to do with "web of trust", but rather with the archaic cryptography PGP in practice uses. Efail, for instance, is a result of flaws that simply don't occur in modern designs, which never release unauthenticated plaintext --- in fact, by cryptographic design, can't do so.
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.
Efail was a problem specific to e-mail, not pgp. BTW, if you attacked e-mail as the insecure by design, factually oligarchic communication system it is, I'd be totally in agreement.
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.
Is there a functional web-of-trust for GPG? My understanding (and personal experience) is that if I want to message somebody using GPG, it’s super unlikely I can derive a pathway through the web-of-trust where I trust somebody who trusts somebody who trust somebody until we eventually get to my intended recipient. Even if that works, it banks of everybody in the chain having done a legit validation of identity, and there’s no way for me to know if they did (vs just picking a key off the web, signing it, and pushing that sig). And even if they did push that sig, where do I get the signatures from, given that the primary key servers used by GPG users are afflicted by a denial of service attack that was disclosed years ago?
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.
They aggregate the signatures but the proofs of identity exist on disparate publicly viewable sites/applications. They commit the state of the signature chain on the public blockchain. So I wouldn't call it completely "centralized"/trusted where you're blindly trusting their SQL database is correct but not "perfectly" decentralized/trustless either.
Perhaps you should blog up an 'Against PGP' to further streamline your internet-friend acquisition rate and prove yourself worthy of challenging the guardian of the top floor of the pagoda (Paul Vixie?) in single combat.
What was fun about "Against DNSSEC" is that I feel like I was one of the first people there with that argument (it's very satisfying to see the rest of the world come around). But on PGP, I'd be very late to the party; nobody in cryptography engineering seems to like PGP, and some of the most high-profile people in the space, like Matthew Green, have repeatedly implied that it's a scourge.
Yes but weirdly you might be the first to put the short anti-PGP case in one place for regular nerds. The nature of DNSSEC is such it's ok not everyone is aware it doesn't do anything for query privacy or whatever. PGP is the other way round - there's a small set of important facts and FAQs relevant and actionable to lots of people. Who not only don't know better but are also being actively misinformed.
S/MIME has better e-mail client support and has massive deployment (use, not that much) in Estonia. I think it already beats PGP in two major aspects with that.