Slashdot Mirror

← Back to Stories (view on slashdot.org)

GnuPG Short ID Collision Has Occurred.

Posted by Unknown on from the 32-bits-ought-be-enough-for-anyone dept.

kfogel writes "Asheesh Laroia now has two GPG different keys with the same short ID (70096AD1) circulating on keyservers. One of them is an older 1024-bit DSA key, the other is a newer 4096-bit RSA key. Oops. Asheesh argues that GPG's short IDs are too short to be the default anymore — collisions are too easy to create: he did it on purpose and openly, but others could do it on purpose and secretly. More discussion (and a patch by dkg) are in this bug report."

9 of 110 comments (clear)

  1. Re:Let's face it by Anonymous Coward · · Score: 5, Insightful

    This is always true, but I think the main point here is that the defaults for GnuPG should not leave users vulnerable to imposters, especially since non-technical users may not realize it would even be an issue. Not everyone who makes the good decision to encrypt critical communications needs to know how it works.

  2. Above post is ignorant by robbak · · Score: 5, Informative

    Having done the most basic of research, I have found out that GNUpg short collisions are everyday events. Which makes me wonder what the point of the article was.....

    --
    Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
    1. Re:Above post is ignorant by gparent · · Score: 5, Funny

      Who the fuck do you think you are? Some of us are trying to get page hits by posting dumb stories on Slashdot here!

  3. So? by cloudmaster · · Score: 5, Informative

    Doesn't this just make it more annoying to do searches, since that key (really a "key name") isn't unique? The encryption/decryption/signing uses the whole big key, right? So this would strike me as a client problem whose impact is limited to being able to verify a signature or decrypt something encrypted. It's seemingly more a nuisance than an actual security problem; you shouldn't be trusting keys from unknown sources, and it's easy enough to revoke and reissue keys if you end up having a conflicting index.

    1. Re:So? by mgiuca · · Score: 5, Informative

      This. There is no problem here. The system is explicitly designed for the key id to be collidable. That is precisely why there is such a thing as a key fingerprint. The 32-bit key ID was never intended to be used to verify the validity of a key, merely for quickly identifying a key. The worst that can happen if two keys have the same ID is you are presented with two keys and have to look more closely to decide which one you want. The 180-bit fingerprint is used to verify a key and should be resistant to collisions for many many years.

      The only problem is if people are using key IDs for verification, in which case it is a user error. Therefore, the lesson of this story is that if you want to know whether a key matches the one you were expecting, you need to look at the whole fingerprint, NOT the key id. That is why when you sign someone's key, they give you the fingerprint, not just the id.

  4. Re:Let's face it by Anonymous Coward · · Score: 5, Insightful

    While I agree with the sentiment, what is possible for one person to know is wildly different for different people. While many of us here know a great deal about how a lot of technology works, many more people out there in the world just don't have the aptitude for it but know and understand all sorts of other things that we're not easily able to wrap our heads around.

  5. Re:Let's face it by Anonymous Coward · · Score: 5, Insightful

    Exactly! If I sell you a television, I don't expect users to know exactly how the television works. Most won't (especially children). The users of the television aren't specialists and aren't expected to know how it works, just how to use it.

    Those who specialize in making televisions are expected to know how it works and they're expected to deliver a product that works as expected. If it fails by design, the user doesn't care why, and it's the manufacturer's responsibility to make sure that their product works right.

    Likewise, it's the cryptographer's responsibility to deliver a secure product. The user mostly just needs to know how to use it correctly, but the cryptographer needs to work out the details of ensuring it's secure and saying, "here is your product, if you use it correctly, it's secure". and if it's not, then it's the cryptographer's job to fix that.

  6. Re:Let's face it by PPH · · Score: 5, Funny

    want to trust your mechanic with pulling your teeth out?

    Not again.

    --
    Have gnu, will travel.
  7. Re:This is an example of the strength of the proto by arth1 · · Score: 5, Insightful

    With 32-bit short keys, there is a time complexity of 2^32.

    That is only if you need to match one specific key.

    To just get a match between two 32-bit keys, you on average need to generate less than 80000 keys.

    But this is irrelevant, because the short ID isn't meant for positive authentication. It's a negative indicator - if the short key doesn't match, you don't need to check further, but if it does match, you do. Anyone who uses it for positive authentication deserves what they get.