Collision attack against long Key Ids

[Bruce Walzer]

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.