Live data from Hacker News

The PGP Problem

latacora.micro.blog

251–260 of 369 posts

Re: The PGP Problem

#251

Earlier quoted context omitted.

> > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. Does anyone actually do this? Even Signal developers themselves don't! (see https://support.signal.org/hc/en-us/articles/360007320791-Ho... ). Instead there is a plain old email address where you are supposed to send your Signal number so that you can chat.

We manage bug bounties for a bunch of different startups, and I can count on zero fingers the number of times I've had to use PGP in the past year for that. In practice, people just send bugs with plain 'ol email.

I used to get about 1 or 2 PGP-encrypted emails with security bug reports per year when I managed this for my employer. There's a dedicated team that receives security reports now, with email feeding into an automated ticketing system with automatic acknowledgements, reminders, spam filters, PagerDuty alerts, etc. There's a huge amount of tooling and workflow built around email, with a lot of integrations into all kinds of enterprise software. Often the only sane way to trigger all this stuff is to send an email.

So I think the result of removing PGP will be even more plain 'ol email than anything else.

Re: The PGP Problem

#252
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…

I'm running a "beta test" of sorts of XMPP+OMEMA with non-technical people in my circles, and while Conversations (Android) and Monal (iOS) are getting there, there are still functionality and compatibility gaps. Gajim is a usable client for desktops, but it's certainly picky about which users it is friendly with (that is, I can't recommend it to non-technical folks). On the other hand "it uses IDs like email" is a c…

As far as usable desktop XMPP+OMEMO clients go, Dino is much friendlier to non-technical users, but paradoxically, it's only available on Unix-like OSes. It runs on WSL and is probably buildable for X on MacOS, but by that point, you've lost non-technical users in both cases.

Re: The PGP Problem

#253

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…

I strongly agree with this; email is not instant messaging, and there is not yet any secure replacement for email. We need a modern design for a successor protocol to email, and no one is working on it because they prefer instant messaging (or think other people do).

I think we're more likely to "accidentally" end up there via E2EE document collaboration tools that are in development now.

One day, a while after they become usable and common, people will just realize they've been sharing documents E2EE in place of sending email, and they'll be using it for basically everything that matters.

It would be a proper restart and allow for significant improvements in usability and security and everything else.

Re: The PGP Problem

#254
post #78

Earlier quoted context omitted.

How does one list a public PGP key, is there a verified central listing service?

One of the major features of PGP is that you don't have to rely on -- trust -- a "verified central listing service". The "Web of Trust" [0] fills that role: > As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of…

The problem is nobody uses this right

Re: The PGP Problem

#255
post #162

> there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography SSL was designed in 1994 but it has been properly maintained and today no-one argues that TLS should be replaced by noise/strobe etc. OpenPGP's problem no 1. is that there are no parties using it on a wider scale and interested in improving it.

SSL 2.0 was overhauled (by cryptographic experts) to create TLS, and, after something like 10 years of effort, support for SSL 2.0 was scourged off the Internet. And still, we had the DROWN attack a couple years ago, which manages to exploit cross-protocol attacks between SSL 2.0 and TLS on different servers . In the last few years, we got TLS 1.3, which again made significant, breaking changes with the previous vers…

> That's what didn't happen with PGP.

Yes. And your software suggestions are excellent for 2019. I just wonder whether in 10 years it would be better to have a standard improved/developed, instead of a collection of one-vendor tools where the code is specification. That said I don't have high hopes for PGP given its maintenance problem.

Thanks for writing on the subject, even if the subject should already be clear to majority of technical people!

Re: The PGP Problem

#256
post #164

> Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key. Interestingly some protocols such as roughtime use the same tactic…

If you squint enough, that’s how CAs work too.

Re: The PGP Problem

#257

Earlier quoted context omitted.

I strongly agree with this; email is not instant messaging, and there is not yet any secure replacement for email. We need a modern design for a successor protocol to email, and no one is working on it because they prefer instant messaging (or think other people do).

I think we're more likely to "accidentally" end up there via E2EE document collaboration tools that are in development now. One day, a while after they become usable and common, people will just realize they've been sharing documents E2EE in place of sending email, and they'll be using it for basically everything that matters. It would be a proper restart and allow for significant improvements in usability and securi…

Can you point me to examples of such tools?

Re: The PGP Problem

#258

So the suggested solution for more secure email is just to give up on the concept of email entirely? Anything that does not do perfect forward secrecy is just pointless so there is no point in trying to keep significant discussions to refer to later. We are expected to return to a sort of virtual pre-writing stage. This is not really helpful. For all its shortcomings, PGP is pretty much all we have. If used in a stra…

I know right - they are all recommending Signal, Wire, WhatsApp, etc., but these aren't alternatives. They are all centralized, controlled by a single entity even if the underlying protocols are open. And you're right, they are instant messaging - ie. alternatives to Messenger, Hangouts, etc. We need a modern email replacement that is decentralized, federated, et al. Something that keeps all the modern cryptographers…

As I've mentioned in another thread, I think we're more likely to get there via the route of E2EE documents collaboration tools. Something that cleanly breaks away from the email model, and adds enough value to make the switch worth the effort.

Re: The PGP Problem

#259

Something I'm curious about - if GPG uses such old/not-recommended encryption standards, is it still secure in the sense that if I gpg encryption something and post it online, a three letter agency will be still unable to decrypt it?

There are two ways that breaks:

- your key won’t be private forever but future compromise does mean past disclosure

- on long enough timescales if said TLAs can mount offline attacks against it.

So, maybe? But it’s definitely the safest way to do it, most of GPGs problems are unforced interaction errors.

Re: The PGP Problem

#260

PGP was a game changer when it was introduced and the idea of a chain of trust was neat. Unfortunately, its implementations are difficult to use, it was never directly supported by operating systems or major applications, and its crypto agility makes it impossible to write minimal implementations. I wrote and use Piknik for small files transfer (especially with the Visual Studio extension), Encpipe for file encryptio…

Has there been any effort to integrate minisign into git?
Post reply on HN