>To avoid situation where someone generates a key with matching fingerprint...

That would be a preimage attack. No one knows how to do that with SHA-1. The best you could do would be to generate two different keypairs with the same fingerprint. That doesn't have any security implications. ... which is lucky, otherwise we would need unusably long fingerprints in the 256 bit range. Note that Signal effectively only has 100 bits per identity for the key fingerprint (they combine two identities to make the 60 decimal digit safety number). Using a birthday attack, generating a collision would only involve 2^50 operations, which is practically feasible.

>That would be a preimage attack.

My bad you're right with the terminology.

>The best you could do would be to generate two different keypairs with the same fingerprint. That doesn't have any security implications.

Except undetectable MITM attacks.

If you're encrypting with adversary's keys you think is valid because the attacker's keys' fingerprint matches with what you're expecting, you're going to have bad time. PGP's main use case is of course use of pinned long term keys, but nation states won't mind swapping values during TLS MITM access if they can. (Which is why E2EE is a thing.)

>Note that Signal effectively only has 100 bits per identity for the key fingerprint (they combine two identities to make the 60 decimal digit safety number)

Thanks I learned something new today.

"However, there are some more advanced use cases which per-conversation safety numbers might not provide for (such as Charlie verifying Alice’s fingerprint by checking with Bob), so we designed the safety number format to be a sorted concatenation of two 30-digit individual numeric fingerprints. Advanced users that would like to use fingerprints for more complex use cases can separate the two fingerprints from the safety number if necessary." https://signal.org/blog/safety-number-updates/

>Except undetectable MITM attacks.

OK, an attacker creates two keypairs with the same fingerprint. How specifically can that attacker use those colliding fingerprints to do a MITM attack? Anything I can think of involves revealing one of the private keys to someone else and having them use that private key as their own.

So it goes something like this

1. Attacker does TLS-MITM with rogue certificate to replace the the public key of user B on their website with the attacker's public key in real time

2. A gets the MITM attacker's public key instead.

3. A sends introductory message containing their public key.

4. MITM replaces A's public key with that of theirs with colliding fingerprint

5. MITM keeps reading messages in between.

Later when they meet and compare public key fingerprints, they won't detect the attack.

This makes a lot of assumptions, but it's merely complex in terms of number of steps. It's not computationally infeasible.

Also, a better attack is of course to just hack the endpoints and exfiltrate private keys and passively read all messages since PGP lacks forward secrecy, and since that's according to Snowden, been happening for over 10 years, it's probably the modern approach. Much less noisy.

MITM can't create a collision with a preexisting fingerprint. That would be a preimage attack. SHA-1 has not been broken in that way.