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

The PGP Problem

latacora.micro.blog

Post reply on HN
Print view View original

261–270 of 369 posts

Re: The PGP Problem

#261

Post by frutiger »

loup-vaillant wrote: post #231
frutiger wrote: post #213

Earlier quoted context omitted.

> you need three emails sent in rapid succession This is partially correct, but they do not need to be in rapid succession, and therefore Bob does not need to be online.

Alice's ephemeral private key must be kept as long as the whole handshake. Bob's is a bit shorter (between the last two messages). If the messages are slow to come, those ephemeral keys become less and less ephemeral, and could actually be stolen.

That is exactly correct. As I'm sure you know, it is Alice that retains her DH key not the email server or anyone else. As I said:

> If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely.

Signal does not depend on TCP being "bidirectional" as lvh said, it depends on participants being mostly online. This has nothing to do with the transport properties of e-mail vs. TCP.

Re: The PGP Problem

#262

Post by lvh »

nmadden wrote: post #251
tptacek wrote: post #219

Earlier quoted context omitted.

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 ki…

It sounds like you’re saying “and that’s why GPG is good”, but I read that as an argument why there’s a very high probability that one of those things is going to spill the beans, plaintext, in an email anyway.

Re: The PGP Problem

#263

Post by Natanael_L »

trabant00 wrote: post #87

The problem with the alternatives is they are product specific and baked into that product. I need a tool that is a separate layer that I can pipe into whatever product I want, be it files, email, chat, etc. Managing one set of identities is hard enough thank you very much and I also want to be able to switch the communication medium as needed. I use gnupg a lot and I'm certainly not very happy with it but I guess it…

The problem with this is that a tool that is too generic is itself dangerous, because it creates cross protocol attacks and confusion attacks like in https://efail.de for PGP email.

I think that a better approach is to bind identities from multiple purpose built cryptographic protocols.

Re: The PGP Problem

#264

Post by lvh »

taeric wrote: post #97

I don't understand why the use of Yubikeys for a non-exportable key isn't valid for folks that care about security. I mean, I get that not everyone will use it. The vast majority won't. However, the vast majority don't care about security at this level. So... what is the actual criticism? If you care about security, use the keys, right? That feels no different from "use some other product."

Sure. We do that for eg SSH. I don’t think it’s a great idea for our standard audience (startups) to implement.

Re: The PGP Problem

#265

Post by lvh »

frutiger wrote: post #261
loup-vaillant wrote: post #231

Earlier quoted context omitted.

Alice's ephemeral private key must be kept as long as the whole handshake. Bob's is a bit shorter (between the last two messages). If the messages are slow to come, those ephemeral keys become less and less ephemeral, and could actually be stolen.

That is exactly correct. As I'm sure you know, it is Alice that retains her DH key not the email server or anyone else. As I said: > If your security model relies on this difference then your security model is broken. It’s worth noting that Signal does NOT rely on this difference. It relies on participants being mostly online to permit frequent rekeys and not having to retain old keys indefinitely. Signal does not de…

“Bidirectional”. So peers can mostly talk to each other. Do you really want to die on that particular semantic hill? “These Ethernet frames have source and destination addresses eventually”?

Re: The PGP Problem

#266

Post by lvh »

tptacek wrote: post #248
dunkelheit wrote: post #245

Earlier quoted context omitted.

So even Latacora-advised startups use plain old email for bug bounties. Why then does the blog post recommend using Signal for that?

Because Signal would be better than the PGP theater. In practice, though, it doesn't matter; people are just going to use plain old email no matter what. They're not going to encrypt their findings to you.

Anecdote about said startups: in 2y of the one big bounty that did have a PGP key, we got one PGPd report, and it was “session takeover”: if I copy the cookie out of Burp and into a new Incognito session, I will be logged in. Bounty plz?

We also got super clever reports on that same bounty program. They just sent email.

Re: The PGP Problem

#267

Post by nmadden »

lvh wrote: post #262
nmadden wrote: post #251

Earlier quoted context omitted.

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 ki…

It sounds like you’re saying “and that’s why GPG is good”, but I read that as an argument why there’s a very high probability that one of those things is going to spill the beans, plaintext, in an email anyway.

No, I'm not defending PGP. Even without the automation, every PGP-encrypted email almost certainly results in a bunch of internal plaintext emails between employees that could easily accidentally cc the wrong person, etc. I'm just pointing out that the chances of replacing PGP with something genuinely secure for these kinds of use-cases are close to zero.

Re: The PGP Problem

#268

Post by Natanael_L »

NoGravitas wrote: post #257
Natanael_L wrote: post #253

Earlier quoted context omitted.

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?

Still under active development, nothing is really ready to use yet

Re: The PGP Problem

#269

Post by thepangolino »

PGP has one big problem:

Lack of a proper email infrastructure.

And by "email infrastructure", I mean proper support by most email clients contact apps.

The most basic use case seem to have never been addressed. You receive an email with a public key attached. Clicking on it should automatically open your contact app and ask if you want to add it to your contact's details. It should also be synchronizable with cardDAV or any other protocol of your choosing.

Re: The PGP Problem

#270

Post by mike_hearn »

Natanael_L wrote: post #232
mike_hearn wrote: post #228

Earlier quoted context omitted.

The CA system is strictly better than PGP for identity management in every respect. People often think it must be the opposite but this is essentially emotional reasoning: the Web of Trust feels decentralised, social, "webby" un"corporate", free, etc. All things that appeal to hobbyist geeks with socialist or libertarian leanings, who see encryption primarily through the activist lens of fighting governments / existi…

The CA system as set up today is a bit fragile and much too limited, though. If it was all we needed, everybody would be using S/MIME with signed certs. We need something more expressive than the current CA system, where you can make the choice to define your own trusted roots.

You can always edit the trust store to add or remove certs your local computer trusts. That's easy, there are even GUI tools available to do it. Heck on MacOS there's even a GUI wizard to create a local CA from scratch!

Nobody does it because the hard part of being a CA isn't the protocol part, it's convincing everyone that you're going to do a good job of issuing certificates. The WoT just ignores that problem entirely - and it's ultimately a social issue.

Post reply on HN