You've misunderstood a lot of Latacora's critique, but I think the most important point you've misunderstood is "negotiation."
> PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences.
> I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way.
"Negotiation" here doesn't mean a synchronous back-and-forth conversation. "Negotiation" in this case means, "if you're not sending me the most secure version, I'll just accept a somewhat less secure version."
PGP encrypted messages are "take it or leave it," but that doesn't mean that PGP doesn't do negotiation. Instead, it means that the PGP implementations decide how much insecurity to accept in favor of backwards compatibility.
Here, in the blog post linked at the top of this page, Sequoia moans that they can't bring themselves to turn off SHA-1 because Debian developers use it. They're accepting a less-secure implementation for backwards compatibility. It's right there in TFA.
I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default." Today, in 2020, that means "don't use GPG, and don't use Sequoia PGP" and I'm confident that it means "don't use PGP ever again," but you and I don't have to agree on that.
The fact that you can change the defaults to be more secure and less backwards compatible doesn't make PGP safe to use. It's dangerous by default. Don't use it, and don't advocate that others use it, until PGP is secure by default (in other words, never).
The other thing you've misunderstood is the problem with long-term keys.
> Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem.
No. Long-term public identifiers are indeed, desirable, but PGP's public identifiers are paired with secret keys. Tying your identity to your public key means that you can't change your secret key unless you change your public identifier as well. (In Signal terms, that would be like saying that you can't rotate your secret key without changing your public phone number, which would be absurd.)
>I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default."
SHA-1 is only broken for collisions. So far the best anyone has come up with for an attack on the SHA-1 in PGP is the mostly impractical Shambles attack on the PGP web of trust. This has been fixed in the implementations. When and if someone can demonstrate a practical attack using SHA-1 then more measures will be taken. This stuff is a little more complicated than just identifying particular hash methods in the list of features. This sort of thing is inherent in a long term encryption standard. You can't just randomly break things because you have a bad feeling about something.
>...but PGP's public identifiers are paired with secret keys.
In exactly the same way that, say, signal links its long term private identity key to public identifiers (your phone number). The problem is inherent in using public key cryptography for messaging. Most PGP implementations identify where that private key is kept and allow the user to protect it with a strong passphrase. That is opposed to how Signal depends on whatever security the device can provide to a key hidden somewhere on the device.
This is going to be my last reply to you, because this response is so confused that I think you're beyond help.
SHA-1 is used to validate long messages.
1. The sender, Alice, computes the (relatively short) SHA-1 hash H of a long message M
2. Alice cryptographically signs the hash H with a signature S
3. Bob can verify the whole message by verifying that the hash H is correctly signed, and then re-computing the SHA-1 of the entire message M, to verify that his computed hash matches Alice's hash H.
If Eve can compute a "SHA-1 collision," Eve can make a fake package X (like, say, malware instead of a real software package) that has the same hash H as the message M that Alice has signed. With that, Eve can trick Bob into accepting her malware by presenting Bob with her fake message X and Alice's real signature S. This works, because Alice really did sign hash H, and X and M have the same hash; their signatures have "collided" with catastrophic results.
To say that SHA-1 is "only broken for collisions" is to say that SHA-1 is broken for PGP.
Anyway, I'm done here. I hope we both agree that you deserve PGP.
You are describing a second preimage attack, ie, Eve finds a colliding message that matches an existing message and hash generated by Alice.
Not even MD5 is vulnerable to a second preimage attack.
The actual problem with SHA-1 is that Eve can generate two different messages with the same hash, one innocuous and one malicious. If Eve can get Alice to sign the innocuous message then Eve can use the signature to attack Bob using the malicious message.
Collisions are still catastrophic for most applications that use signatures, but it’s a wee bit harder to pull off an attack using pregenerated collisions than if you can find a second preimage. (Collision-based attacks need a signing oracle whereas second preimages do not.)
> I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default."
OK - lets see the implications of this:
> Today, in 2020, that means "don't use ...
Debian.
(As far as I can tell, the known SHA1 attacks have no practical impact on the security of using PGP to sign software updates, where the key management isn't reliant on web of trust... )
In practice, Debian downloads your packages over HTTPS from reliable trusted parties. HTTPS is the real, actual defense against package manipulation. The PGP signatures do nothing, but they don't really need to work; that's why nobody's bothered to fix them.
No, a default Debian installation downloads packages over plain HTTP. It doesn’t even support downloading packages over HTTPS unless you install the optional apt-transport-https package and edit your sources.list.
> PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences.
> I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way.
"Negotiation" here doesn't mean a synchronous back-and-forth conversation. "Negotiation" in this case means, "if you're not sending me the most secure version, I'll just accept a somewhat less secure version."
PGP encrypted messages are "take it or leave it," but that doesn't mean that PGP doesn't do negotiation. Instead, it means that the PGP implementations decide how much insecurity to accept in favor of backwards compatibility.
Here, in the blog post linked at the top of this page, Sequoia moans that they can't bring themselves to turn off SHA-1 because Debian developers use it. They're accepting a less-secure implementation for backwards compatibility. It's right there in TFA.
I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default." Today, in 2020, that means "don't use GPG, and don't use Sequoia PGP" and I'm confident that it means "don't use PGP ever again," but you and I don't have to agree on that.
The fact that you can change the defaults to be more secure and less backwards compatible doesn't make PGP safe to use. It's dangerous by default. Don't use it, and don't advocate that others use it, until PGP is secure by default (in other words, never).
The other thing you've misunderstood is the problem with long-term keys.
> Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem.
No. Long-term public identifiers are indeed, desirable, but PGP's public identifiers are paired with secret keys. Tying your identity to your public key means that you can't change your secret key unless you change your public identifier as well. (In Signal terms, that would be like saying that you can't rotate your secret key without changing your public phone number, which would be absurd.)