Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one:

> Put a Signal number on your security page to receive bug bounty reports, not a PGP key.

We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phone number, something bad guys can definitely intercept if it's worth money to them, whereas a PGP key is just a public key and so you can't "intercept" it at all.

Now, Signal doesn't pretend this can't happen. It isn't a vulnerability in Signal, it's just a mistaken use case, this is not what Signal is for, go ask Moxie, "Hey Moxie, should I be giving out Signal numbers to secure tip-offs from random people so that nobody can intercept them?".

[ Somebody might think "Aha, they meant a _Safety number_ not a Signal number, that fixes everything right?". Bzzt. Signal's Safety Numbers are per-conversation, you can upload one to a web page if you want, and I can even think of really marginal scenarios where that's useful, but it doesn't provide a way to replace PGP's public keys ]

Somebody _could_ build a tool like Signal that had a persistent global public identity you can publish like a PGP key, but that is not what Signal is today.

The safety number is only partly per-conversation. If you compare safety numbers of different conversations, you'll discover that one half of them is always the same (which half that is changes depending on the conversation). This part is the fingerprint of your personal key.

The Signal blog states that "we designed the safety number format to be a sorted concatenation of two 30-digit individual numeric fingerprints." [1]

The way I understand it, you could simply share your part of the number on your website, but Moxie recommends against it, since this fingerprint changes between reinstalls.

[1] https://signal.org/blog/safety-number-updates/

Ah! Yes, I see. You'd need to figure out which is "your" half, which the application as it exists today doesn't help you to do since that's not what they're going for. The person initiating would need to send something to establish a conversation, like "Er, hi?" and then once that conversation exists they can verify the number shown on your web page matches half of the displayed safety number as expected and actually proceed.

It's clunky, but less so than I feared. I can actually imagine a person doing this. I mean, they won't, but like PGP this is something a person _could_ do if they were motivated and competent.

> persistent global public identity

Certificate Transparency could be reused/abused to host it. If, for example, you issued a cert for name <key>.contact.example.com and the tooling would check CT logs this could be a very powerful directory of contacts. Using CT monitors you could see if/when someone tampers with your domain name contact keys.

Mozilla is planning something similar for signing software: https://wiki.mozilla.org/Security/Binary_Transparency

This is basically the keybase.io log system. Although they too rely on PGP currently

Minus the network of independent logs as from what I remember only keybase.io runs their own log system. Although they do timestamp their Merkle tree roots into Bitcoin.

> > 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.

If the people from Signal start a conversation with you on the number you emailed, how do you know it’s actually them? Couldn’t it be a third party who intercepted your email?

You need to check their “safety number”, and now we’re back to the same idea as with PGP with web of trust and key sharing parties.

At some point you still need some kind of pub-key identity check if you don’t want to accidentally report your vulnerability to PRC instead.

Right, that's insecure. Maybe they should, you know, put a PGP key on their website? :)

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.

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.

Maybe all PGP users are morons, that's beside the point. My point is that if someone recommends something but doesn't follow their own recommendation, it is most likely that the recommendation is not well thought-out and can be ignored. In this case the recommendation to use Signal looks more like a refutation of the point brought up by PGP advocates and not something that anyone would actually do.

That’s a fair criticism and I will happily admit that’s what it should say: that all PGP users are morons. (Just kidding. You’re right re: bug bounty advice.)

> PGP theater

Hmm I don't see it as theater if you are unable to intercept and decrypt my message. Or forge my signature, etc.

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.

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.

Keybase.io supports this usecase

Reply on news.ycombinator.com