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. Let's face it by 2.7182 · · Score: 4, Insightful

    When you've got nothing on the line, you're not going to be as careful about cryptography as someone who does.

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

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

    4. Re:Let's face it by arth1 · · Score: 4, Insightful

      If they use it, it's part of a package that uses it, and they will never see the short ID.
      And anyone who uses it for real protection would never base their acceptance of a key on the short ID anyhow.

      So the submission is, while technically correct, likely of little to no consequence.

      It's a bit like saying that dirvers' licenses now are insecure as IDs because they contain a line stating the eye colour, and it has been found that by wearing coloured contacts, one can make a false positive ID. The observation is correct, but the conclusion is not.

      tl;dr: The short ID is one of many factors to assist in verifying a key. It should never be used alone, and isn't "broken" because multiple keys can match it.

  2. A collision in a 32 bit key space? Unpossible! by zill · · Score: 4, Insightful
    I'm shocked, shocked to find collisions going on in here!

    There is the remote chance that several keys will have the same "short" Key ID. The "long" Key ID decreases the risk of a collision, but can be more unwieldy to use.

    Considering that certain versions of the GnuPG man page actually explicitly cover this, I'd say this is a non-story. Just use the long key ID if you're worried.

    1. Re:A collision in a 32 bit key space? Unpossible! by Anonymous Coward · · Score: 3, Insightful

      The a commenter in the bug report explains the importance of this:

      Even when you give gpg a long key-id (or even the full fingerprint) the program (which has no "plans for a new release") truncates and uses the short key-id.

      So even if you say "gpg, look up this [long key-id]" it truncates silently.

      See an example here:
      https://bugs.g10code.com/gnupg/msg4026

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

  4. Which surprises you most? by dfay · · Score: 4, Insightful

    Which surprises you most?

    1. That GPG developers and users have ignored the well-known problem (in security circles) of the Birthday Paradox?
      - or -
    2. That there are > ~45k GPG users such that this even is more likely than not to occur. ;)

    Seriously though, a 1 in 65536 chance of a collision doesn't seem acceptable to me.