>The guarantee is worthless, HN could generate a new key with the same "Anonymous" name

Actually, it's not. That new key is an entirely different identity, and if you're struggling making the distinction between its "name" and its "identity", I'd argue you're not the target audience for PGP in the first place. There are 45,000 John Smiths in the world. Are you going to also argue that the concept of identity is thwarted by this fact? No. I believe this argument is made in bad faith.

>and use it to sign whatever they wanted to sign, and modify your comment to post that. I have no way of finding out whether this already happened or not.

Have you tried checking the signature? (hint: it's invalid - HackerNews manipulates the whitespace). Verifying signatures is incredibly easy in GnuPG. Would you like me to walk you through it?

>In general posting GPG signed messages in forums is of dubious utility, unless you're a celebrity of some sort and have a key with a decent amount of signatures on it.

On the contrary, it's quite useful. Public key cryptopgraphy allows you to be absolutely certain that a messages with a valid signature were signed by the holder of the private key. You don't need to know who that person is, but you can be certain that he holds the corollary private key. Your argument seems to be conflating _that_ with an argument on the metadata e.g. the authenticity of the public key itself, and that's an entirely different discussion orthogonal to the _utility_ of PGP.

By the way, GPG is just an implementation of the OpenPGP protocol. There's more than one implementation (RNP, sequoia, and OpenPGP.js, to name some for instance).

>Even then, GPG makes path finding extremely inconvenient, so even though I'm very well connected on the PGP WoT, it'd take me a serious amount of work to verify a signature

So? I never said it was easy. At the end of the day, you'd have to trust someone. PGP allows you to trust your web of friends. TLS requires you to trust some certificate authority. You're not really making any case against PGP here. Moreover, it's net even close to the use-case I argued.

For a journalist trying to report his findings in an unfriendly country, PGP is an excellent choice. For a client to secure communications with his lawyer, PGP is an excellent choice. And I'm still waiting for you to forge that signature to prove me wrong.

> Actually, it's not. That new key is an entirely different identity

Yes, which is just as worthless as the one you used, and from my point of view neither is better than the other.

> Have you tried checking the signature?

No, there's no point. It is worthless whether it verifies or not.

> On the contrary, it's quite useful. Public key cryptopgraphy allows you to be absolutely certain that a messages with a valid signature were signed by the holder of the private key.

Yes, and anyone can make a key, and they're all equally worthless unless there's a way for me to develop trust into one of them. And in this situation, there's none.

> So? I never said it was easy. At the end of the day, you'd have to trust someone.

In the situation you're providing here, there's no way for me to trust anyone, so your signature might as well not be there.

>Yes, which is just as worthless as the one you used

Wrong. One produces a valid signature, the other does not. I couldn't care less for your point of view - my interest align with my clients.

>No, there's no point. It is worthless whether it verifies or not.

An invalid signature indicates the message has been tampered with.

>they're all equally worthless unless there's a way for me to develop trust into one of them

Have you tried engaging with the parent post instead of talking past it? Attributing trust to some key an entirely orthogonal issue to the utility of a PKI protocol.

> In the situation you're providing here, there's no way for me to trust anyone, so your signature might as well not be there.

Sigh. First off, it tells you two things. (1) The message was signed by the holder of the private key if the signature is valid, and (2) the message has been tampered with if the signature is invalid. And you don't even need to trust the key to deduce these facts. Second, you still haven't forged that signature, so the fact that you're arguing past me instead of posting a valid & forged signature only proves my point. You can't do it.

> Wrong. One produces a valid signature, the other does not.

Wrong. They obviously wouldn't be stupid enough to just modify the message. They'd create their own key, and create a valid signature with that.

Then as an end-user, what it looks like to me is that you signed one message with key BDEC7256 and another with key 1E81885. No way for me to tell which one of those is the actual you, because I don't know who you are.

> An invalid signature indicates the message has been tampered with.

Which is why they'll make a valid signature with their own key.

If they're smart about it, they'll take your text, feed it to their key and silently rewrite your comment. I won't ever get to see your intended signature, only theirs.

And to make it extra-devious, they could arrange so that you see your original submitted version, but I see the fake one.

You kind of do know who they are, the first message was signed by the the first key, so you know that key is associated with that message and the author who sent that message. You don't know their name, but you know that this author, whatever their name may be, has control of that key pair.

As an end user, you see that the first message and second message were signed with different key pairs. Since you know that the first key is controlled by the author of the first message, you use a little bit of logic to deduce that the second message must not be authored by them, because it was not signed by the key pair that signed the first message.

So PGP did do it's job here IMO. The end user sees that there are two different authors here, which is what it was meant to do!

>No way for me to tell which one of those is the actual you, because I don't know who you are.

You don't really need to know this oftentimes, you just need to know that author A is in control of key pair A, and any messages that aren't signed with key pair A must not be authored by author A.

An example of this is trust on first use. You find some python library that colors terminal output, and it happens to be signed with key pair A. Going forward if you check the signature of the release artifacts, you know that it was authored by the same person that authored the original library you used, even if you don't actually know who they are.

Another example of this is TLS certificates. When creating a TLS certificate for your domain name, there is no cryptographic guarantee that the person who paid for the domain name is in control of the machine that is used to create the certificates associated with that domain name.

The only guarantee that is made, is that the person in control of the machine used to create the certs is the only person who has access to the private key material. So in practice this only proves that the machine you connect to when going to $url is controlled by the person who controlled the machine used to create the certs.

We can imagine person A buying $domain. They setup their DNS records to point to an IP address. If the DNS servers used by lets encrypt (for example) lie about the record, it is possible that an untrusted party is able to create a certificate for person A's $domain.