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

The PGP problem (2019)

latacora.com

Post reply on HN
Print view View original

71–80 of 121 posts

Re: The PGP problem (2019)

#71

Post by defanor »

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availability issues. Almost nothing of that is available from Linux distributions' system repositories. Integration with other software and infrastructures is lacking. Dealing with multiple specialized tools is more of a headache even for expert users, especially when their added benefits do not make much sense given one's threat model. OpenPGP/GnuPG is more resilient and versatile than those, still usable where those are not.

I think such an article would seem more convincing, at least to me, if more sensible alternatives were proposed. Ideally without the advice to not encrypt email, without assumptions of continued availability of all the online services, of trust to certain third parties, and so on. Or it could be just a plain criticism without suggestions, which would still be somewhat informative.

Edit: there is another list of alternatives in a sibling comment, advising against (well, actually being quite hostile towards, and generally impolite) usage of what I had in mind as one of the possible more sensible alternatives: XMPP with OMEMO. Though upon skimming the criticism of that, I have not found it particularly convincing, either, and it just looks like some authors try to be particularly provocative/edgy.

Re: The PGP problem (2019)

#72

Post by woodruffw »

defanor wrote: post #71

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availab…

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter.

(Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)

But even this jumps ahead, given that the alternatives are not in fact proprietary. The list of open source tool alternatives has been the same for close to a decade now:

* For messaging/secure communication, use Signal. It’s open source.

* For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.

* For signing, use minisign, or Sigstore, or even ssh signing. All are open source.

Re: The PGP problem (2019)

#73

Post by woodruffw »

zimmerfrei wrote: post #70
SahAssar wrote: post #67

Earlier quoted context omitted.

But if you use the modern crypto stuff you loose interoperability, right? What is the point of keeping the cruft of the format if you still won't have compatability if you use the modern crypto? The article mentions this: > Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which…

When you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not). sequoia's defaults are reasonable as far as I remember. It's also bit strange that…

I think GP’s point isn’t that you don’t have the freedom to decide your own interoperability (you clearly do), but that the primary remaining benefit of PGP as an ecosystem is that interoperability. If you’re throwing that away, then there’s very little reason to shackle yourself to a larger design that the cryptographic community (more or less) unanimously agrees is dangerous and antiquated.

Re: The PGP problem (2019)

#74

Post by athrowaway3z »

woodruffw wrote: post #72
defanor wrote: post #71

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availab…

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter. (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one pro…

I have no clue how you reached the conclusion of calling it a red herring.

It matters - because Satan can disconnect the centralized nodes.

Re: The PGP problem (2019)

#75

Post by defanor »

woodruffw wrote: post #72
defanor wrote: post #71

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availab…

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter. (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one pro…

> security under a hostile setting

Yes, but security usually includes availability, and I mentioned a setting with service blocking above. Like that by a government.

> (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one prominent keyserver still limping around the Internet.)

How is it a red herring?

> For messaging/secure communication, use Signal. It’s open source.

From my point of view, it is complicated by Signal being blocked here (and it being centralized helped to establish such blocking easily), likely the phone number verification won't work here, it is not available without a phone, and it is not available from F-Droid repositories on top of that. Currently money transfers are also complicated, so finding some foreign service that would help to circumvent phone number verification is also complicated, and not something I would normally do even without that. All this Internet blocking is a new development here, but such availability issues due to centralization were anticipated for a long time, and are a major motivation behind federated or distributed systems. Some mail servers are also being blocked, but generally mail still works, and less of a pain to use.

> For file encryption, use age. It’s open source and has multiple mature implementations by well-regarded cryptographic engineers.

> For signing, use minisign, or Sigstore, or even ssh signing. All are open source.

These I find to be okay. Having to install them in addition to GnuPG that is usually already available, but that is to be expected; they are available at least from Debian repositories, so not something to complain about when considering alternatives. Likewise with the key sharing: not getting to reuse OpenPGP's PKI, and will have to replace that somehow, but it is not like it is used widely and consistently anyway, so perhaps not much of a loss in practice. Likewise with familiarity of the users: I would expect a little more friction with such tools, compared to GnuPG, but not much more. And I don't see actual usage downsides apart from those. Though the benefits also seem a bit uncertain, but generally that sounds like a switch that makes sense to consider.

Re: The PGP problem (2019)

#76

Post by Valodim »

woodruffw wrote: post #72
defanor wrote: post #71

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availab…

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter. (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one pro…

> given that there’s only one prominent keyserver still limping around the Internet

Hey, I take issue with that. keys.openpgp.org is just about the only thing running smoothly in the openpgp ecosystem :P

Re: The PGP problem (2019)

#77

Post by api »

PGP is horrible and way overly complicated but this article concludes by trading that for a long list of piecemeal solutions, some of which are cloud based and semi or fully proprietary.

PGP has hung on for a long time because it “works” and is a standard. The same can be said for Unix, which is not actually a great OS. A modern green field OS designed by experienced people with an eye to simplicity and consistency would almost certainly be better. But who’s going to use it?

Re: The PGP problem (2019)

#78

Post by jeltz »

defanor wrote: post #71

This OpenPGP and GnuPG criticism is brought up regularly here, but the proposed alternatives come with their own downsides: some of those are proprietary, some are centralized systems or depend on such. In addition to all the inconvenience, when such centralized systems are blocked, casual users switch to explicitly backdoored options. The advertised IMs are tied to phone numbers, introducing both privacy and availab…

What is your issue with Sequoia PGP? It is not proprietary, it is not centralized and it is much better than GunPG from what I can tell.

Re: The PGP problem (2019)

#79

Post by woodruffw »

Valodim wrote: post #76
woodruffw wrote: post #72

Earlier quoted context omitted.

One of the premises of modern cryptographic engineering is security under a hostile setting: it shouldn’t matter to a chat protocol that a server is proprietary or a network is centralized if the design itself is provably end-to-end encrypted. The server could be run by Satan and it wouldn’t matter. (Centralization itself is a red herring. One may as well claim that PGP is centralized, given that there’s only one pro…

> given that there’s only one prominent keyserver still limping around the Internet Hey, I take issue with that. keys.openpgp.org is just about the only thing running smoothly in the openpgp ecosystem :P

Sorry, that was an unduly inflammatory framing from me. You’re right that keys.openpgp.org runs smoothly, particularly in contrast to the previous generation of SKS hosts. I don’t think it comes close to meeting the definition of a decentralized identity distribution system, however.

Re: The PGP problem (2019)

#80

Post by zimmerfrei »

woodruffw wrote: post #73
zimmerfrei wrote: post #70

Earlier quoted context omitted.

When you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not). sequoia's defaults are reasonable as far as I remember. It's also bit strange that…

I think GP’s point isn’t that you don’t have the freedom to decide your own interoperability (you clearly do), but that the primary remaining benefit of PGP as an ecosystem is that interoperability. If you’re throwing that away, then there’s very little reason to shackle yourself to a larger design that the cryptographic community (more or less) unanimously agrees is dangerous and antiquated.

It is not a coincidence that most of the various proposed alternatives to PGP (signal, wormhole, age, minisign, etc) are led by a single golden implementation and neither support nor promote community-driven specifications (e.g., at the IETF).

Over the decades, PGP has already transitioned out of old key formats or old crypto. None of us is expecting to receive messages encrypted with BassOmatic (the original encryption algorithm by Zimmermann) I assume? The process has been slow, arguably way slower than it should have after the advancements in attacks in the past 15 years (and that is exactly the crux behind the schism librepgp/opengpgp). Nonetheless, here we are, pointing at the current gpg as "the" interoperable (yet flawed) standard.

In this age, when implementations are expected (sometimes by law) to be ready to update more quickly, the introduction of new crypto can take into account adoption rates and the specific context one operates in. And still, that happens within the boundaries of a reasonably interoperable protocol.

TLS 1.3 is a case in point - from certain points of view, it has been a total revolution and break with the past. But from many others, it is still remarkably similar to the previous TLS as before, lots of concepts are reused, and it can be deemed as an iteration of the same standard. Nobody is questioning its level of interoperability, and nobody is shocked by the fact that older clients can't connect to a TLS 1.3-only server.

Post reply on HN