Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The PGP Problem

latacora.micro.blog

Post reply on HN
Print view View original

21–30 of 369 posts

Re: The PGP Problem

#21

Post by srl »

First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone.

It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For instance, archlinux (I'm loyal) signs packages with PGP[1] and, for source-built packages, encourages integrity checks with MD5. My recollection is that, about 5 years ago, MD5 was supposed to be replaced with SHAxxx. Am I misinterpreting this? Is this actually Perfectly Okay for what a distro is trying to accomplish with package distribution?

(I'm particularly suspicious of the source-built package system, which consists of a bunch of files saying "download this tarball and compiler. MD5 of the tarball should be xyz." I'm pretty confident that's not okay.)

Okay, now moving from package distribution to messaging, and again looking at the state of my favorite system. How am I supposed to message securely? The best nix messaging tools are all based around email. Even when I can get the PGP or S/MIME or whatever toolset to work (let's face it, that's at least 45 minutes down the drain), it's clear that I'm not in good shape security-wise.

I should use signal, apparently. Great. Just a few problems: (1) no archlinux signal package, (2) I'm guessing I can't use it from the terminal, and (3) most severely, it seems signal has incomplete desktop support. In particular, I need to first set up signal on my phone. Well, let's face facts: I have a cheap phone from a hard-to-trust hardware vendor, and I think there's a >5% chance it's running some sort of spyware. (The last phone I had genuinely did have malware: there were ads showing in the file manager, among other bizarre behaviors.) So in order to use signal on my desktop, I need to buy a new phone? That's even worse, usability-wise, than PGP.

Is... is it really this bad? I'm getting the sense that the desktop linux community has completely dropped the ball on this one. (And perhaps more generally desktop mac/windows... I wouldn't know.)

[1] Perhaps not so bad, since the keyring is distributed with the system -- but how was the original download verified? Options are: PGP, MD5, SHA1, with the choice left up to the user. That can't be right.

Re: The PGP Problem

#22

Post by cyphar »

tptacek wrote: post #16
cyphar wrote: post #11

Earlier quoted context omitted.

Matrix works, and has fairly easy-to-use clients (and I've switched a few non-technical folks without too much trouble). It's also an open protocol, not just an app. The main criticism (and I'm preemptively responding to tptacek here) is that they haven't yet made E2EE the default (though this should happen in a few weeks now that cross-signing appears to be done). I also think the key backup system should be much be…

Use Matrix if you want to contribute to Matrix or are an enthusiast about what Matrix is trying to do. But don't use it as a secure messenger, or tell at-risk people to use it. It may someday be a serious option for secure messaging, but it is not that today. I'm not a Matrix hater, but I think Matrix's cheering section gets the project in trouble, since their answers about privacy and security are demonstrably worse…

Is there a specific issue other than "it's not the default" that precludes it from secure messaging? This is the thing I don't understand about your position -- you have been saying for a very long time that "it's not ready yet" but as far as I can see the default-to-unencrypted setup is the main issue you have with it? I get that asking a journalist to use it right now is a bad idea, but if E2EE was the default today what other issues do you see?

From my PoV, Matrix has many features that might actually end up increasing security over Signal's design. Just as an example, you cannot blacklist or even get alerted to new devices being added to an E2EE conversation with Signal (and if you look at things like the Assistance and Access legislation here in Australia, that is a serious concern). With Matrix you do detect it and can blacklist the other device (and with cross-signing being done very soon, you can also be sure that verification of devices will be a rare event). I also think the new emoji-based verification is a massive improvement over Signal's "safety numbers" setup.

Re: The PGP Problem

#23

Post by lvh »

tptacek wrote: post #19
lvh wrote: post #17

Earlier quoted context omitted.

Re: magic-wormhole's 16 bits: I don't think you should be worried about that, because SPAKE2 will give you proof positive if the attacker attempts to guess. Are you saying 2*-16 success isn't good enough?

Isn't the code length also selectable?

Yep, the default python implementation lets you pick a code and generate a code with more than 2 words. I'm just cautious in telling people to twiddle knobs that don't need twiddling :-) But you can absolutely go up to 2^-64 or whatever if that makes you happy!

Re: The PGP Problem

#24

Post by roamingnomadic »

Is this blog post satire? or an ad of sorts for some vaporware?

The talking alts either use PGP or a botnet. (signal uses PGP with a CA type of thing, so much for "stop using pgp") and whatsapp is owned by facebook.

tarsnap as I understand requires that I lock in to a service to secure my backups. F- that. Someone already talked about wormhole.

And how is essentially forking pgp with 'age' really going to solve things? Wow thanks another forked app! :^)

It would be easier to just make a wrapper for gnupg that sets the settings for everything the author is talking about. (well most of the things the user is talking about)

Wouldn't it be easier to just inform maintainers of the package to change the default standards of packages like gnupg? Has the author even attempted to change some of these things?

Don't get me wrong, I get where the author is coming from. Uinx philosophy should be followed... but certain systems can not be compartmentalized they have to unfortunately interact with other another.

If you for example encrypt data without signing it, how would you know that someone isn't trying to poison ciphertext to extract data leakage or worse yet, they already found a way to decrypt your data and manipulating sensitive data?

An encryption program by DESIGN should also have a method to sign data.

Re: The PGP Problem

#25

Post by viraptor »

Another use case I don't know a replacement for is offline team+deployment secrets. Requirements:

- you need team members to read/write the secrets

- you need the deployment service to read the secrets

Without using an online system managing the secrets via ACLs + auth, I don't know how to replace PGP here.

Re: The PGP Problem

#26

Post by lvh »

roamingnomadic wrote: post #24

Is this blog post satire? or an ad of sorts for some vaporware? The talking alts either use PGP or a botnet. (signal uses PGP with a CA type of thing, so much for "stop using pgp") and whatsapp is owned by facebook. tarsnap as I understand requires that I lock in to a service to secure my backups. F- that. Someone already talked about wormhole. And how is essentially forking pgp with 'age' really going to solve thing…

> (signal uses PGP with a CA type of thing, so much for "stop using pgp")

I legitimately have no idea what this means.

> And how is essentially forking pgp with 'age' really going to solve things? Wow thanks another forked app! :^)

A big part of the criticism we've gotten when we tell people "PGP bad" is that we're not providing alternatives. age is one of those alternatives, for one of those use cases.

> It would be easier to just make a wrapper for gnupg that sets the settings for everything the author is talking about. (well most of the things the user is talking about) > Wouldn't it be easier to just inform maintainers of the package to change the default standards of packages like gnupg? Has the author even attempted to change some of these things?

As we mentioned repeatedly in the blog post: no, the PGP format is fundamentally broken, it is not a matter of "just fixing it".

> If you for example encrypt data without signing it, how would you know that someone isn't trying to poison ciphertext to extract data leakage or worse yet, they already found a way to decrypt your data and manipulating sensitive data?

I think you're making an argument against unauthenticated encryption here. That's true! You should not have unauthenticated encryption, the way PGP makes it easy for you to have. age is not unauthenticated encryption, so the criticism does not apply.

Re: The PGP Problem

#27

Post by lvh »

viraptor wrote: post #25

Another use case I don't know a replacement for is offline team+deployment secrets. Requirements: - you need team members to read/write the secrets - you need the deployment service to read the secrets Without using an online system managing the secrets via ACLs + auth, I don't know how to replace PGP here.

what's wrong with an online system managing the secrets? KMS is great, and makes it easy to separate decrypt from encrypt permissions.

(KMS is not the only option! I'm just trying to eke out why you think that's valuable. For example, I think age, mentioned in the blog post, is a direct replacement?)

Re: The PGP Problem

#28

Post by srl »

luizfelberti wrote: post #6

The missing answer in there is how to avoid PGP/GnuPG for commit signing. I've asked about this in another similar thread[0] but didn't get a hopeful answer. Everytime I look at git's documentation GPG seems very entrenched in there, to a point that for things that matter I'd use signify on the side. Is there a better way? [0] https://news.ycombinator.com/item?id=20379501

It seems pretty clear that, with the current tools available, there is no way to do this (at least with git). There's nothing in principle difficult about it, just that (say) git+signify hasn't been implemented.

I'm getting the strong sense (see also my toplevel comment, and maybe someone will correct me and/or put me in my place) that there's an enormous disconnect between the open source + unix + hobbyist + CLI development communities, and the crypto community. The former set has almost no idea what the state of art in crypto is, and the latter (somewhat justifiably) has bigger fish to fry, like trying to make it so that non-command-line-using journalists have functional encryption that they can use.

I think this is a sociological problem, not a technical "using command-line tools makes Doing Crypto Right impossible".

Re: The PGP Problem

#29

Post by cyphar »

srl wrote: post #21

First, thanks enormously for writing this -- and for all the other recent articles that have appeared here the vein of "PGP is as bad as it is unpleasant to use". It's a point I didn't really appreciate (at least as much as I (sh/c)ould have) and I'm sure I'm not alone. It seems that the state of package distribution for many distributions is poor, security-wise. (OpenBSD, to nobody's surprise, is an exception.) For…

Arch Linux's pacman is not a good example of a secure package distribution system (especially not the AUR, where you are downloading all the bits from the internet and building them yourself as your own user or even sometimes as root). They didn't do any package signing or verification at all until (shockingly) recently -- less than 10 years ago IIRC. I am a huge fan of Arch's philosophy but am definitely not a fan of the design of their package distribution system.

If you look at systems like Debian-derivatives or RPM-based distros (openSUSE/SLES, and Fedora/CentOS/RHEL) the cryptosystems are far better designed. In the particular case of openSUSE, the AUR-equivalent (home: projects on OBS) are all signed using per-user keys that are not managed by users -- eliminating almost all of the problems with that system. Yeah, you still have to trust the package maintainer to be sure what they're doing, but that should be expected. I believe the same is true for Fedora's COPR.

[Disclaimer: I work for SUSE and contribute to openSUSE.]

Post reply on HN