Remix.run Logo
▲ Joel_Mckay 20 hours ago

Good ideas demand to be free. =3

▲tptacek 20 hours ago | parent [-]

There's a good idea in PGP, and a very bad one. The good idea --- and PGP genuinely deserves credit here --- is end-user, consumer-facing strong cryptography tools. That's now universally accepted and has been for decades. The bad idea is a tool with PGP's design, of "cryptographic jack-of-all-trades". PGP's design has aged like milk, and PGP itself is a security liability in almost every system that hosts it.

▲TheCondor 16 hours ago | parent | next [-]

PGP is special to me, I was a beta user when Phil uploaded it to some Colorado BBSes, way back when. He even made time to talk to teenage me about it on the phone.

What's crazy is when it was concieved, we didn't have trusted strong cryptographic primitives. We did have DES but it wasn't trusted. We did have some of these crazy ideas that we all would have "secrets" and you might put those secrets encrypted on a disk in a vault and you'd not even want the feds to get them. Now we have all sorts of much more vetted crypto primitives, but the idea of actual secrets you'd keep in cold storage is largely dead. You're spot on that modern use cases need different APIs and tools and specialized solutions.

▲BLKNSLVR 12 hours ago | parent [-]

Nice username.

https://hackyourmom.com/en/osvita/u-pamyat-pro-kevina-mitnik...

▲47282847 18 hours ago | parent | prev | next [-]

PGP the packet formats, PGP the tool(s), OpenPGP the specs, GnuPG the tool, GnuPG the library; or any of the other libraries? Web of Trust? All of it? None of the above?

Any time this topic comes up, here and elsewhere, I find that most discussions revolve around different understandings and misunderstandings what people mean when they say “PGP”, and rarely lead to anything beyond that. - no this is PGP no you’re wrong that is PGP and so on and on…

▲dale_glass 15 hours ago | parent | next [-]

Almost all of it, yes.

The packet format is awful, full of complexity, backwards compatibility mess, and serious security problems.

The spec is pretty awful in that a lot of the complexity is due to keeping compatibility with things that are a terrible idea. And also in that the general concept of a long lived key turned out to be a bad one.

The library or lack thereof IMO cripped PGP/GPG back when it was relevant. It's nigh impossible to make tooling for it, or it was until Sequoia showed up, which was extremely late. Things like doing stats on keys, or doing anything but what the binary wants to do were terribly painful until Sequoia.

The Web of Trust was an interesting idea for a while, but failed to transition to the modern internet.

By the time you fix all the things what remains looks nothing like PGP, so it amounts to "all of it is bad".

▲HoldOnAMinute 17 hours ago | parent | prev | next [-]

PGP: The flamethrower (kids love this one)

▲tptacek 18 hours ago | parent | prev | next [-]

All of those things are liabilities (I read them carefully and mentally checked them off one by one; I'm not just being rhetorical). I wrote a sibling comment going into more detail, but happy to answer questions.

▲tejohnso 14 hours ago | parent [-]

Well, gpg2 is an implementation of openpgp and is GnuPG the tool correct? So are you saying that when I `gpg2 --symmetric myfile` I'm doing something harmful rather than useful?

The expectation is that anybody who ends up with the encrypted copy would have an impossible time trying to decrypt it without, I don't know, millions of dollars worth of compute per year for decades to throw at it or something like that.

▲ an hour ago | parent [-]
[deleted]
▲woodruffw 18 hours ago | parent | prev [-]

Each of these bad in a different and exciting way, if your idea of exciting is reading mailing list threads.

(The idea of trust networks is not bad. But PGP’s implementation of them is bad.)

▲kstrauser 9 hours ago | parent [-]

What’s a better one? Are you thinking of something like Keybase?

▲m348e912 20 hours ago | parent | prev | next [-]

>PGP itself is a security liability in almost every system that hosts it.

Elaborate

▲tptacek 18 hours ago | parent | next [-]

Secure messaging is its own (increasingly well-defined) cryptographic problem. Group secure messaging is a distinct problem with its own cryptography. Backups are their own problem with their own constraints. Package signatures are their own problem.

There isn't one cryptosystem that does all these things. For messaging you want a carefully-defined notion of forward secrecy and post-compromise recovery, along with a careful decision about repudiation/non-repudation (1990s cryptography doctrine would suggest you just always want nonrepudiabilty, which turns out to be disastrous for privacy). For backup, you want deduplication and content addressing. For packages, you want transparency logs. You almost never want long-lived keys, but you often want identify binding.

PGP solves basically none of these problems, and offers instead a 1998 API (I'm not kidding, I thought about what year to pin it at) to basic cryptography primitives.

▲riedel 19 hours ago | parent | prev | next [-]

I guess the code base has really become a bit messy over time with all that parsing and different crypto algorithms. But the attack surface can be significantly reduced by using sq or even better stateless sqop.

▲some_furry 20 hours ago | parent | prev [-]

https://gpg.fail/

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

Recommendations: https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

We don't need to keep elaborating or re-litigating the same discussion. The PGP idea of "one tool to rule them all" is a terrible cryptography design, and the world is better off the sooner we stop trying to make it work.

▲upofadown 19 hours ago | parent [-]

Obligatory response to "The PGP Problem":

* https://articles.59.ca/doku.php?id=pgpfan:tpp

By what I saw, there wasn't really anything anyone would care about in https://gpg.fail/ . The GnuPG problem actually declined to respond to some of them.

▲ 19 hours ago | parent | next [-]
[deleted]
▲some_furry 19 hours ago | parent | prev [-]

[flagged]

▲tptacek 18 hours ago | parent [-]

Not helping.

▲voooduuuuu 19 hours ago | parent | prev | next [-]

Another thing is also that email itself was not designed with encryption in mind and because it is decentralized and backwards-compatible it is hard to enforce new rules (everyone should use PGP).

But PGP is useful if both sender and receiver agree to use PGP.

▲woodruffw 19 hours ago | parent [-]

> But PGP is useful if both sender and receiver agree to use PGP.

Anecdotally: this works until you add a third person who responds to the thread in plain text, with everything threaded beneath. Or when you do that by accident.

Applied cryptographers will tell you to use Signal or any other E2EE chat.

▲user3939382 19 hours ago | parent [-]

Signal isn’t owned by the users and independent of third parties the way PGP/GPG is so regardless of who will or won’t suggest a substitute it’s not.

▲woodruffw 18 hours ago | parent | next [-]

Why is “owned by the users” (whatever that means) the quality you’re testing cryptographic protocols against?

▲TFNA 17 hours ago | parent [-]

Signal's has buildable source code on the client side and all. However, the server code is closed source and the developers have made disquieting changes like uploading most users' contact lists to the server protected only by Intel SGX that is known to have vulnerabilities exploitable by a nation-scale actor.

▲woodruffw 17 hours ago | parent [-]

The point of E2EE is that you don't need to trust the server that you're talking through. A secure E2EE scheme is secure in the presence of an actively malicious server.

I think SGX is a red herring in this context. You can find it risky or not, but it's (1) not material to Signal's E2EE property, and (2) materially better than email, which sends all contact metadata in plaintext, regardless of whether you try and encrypt your message bodies. Bringing it up in this context seems like a category error.

▲cowlevel 14 hours ago | parent [-]

Is this accounting for the fact that they kill people based on metadata? More technically complex and unreliable protocols such as SimpleX attempt to also protect the metadata.

▲woodruffw 14 hours ago | parent [-]

Is what accounting for that? If you're worried about metadata leaks, you shouldn't be using email, full stop.

▲TFNA 5 hours ago | parent [-]

By "metadata" GP is presumably talking, as I was, about Signal uploading most users' contact lists to the server with weak protection.

▲akerl_ 3 hours ago | parent [-]

The point is that if the comparison point is PGP-encrypted email, which has no protection for any metadata and passes it on the wire in the clear, raising concerns about Signal’s metadata protections makes no sense.

▲TFNA 43 minutes ago | parent [-]

In the context of this whole big thread, the point is that neither infamously leaky PGP nor Signal keep metadata secure from nation-level actors.

▲gatlin 19 hours ago | parent | prev [-]

XMPP + omemo

▲SecretDreams 15 hours ago | parent | prev [-]

Can you elaborate? I know of commercial softwares that use it still where only the softer has the private key. Seems to work pretty well, but this is slightly out of my normal scope.