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

31–40 of 82 posts

Re: PGP Marks 30th Anniversary

#31

Post by shawnz »

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…

Which of these do I use to send encrypted messages to darknet vendors based on well-known public keys shared through Reddit etc? This is the number one use case of PGP for me and it doesn't seem to be solved by any of these other tools.

Re: PGP Marks 30th Anniversary

#32

Post by upofadown »

greenyoda wrote: post #9
tptacek wrote: post #8

Earlier quoted context omitted.

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…

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 recovery properties out of the box BTW...

Re: PGP Marks 30th Anniversary

#33

Post by upofadown »

dale_glass wrote: post #26
globular-toast wrote: post #23

Earlier quoted context omitted.

I think you're wrong on point 1. PGP was always very much about communicating with people you don't know. Otherwise you'd just use symmetric encryption. Web of trust is still the best way we have to do that. Newer applications like signal etc are what require each pair of correspondents to exchange keys and "complete the graph". The difference with more "modern" technologies is just that they let you implicitly trust…

Give it a try, then. 0. GPG implicitly trusts your key. 1. GPG trusts keys you've signed. 2. GPG can also trust keys signed by people you trust. And that's where it ends, normally. So say you want to verify the signature on the Tor browser. So have you met the key holder directly and signed their key? #1 failed. Do you know anybody who signed the Tor key? #2 failed. You can't properly verify it. Actually, GPG allows…

>Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain.

But it certainly doesn't mandate it. It's called the web of trust, not the chain of trust. You would never have such a chain of trust in real life so there is no reason to use PGP to create a model that doesn't make sense. Trust is normally quite shallow.

This is a generic rhetorical technique often used against flexible systems. The flexibility is used to create absurd straw men.

Re: PGP Marks 30th Anniversary

#34

Post by rjzzleep »

dale_glass wrote: post #28
globular-toast wrote: post #27

Earlier quoted context omitted.

I get that it's hard but it's hard because security is hard. What's the alternative? How else can you verify the signature on Tor browser?

By explicitly supporting this model. Recognize that in the modern usage model you often need to find a trust path to some completely random person you've never met, such as the maintainer of some random software program. And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to…

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 security aspect your system is not compromised, because the security of your base packages now depends on whether random key for third party is compromised. I.e. you can now install backdoored software because that package you wanted to add is compromised.

It's not really limited to linux repos though, imagine you install a driver on windows and it asks you to trust the signing key. That signing key can now be use to put random malicious software on your windows system.

Is there any reason why this metadata couldn't be added to something like pgp other than it requiring a lot of changes in the tooling?

Re: PGP Marks 30th Anniversary

#35

Post by southerntofu »

tialaramex wrote: post #30
makach wrote: post #14

Earlier quoted context omitted.

I don’t understand why people want to replace PGP. Of course we can improve the technology but the fact is that security is hard and requires interplay between the humans, processes and technology to work. It’s not enough to rely on just one of those pillars. There is an illusion in the world of IT that we can solve everything with technology. Maybe the reason why people don’t want or like PGP is because it needs str…

> 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 sig verification enabled as context menu entry in the file manager, same for encryption/decryption.

Basically, once you know what public/private keys are, you've got all you need for secure communications. Is that a bad thing? My only HUGE criticism of PGP is with the key servers. It's getting better now with WKD, OpenPGPCA, etc.. I'm really excited about the Sequoia project. From their blog/docs it appears all my criticisms of PGP are being addressed.

Re: PGP Marks 30th Anniversary

#36

Post by upofadown »

schoen wrote: post #6
waynesonfire wrote: post #3

such a great tool. It's not a serious security product unless you support PGP.

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.

Re: PGP Marks 30th Anniversary

#37

Post by dale_glass »

rjzzleep wrote: post #34
dale_glass wrote: post #28

Earlier quoted context omitted.

By explicitly supporting this model. Recognize that in the modern usage model you often need to find a trust path to some completely random person you've never met, such as the maintainer of some random software program. And that you need to support a "good enough" trust model for those cases. What do I mean by that? GPG has two separate things: signatures, and trust levels. When you sign somebody's key, GPG wants to…

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 its design. When something like a package manager uses GPG it calls the commandline tool and gives it a home directory and keyring somewhere.

What the world really needs is a GPG library. But not GPGme, which just calls the GPG binary and parses the output.

What is needed is one that dispenses with any ideas about how the end-user is supposed to work and just provides primitives to parse keys and messages, verify signatures, etc, and lets the user make decisions about whether to have a global list of keys, or per-repo keys, use a proper database like postgres, or even not store anything at all if all you need is to parse something. But alas, such things are still scarce, and the prevailing model is just hacking GPG into sort of doing a job it doesn't want to do.

There's also some weirdness on the package handling side. Apparently the modern way of doing things in Debian is that you don't sign a package, you sign the repository metadata instead. This may be motivated by the fact that GPG sucks and is slow (because you're calling a binary that loads libraries, parses config file and databases every time, etc), and calling GPG a thousand times during installation would be a significant slowdown.

Re: PGP Marks 30th Anniversary

#38

Post by dale_glass »

upofadown wrote: post #33
dale_glass wrote: post #26

Earlier quoted context omitted.

Give it a try, then. 0. GPG implicitly trusts your key. 1. GPG trusts keys you've signed. 2. GPG can also trust keys signed by people you trust. And that's where it ends, normally. So say you want to verify the signature on the Tor browser. So have you met the key holder directly and signed their key? #1 failed. Do you know anybody who signed the Tor key? #2 failed. You can't properly verify it. Actually, GPG allows…

>Actually, GPG allows the chain to extend for longer. You can verify a You -> Alice -> Bob -> Carol chain. But it certainly doesn't mandate it. It's called the web of trust, not the chain of trust. You would never have such a chain of trust in real life so there is no reason to use PGP to create a model that doesn't make sense. Trust is normally quite shallow. This is a generic rhetorical technique often used against…

The web can be seen as being made from many chains.

https://imgur.com/a/aTDcbtu

Those connections exist on keyservers already, GPG just doesn't have a comfortable way of finding them. For instance if you want to verify M's key, you have:

A -> B -> G -> M

A -> C -> H -> M

A -> D -> H -> M

A -> E -> I -> M

Using multiple paths should allow building some confidence into M's key.

The issue is that in the current model, A has the keys for B, C, D and E, and also M's key since they're trying to check their signature. But the rest of the web that is present on keyservers isn't easily reachable to the user.

Re: PGP Marks 30th Anniversary

#39

Post by scruffyherder »

tptacek wrote: post #2

It was on this day in 1991 that Pretty Good Privacy was uploaded to the Internet [... then...] a number of volunteer engineers came forward and we made many improvements. In September 1992 we released PGP 2.0 in ten foreign languages Fun fact: "We made many improvements" is doing an interesting lift in this paragraph, since PGP 1.0 shipped with a cipher of Zimmerman's own design, Bass-O-Matic, which lived up to its n…

https://unix.superglobalmegacorp.com/cgi-bin/cvsweb.cgi/pgp/...

I still use PGP 1.0 as all of the scanners that check for stuff can't recognize any of it, and it slides through. It's more of payload thing

Re: PGP Marks 30th Anniversary

#40

Post by JshWright »

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).

Post reply on HN