Re: [openpgp] Followup on fingerprints

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 6, 2015 at 12:07 PM, Vincent Breitmoser <[e-mail]>
wrote:

>
> On 6 Aug 2015, ianG wrote:
>
> > I'll bite: A person with two keys can sign a document that holds
> > him, then announce that it wasn't signed by him.
>
> Even though two keys exists with the same fingerprint, a signature made
> by one will only check out with that one, so creating ambiguous
> signatures is not that simple unless the attacker can also freely choose
> which one of the two keys will be used for verification.  Also keep in
> mind that certificates are made over public key material, not only
> fingerprints.
>
> > As proof, he can anonymously publish his other key...
>
> Yes, well.  He could also publish this key if it wasn't a collided one,
> or simply state that it was compromised.  Which leads us to the same old
> discussion about the usefulness of non-repudiation in practice.
>

Yes, I think we all understand the attack scope etc. pretty well at this
point. The question is what to do about it and I think we actually have a
practical consensus there as well.

Remember that I am a systems guy looking to build stuff on top of stuff
that is built on top of stuff. So for me the problem with a fingerprint
that might or might not be vulnerable to attack is that I have to evaluate
the security properties every time it is used and give reasons.

The use of MD5 in HTTP-DIGEST authentication is perfectly secure even with
the known flaws in MD5 etc. because the design intentionally uses a nested
construction to guard against extension attacks and the low entropy of
passwords means MD5 is never going to be the weakest link. But even so I
gave up explaining to people why that was so about ten years ago because it
just wasn't worth having the same argument again and again and again. Even
pointing out that the scheme was designed that way only to get round the
public key patents and there are much much better ways to do things does
not end the argument.


There are really two questions that the group needs to consider:

1) How many significant bits are necessary when printing a fingerprint on a
business card?

2) How many internal bits should be preserved?

The answer to 1 seems to be that 100 bits is the very lowest security level
that is acceptable and 150 bits should be more than sufficient for OpenPGP
uses.  The work factor for impersonation of a key holder being 2^100 and
2^150 respectively.

The answer to 2 is 'as many as you have available'. So even if there are
only 150 bits printed on the business card, programs should store either
the complete key parameters or the full digest output internally.

The security considerations should mention the birthday attack so that
reviewers know it has been considered and that the scope is limited to
allowing an attacker to create a pair of colliding keys for their own use.
The circumstances in which this could be exploited are very narrow and
would depend on the attacker being able to cause two different systems to
react differently to the same fingerprint.


For example, imagine a debit system in which the account is identified by a
fingerprint. Mallet creates a malicious keypair and ensures that the bank
of Ethel has one and the bank of Gax has the other. Mallet then creates a
money transfer order from his account at Ethel to his account at Gax which
he signs with the Gax key. As soon as Gax has cleared the funds, Mallet
transfers them out again (a few milliseconds later). When Gax tries to
perform settlement against Ethel at the end of the day, Ethel rejects the
transfer order because the signature doesn't verify.