[felipelalli]

Even though I read so many posts criticizing PGP, it's still difficult for me to find an alternative. He states in the article that being a "Swiss Army Knife" is bad. I understand the argument, but this is precisely what makes GPG so powerful. The scheme of public keys, private keys, revoke, embedded WOT, files, texts, everything. They urgently need to make a "modern version" of GPG. He needs a replacement, otherwise he'll just be whining.

[schoen]

There's a section in this post with proposed replacements:

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/#th...

I was also frustrated with this criticism in the past, but there are definitely some concrete alternatives provided for many use cases there. (But not just with one tool.)

[eddythompson80]

I’m still frustrated by the criticism because I internalized it a couple of years ago and tried to move to age+minisig because those are the only 2 scenarios I personally care about. The overall experience was annoying given that the problems with pgp/gpg are esoteric and abstract that unless I’m personally are worried about a targeted attack against me, they are fine-ish.

If someone scotch tapes age+minisig and convince git/GitHub/gitlab/codeberge to support it, I’ll be so game it’ll hurt. My biggest usage of pgp is asking people doing bug reports to send me logs and giving them my pgp keys if they are worried and don’t want to publicly post their log file. 99.9% of people don’t care, but I understand the 0.1% who do. The other use is to sign my commits and to encrypt my backups.

Ps: the fact that this post is recommending Tarsnap and magicwormhole shows how badly it has aged in 6 years IMO.

[brewmarche]

> git/GitHub/gitlab/codeberge

Is this about commit signing? Git and all of the mentioned forges (by uploading the public key in the settings) support SSH keys for that afaik.

git configuration:

gpg.format = ssh

user.signingkey = /path/to/key.pub

If you need local verification of commit signatures you need gpg.ssh.allowedSignersFile too to list the known keys (including yours). ssh-add can remember credentials. Security keys are supported too.

[nine_k]

Has Tarsnap become inadequate, security-wise? The service may be expensive for a standard backup. It had a serious bug in 2011, but hasn't it been adequate since then?

[deknos]

you cannot selfhost it. it's not verified and audited independently as a whole system.

for some people, that's important

[eddythompson80]

I don’t know anything that makes me think it’s inadequate per se, but it’s also been more than 10 years since I thought about it. Restic, gocryptfs, and/or age are far more flexible, generic and flat out better in managing encrypted files/backups depending on how you want to orchestrate it. Restic can do everything, gocryptfs+rclone can do more, etc.

[aniviacat]

> the fact that this post is recommending Tarsnap and magicwormhole shows how badly it has aged in 6 years

What's wrong with magic wormhole?

[eddythompson80]

It’s just not the same thing. There is significant overlap, but it’s not enough to be a reasonable suggestion. You can’t suggest a service as a replacement for a local offline tool. It’s like saying “Why do you need VLC when you can just run peertube?”. Also since then, age is the real replacement for pgp in terms of sending encrypted files. Wormhole is a different use case.

[jcgl]

Adding to my comment since it was downvoted:

There are two parts of "sending encrypted files": the encryption and the sending. An offline tool (e.g. PGP or age) seems only necessary when you want to decouple the two. After all, you can't do the sending with an offline tool (except insofar as you can queue up a message while offline, such as with traditional mail clients).

The question thereby becomes "Why decouple the sending from encryption?"

As far as I can see, the main (only?) reason is if the communication channel used for sending doesn't align with your threat model. For instance, maybe there are multiple parties at the other end of the channel, but you only trust one of them. Then you'd need to do something like encrypt the message with that person's key.

But in the use-case you mentioned (not wanting to publicly post a log file), I don't see why that reason would hold; surely the people who would send you logs can trust trust Signal every bit as easily as PGP. Share your Signal username over your existing channel (the mailing list), thereby allowing these people to effectively "upgrade" their channel with you.

[jcgl]

Sticking to the use case of serving that 0.1% of users, why can’t a service or other encrypted transport be a solution? Why doesn’t Signal fit the bill for instance?

[stackghost]

The so-called web of trust is meaningless security theatre.

>They urgently need to make a "modern version" of GPG.

Absolutely not.

[Diti]

> The so-called web of trust is meaningless security theatre.

Ignoring your comment’s lack of constructive criticism, I’m going to post this meaningful implementation that an excellent cryptographer, Soatok Dreamseeker, is working on: [1].

You may also search for his posts in this HN thread, his nickname is “some_furry”.

[1]: https://github.com/fedi-e2ee/public-key-directory-specificat...

[zenethian]

Keyservers already “solved” this problem without needing federation because we only needed one keyserver anyway. Federating them isn’t going to do anything. Web of trust is a broken system that sounds super cool until you try to really use it. It has so many flaws that there’s really no way to revive it. Keybase tried to do something about it and also failed.

[some_furry]

To be clear, this is not Web of Trust. It's using Key Transparency as a means to distribute public keys more securely than TOFU.

If people want to build WoT on top of ny design, I won't stop them, but it's not a goal of mine.

[rolandog]

Keybase was doing great until it got acquired by Zoom and people felt uneasy about the implications, IIRC