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. _______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
