7 ms·

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

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

dale_glass 3y ago
> 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.
- chlorion 3y ago
  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.

dale_glass 3y ago

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

chlorion 3y ago
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.