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

PGP Marks 30th Anniversary

philzimmermann.com

Post reply on HN
Print view View original

41–50 of 82 posts

Re: PGP Marks 30th Anniversary

#41

Post by hiq »

upofadown wrote: post #36
schoen wrote: post #6

Earlier quoted context omitted.

I'm a huge fan of Phil and his work, and plan to send him a note of thanks, but I think your second sentiment is out-of-date now. Even if we avoid other controversies like Thomas Ptacek's views about the inappropriateness of the e-mail encryption threat model, PGP doesn't support forward secrecy and so it's at least not suitable for instant messaging or TLS (as well as not being integrated into their protocols!). A s…

Forward secrecy is not of any real value in most instances of instant messaging as people usually keep their old messages around thus negating it. Using OpenPGP in the way that TLS is used would negate the advantage of static encryption and would cause the result to be as insecure as TLS. Probably worse as OpenPGP has not required all the band aids that TLS has ended up with.

> Forward secrecy is not of any real value in most instances of instant messaging as people usually keep their old messages around thus negating it.

Both Signal and WhatsApp have disappearing messages as a feature. Signal now allows users to enable this feature by default for new conversations.

Most people keep their old messages because they're only aware of some remote dragnet surveillance threat in democratic countries. I'm sure the situation is different in countries where the surveillance is more offensive, and perceived so by the population.

Re: PGP Marks 30th Anniversary

#42

Post by GekkePrutser »

tptacek wrote: post #8
greenyoda wrote: post #7

Earlier quoted context omitted.

What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)

The high bit of the right answer to this question is that you don't want to replace PGP; one of the things we've learned in 29 years is that you don't want a single tool to do lots of different cryptographic things, because different applications have different cryptographic needs. For package signing: use something in the signify/minisign family. To encrypt a network transport, use WireGuard. To protect a web transa…

The big problem with those DMGs is that they only work on one OS. This is one thing where PGP encrypted files shine.

Re: PGP Marks 30th Anniversary

#43

Post by guillemj »

dale_glass wrote: post #37
rjzzleep wrote: post #34

Earlier quoted context omitted.

One thing I've noticed is that package signing has a bit of an issue. It lacks metadata about the package. I'll use archlinux as an example but the same applies to PPA's in Ubuntu: Say you add a public key of a third party because you want to install a certain package or add a certain repo. The keyring then trusts that key. But it doesn't trust the key for a specific package. It just generally trusts the key. From a…

My view is that it's because GPG sucks, and has been used for things it doesn't want to be used for. GPG's usage model is a commandline tool, used by a person to verify a signature on a file or such. It has a keyring in ~/.gnupg, and importing keys imports them into this keyring. And it really insists on that. This whole idea of having a key that only applies to a specific package or repository was never intended in…

Hmm this seems to conflate various things.

As anyone who has had to make code interact with GnuPG will attest, I very much agree its interfaces are not ideal to put it mildly. I'm pretty excited, though, about things like Statless OpenPGP CLI (SOP), or Sequoia's CLI f.ex., and several of the other tools referenced up-thread to handle package signatures are also CLI, so I don't think that's an inherent problem.

Regarding packages, apt supports pinning specific keys or keyrings to specific repositories (via the signed-by attribute), as does debsig-verify (which can pin keys or keyrings to specific policies). On Debian, packages get signed by the maintainers (both the source packages, inside the .dsc file, and for the entire upload, inside the .changes file), which get uploaded and then the repository software takes over and signs both source and binary packages in the metaindices. This was made pretty much designed on purpose, and independently of GnuPG CLI's speed or design shortcomings. The repository needs to handle key rotation, due to expiration, algo renewal, security compromises, maintainers leaving the project (and as such their keys not being trusted anymore), etc. Embedding the signatures into the source or binary packages would mean that they would change content, which implies massive mirroring costs, simple digest verification oddities, and similar. Adding detached signatures for each individual source and binary package would make the inode count explode. The metadata still would need to be signed no matter what, and doing either of those per package signing would also make signature update and repository metadata generation and mirroring extremely painful, as you need to be able to do that atomically. In addition the repository needs to be signed as a whole, because it's really a snapshot of a known state, and while it should be fine to mix and match various repositories (at the user request), that should not be the default (at least within a specific repository state).

Re: PGP Marks 30th Anniversary

#44

Post by dale_glass »

dale_glass wrote: post #37
rjzzleep wrote: post #34

Earlier quoted context omitted.

One thing I've noticed is that package signing has a bit of an issue. It lacks metadata about the package. I'll use archlinux as an example but the same applies to PPA's in Ubuntu: Say you add a public key of a third party because you want to install a certain package or add a certain repo. The keyring then trusts that key. But it doesn't trust the key for a specific package. It just generally trusts the key. From a…

My view is that it's because GPG sucks, and has been used for things it doesn't want to be used for. GPG's usage model is a commandline tool, used by a person to verify a signature on a file or such. It has a keyring in ~/.gnupg, and importing keys imports them into this keyring. And it really insists on that. This whole idea of having a key that only applies to a specific package or repository was never intended in…

@guillemj Interesting information, thanks. I stand corrected.

Also, is there a comment depth limit? I can't seem to reply directly. Sheesh.

Re: PGP Marks 30th Anniversary

#46

Post by tialaramex »

southerntofu wrote: post #35
tialaramex wrote: post #30

Earlier quoted context omitted.

> Maybe the reason why people don’t want or like PGP is because it needs strong human processes to work properly and keep its integrity, and that breaks the illusion that you can easily solve everything with tech. What you've got here is pretty much the mirror of the argument you've dismissed a paragraph earlier. Now you're desperate to rely on humans instead. This makes me think about Snowpiercer, for two reasons. O…

> PGP isn't very good technology. What part of PGP precisely? I've read a lot of criticism of PGP but they were either focused on a specific (catastrophic) implementation such as GNUPG, or were really skeptical of usage by non-technical humans. I know quite a few people doing PGP email with Thunderbird and they're pretty happy with it. It's also very convenient that their GNOME-based Tails operating system has PGP si…

When PGP was invented, a bunch of things we are now quite sure how to do either were experimental or hadn't been discovered. In some of those cases you can retro-fit to PGP, so e.g. you can use a nice elliptic curve signing primitive instead of RSA, you can do AES instead of IDEA. So far not too bad.

But then in some cases what we became quite sure about is that PGP's principles/ assumptions are themselves wrong. For example, PGP is pretty sure a message ought to have a digital signature from the sender so you know who it's from. But that's wrong, now you're helping the recipient prove to everybody else what you sent them. That doesn't sound like "pretty good privacy" at all. If instead we do message integrity correctly we can assure the recipient that you wrote it, but since they could have forged that assurance they don't have proof you wrote it which they could show to anybody else. They could tell others what it says, but they could just as well make up any rumours they want.

The worst of these problems is the Web of Trust. The Web of Trust can't work. It might work if everybody you know is a cryptographer and everybody they know is a cryptographer and so on. But it can't work in real life, and often in describing it people make revealing mistakes.

Let me quote somebody else making such a mistake (not on HN) and then I'll reproduce part of my response to their mistake in answer:

"How much do you trust guy #53 of 120 you met at FOSDEM? Do you remember how well you checked his ID?"

I am 100% certain my mother is my mother, but I wouldn't trust her as far as I can throw her. And this is where the WoT breaks down. Your trust metric must reflect your confidence that these people will do their part correctly in the WoT, but even conscientious users often don't understand how to do their part correctly, so realistically almost everybody's "trust" indication for almost everybody should be zero. At which point it's not a "web" it's just a bunch of unconnected points.

Re: PGP Marks 30th Anniversary

#47

Post by gspr »

mratsim wrote: post #45

Please let PGP retire as a pioneer now and not as a laggard tomorrow. - https://latacora.micro.blog/2019/07/16/the-pgp-problem.html - https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-crypt... - https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695...

Well, then there needs to be a widely adopted, standardized alternative.

Re: PGP Marks 30th Anniversary

#48

Post by dane-pgp »

JshWright wrote: post #40
stratosgear wrote: post #25

This brings back memories. I was an international student from Greece at the University of San Francisco, that fall, and I was present at a CS presentation that took place at the time (I'm not sure if it was Phill or not, but definitely one of the original authors). At the end of the presentation there was a pile of floppies that you could get a copy of the software. I got one along with my other classmates. Unfortun…

> I'm not sure if it was Phill or not One "l" (it's the "z" at the end of "Zimmermann" that's doubled).

> it's the "z" at the end of "Zimmermann" that's doubled

Actually it's the "n" at the beginning of "Zimmermann" that is doubled.

Re: PGP Marks 30th Anniversary

#49

Post by tptacek »

upofadown wrote: post #32
greenyoda wrote: post #9

Earlier quoted context omitted.

Thanks! Link to "age", for those who are interested: https://github.com/FiloSottile/age

Last I looked "age" did not have any sort of recovery utility. It isn't even clear that such a utility is possible (the protocol is poorly documented). A single bit error at the start of the file causes the loss of the entire file. So be careful using it for any sort of thing that might ever require the sort of recovery that bzip2 or lzip provides (gzip has a third party recovery utility). OpenPGP has excellent recov…

I want to be sure I'm reading this correctly. Failing to decrypt on a single bit error is the literal job definition of authenticated encryption. Any error you accept is malleability conceded to an attacker. Are you complaining that age isn't malleable enough?

Re: PGP Marks 30th Anniversary

#50

Post by tptacek »

darkr wrote: post #29
greenyoda wrote: post #7

Earlier quoted context omitted.

What do you recommend as a replacement for PGP? (I'm looking for stand-alone software I can use to encrypt files on storage media, not an encrypted e-mail service.)

The other points in this thread recommending modern, context-specific cryptography tools are very valid, however if you're set on PGP; Sequoia[1] is a new(ish) OpenPGP library written from the ground up in Rust. 1: https://sequoia-pgp.org/

Sequoia is fine work, and running less C code is a good thing, so if you have to use PGP (sorry) then use Sequoia. But note that the PGP ecosystem is hopelessly mired in GPG, and the problems go beyond C code --- Sequoia, for instance, is (AFAIK) the first popular implementation of AEAD crypto for GPG, but AEAD doesn't interoperate with GPG.
Post reply on HN