Thank you all.

I have the feeling that attacks against PGP/GNUPG are being launched based on alleged weaknesses that are later proven not to exist. I see people recommending against using it based on these assumptions.

Best regards

El 11/3/26 a las 20:37, Bruce Walzer escribió:
On Wed, Mar 11, 2026 at 05:57:04PM +0100, Nombre y Apellidos via Gnupg-users 
wrote:
Hello

I'm a GPG user for a while, but I don't have any technical knowledge of
cryptography, only basic understanding of the subject. I mention this to
try and excuse my lack of knowledge.

I see a blog post about collisions in key Id's in this blog:
https://soatok.blog/2026/01/07/practical-collision-attack-against-long-key-ids-in-pgp/

The blog post was ultimately in response to a comment of mine on
news.ycombinator.com. You can dig through the comments for context if
you like:

* https://news.ycombinator.com/item?id=46403200

The following is my reply to the blog post from there. I never received
any further reply.

Sorry that my, perhaps, poor wording caused you to waste your time
producing colliding 64 bit PGP key IDs. I should have used the term
"threat model". We were discussing how long key fingerprints should
be. My point was that even though 64 bit key IDs are trivially
collidable there did not seem to be any practical attacks based on
that. So you in a sense provided support for my argument. :) So we
can skip directly to your proposed attack...

I have to admit that I don't actually understand it. First the
attacker gets some kernel devs to sign key1 of the two keys with
colliding key IDs. Why? How does that help the attacker? Then I am
guessing that the attacker signs some software with key1. Are the
signatures important here? Then the attacker signs the malicious
software with key2? Key2 isn't signed by any developers so if that
was important the attack fails. If it wasn't important then why
mention it?

Could you please provide a more detailed description of the attack?
It seems to me that the sort of attack you are describing would
require some trusted third party to trick. Like a TLS certifying
authority for example.


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to