0

In this answer to GPG keys & SHA-1, there's the sentence:

However, since PGP keys are usually generated by their users, collision attacks are not a problem. They might conceivably be a problem in contexts where someone's key is generated by a third party, which might occur in some corporate environments or other large organizations.

I don't quite understand what this means. Is there a chance that you can generate a PGP key-pair that is the same as another existing key? Let's say that I don't have a particular target, I just want to assume someone else's identity as a laugh. What features of PGP key generation allow for this or prevent it?

Community
  • 1
Ohnana
  • 4,727
  • 2
  • 24
  • 39

1 Answers1

2

You have to distinguish between different kinds of attacks which are in scope of the hash sum algorithm chosen.

The post you referenced on one hand discusses collision attacks (against the whole SHA-1 based fingerprint).

However, since PGP keys are usually generated by their users, collision attacks are not a problem. They might conceivably be a problem in contexts where someone's key is generated by a third party, which might occur in some corporate environments or other large organizations.

A collision attack means finding two (or more) keys with the same fingerprint. As long as you create your key own your own, this is not an issue -- all you could do is create two keys with the same fingerprint, but they all belong to you anyway. If somebody else creates the key for you (for example, your company), they might be able to perform a collision attack and hand over one key with a given fingerprint while keeping another key with the same fingerprint -- but they might keep the private keys anyway, so there's no need to perform such sophisticated attacks.

A collision attack is simpler/faster to perform as a preimage attack, as you've got more control over the input and can find arbitrary two keys with matching fingerprint instead of having to find a collision for a given, fixed key.

Preimage attacks on SHA-1 could be a problem, if one only relies on the fingerprint. I can imagine various scenarios where an attacker could fool someone into accepting their key in place of another key. Alice downloads a key from somewhere and calls Bob to verify the fingerprint. An attacker organizes a keysigning party and substitutes their key for someone else's. Such attacks would be difficult, but feasible.

The result is that an attacker would have another key with the same fingerprint. Such a preimage attack would probably fool a bunch (if not most) of OpenPGP implementations in considering the wrong key.

A very relevant, but different attack is a collision attack on short key IDs. Short key IDs are 32 bit subsets of the fingerprint, and have a much too small value range. Those are actually a kind of preimage attacks, as they allow to collide key IDs against existing keys. The solution is not to use short key IDs at all.

Community
  • 1
Jens Erat
  • 23,816
  • 12
  • 75
  • 96
  • I see, that makes more sense. I guess what I was trying to get at is, could you generate two identical PGP public-private key pairs? Not just same same key ID or fingerprint, but the same exact key pair. – Ohnana Jan 12 '16 at 14:05
  • In theory yes, but the key space is _vast_ and the chances of doing so are very, very small. To do so, the fingerprint is not of relevance, but you'd be brute-forcing a private key matching the public key. – Jens Erat Jan 12 '16 at 14:14