Collision attack against long Key Ids

[Nadie]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260314/02facafe/attachment.sig>