Live data from Hacker News

The PGP Problem

latacora.micro.blog

51–60 of 369 posts

Re: The PGP Problem

#51
post #47
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…

Signal does a great job of supporting activists. That's basically its intentional product focus. Everything an open source proponent engineer might want to promote is secondary. The focus on activism and trying to deal with large actors definitely looks like #1. Everything else about their product is secondary to that. Signal's product focus has been at best un-encouraging to those who want to use it for anything els…

The byzantine packet format in PGP buys PGP nothing. There is no engineering reason for PGP to work that way, and PGP continues to suffer security issues because of it. I'm not arguing that PGP's original designers were incompetent, nor am I considering that argument, because it is totally uninteresting to me. What is relevant to me is the fact that today, that design is costly and bad. What more is there to think about? We should get rid of bad cryptography and replace it with good cryptography.

Re: The PGP Problem

#52
post #9

With the rapid churn of various chat clients it's hard to get something to stick, and I attempted to settle on XMPP+OMEMO (or OTR), since it's a protocol, not an "app" (eww). Not a single person I know still uses XMPP, and it's easier to just tell people "Download Signal". However, that requires a phone number, and is useless on a desktop if your phone's off. Despite being Free Software, it's fairly locked down. Secu…

to be fair i see signal as a alternative to a more secure texting means in presentation. of course this requires data so then there may be better alternatives for sure but what people are used too.

Re: The PGP Problem

#53
post #29
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 o…

aur is a system. you can of course make your own pkg's without sharing if you so chose.

responsibility is assumed when using others for any can submit there. that said there are signatures that can be verified ie available.

Re: The PGP Problem

#54
post #36
post #30

So the recommendation here is just to use Chat clients to communicate and forget about Email? Well that is hardly a good solution.

Yes! E-mail is fundamentally terribly positioned to do secure messaging. You can use e-mail, or you can have cryptography that works and have people use it, but you can't do both.

> E-mail is fundamentally terribly positioned to do secure messaging

E-mail is fundamentally a way to send a sequence of bytes somewhere (untrusted) so they can be picked up later by someone (trusted).

That’s also literally what Signal is built on so I think you’re overstating the difference.

Re: The PGP Problem

#55
post #34
post #32

The PGP problem isn't going away until there is a stable alternative. Under 'The Answer' there are several different, domain specific tools, with their different features and UIs and limitations. And the general case (encrypting files, or really that should be 'encrypting data'), "this really is a problem". If I want to replace my use of GnuPG on production with the things on that list, I need to write my own encrypt…

What specific problem are you trying to solve with PGP? If it's "encrypting files", why are you encrypting those files? What's the end goal? I acknowledge that there are cases that boil down to "encrypt a file", but believe they are a lot narrower than people assume they are.

We encrypt files:

- For offsite backups (disaster recovery), mirroring object stores and filesystems to cheap cloud storage.

- For encrypting secrets needed for maintaining IT systems (eg. all those shared passwords we never seem to be able to get rid of)

- For encrypting sensitive documentation for transfer (email attachment, shared via filesystem, shared via HTTP, shared via pastebin even)

Despite the awful UI, GnuPG does all of that in a standard way. We have tested disaster recovery with no more instructions than 'the files are in this S3 bucket'.

And the same tool is also useful for other tasks too: - public key distribution (needs care to do it securely, but functional) - commit signing, signed tags - package signing (per Debian)

We could use custom or multiple tools for all this, but a single tool to learn is a big advantage.

I think all use cases boil down to 'encrypt and/or sign a file' for one of the stages. In the article, 'talking to people', 'sending files', 'encrypting backups' are all really just 'encrypt/sign a file' followed by transmission. And some sort of keyring management is needed for usability. A tool that can pull keys from a repository and encrypt and/or sign a file to a standard format could be used to build all sorts of higher level tools. I imagine it would be quite possible to build this on top of libsodium, and if it gained mindshare, replace uses of GnuPG.

Re: The PGP Problem

#57
post #2

Really, all I did here was combine posts from Matthew Green, Filippo Valsorda, and George Tankersley into one post, and then talk to my partner LVH about it. So blame them. (also 'pvg, who said i should write this, and it's been nagging at me ever since)

What are your thoughts on Keybase as a secure Slack replacement?

Re: The PGP Problem

#58
post #36

Earlier quoted context omitted.

Yes! E-mail is fundamentally terribly positioned to do secure messaging. You can use e-mail, or you can have cryptography that works and have people use it, but you can't do both.

> E-mail is fundamentally terribly positioned to do secure messaging E-mail is fundamentally a way to send a sequence of bytes somewhere (untrusted) so they can be picked up later by someone (trusted). That’s also literally what Signal is built on so I think you’re overstating the difference.

Secure messaging is much more complex, but here’s a simple example of how that’s not true: TCP is bidirectional and email is one message, fire and forget. That immediately affects your ability to have forward and backward secrecy.

Re: The PGP Problem

#59
post #27

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

How do you turn on the online system?

Re: The PGP Problem

#60

So what do I use for encrypted messaging that can, like, replace email, then? Nobody seems to have provided any sort of satisfactory answer to this question. To be clear, an answer this has to not just be a secure way of sending messages, it also has to replicate the social affordances of email. E.g., things distinguishing how email is used from how text-messaging is used: 1. Email is potentially long-form. I sit dow…

Your point 1 especially speaks to me. Phone-based messaging in general isn't appropriate for the things I would most like to be kept private between me and a recipient, because those sorts of things can't be created on a phone. I've found PGP pretty good for making that happen, when I'm working with someone who a) uses PGP also and b) exercises some caution when using it. I haven't found an option that I can trust that will work for me.
Post reply on HN