Re: [openpgp] Followup on fingerprints

[Derek Atkins <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> writes:

> On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote:
>> That does not mean we have to support those applications. But it does
>> mean that we have to write a security consideration telling people we
>> have (1) considered the issue and that (2) either it isn't a problem
>> or you should do stuff that is going to be affected.
>
> Completely agreed that the security considerations should make a point
> of calling out what we think are legitimate and illegitimate uses of a
> fingerprint.
>
>> The concern here is that Mallet generates two keys that have the
>> fingerprints
>>
>> Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and .
>> Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2'
>>
>> Mallet joins an open source project which only takes the first 100 bits for
>> the fingerprint. He uploads the key for M1 to a keyserver.
>>
>> He then commits a large number of malicious patches using M2 for
>> authentication. These are all authenticated against his public key M2 when
>> he does the commit but the repository uses the key sent in band and does
>> not keep the key for later verification.
>>
>> At this point, any attempt to hold Mallet accountable is going to have to
>> rely on a human examining the logs and working out that Mallet must have
>> generated the malicious pair of keys. There is going to be no way to unwind
>> the thing automatically.

Why?  M1 and M2 are completely different fingerprints, unless you're
assuming that the x's are the same.  If the x's are the same that means
that Mallet has performed a 2^50 level attack to get 100 bits to match!
How long and how much energy does Mallet have to do this?  It's
certainly not something s/he is going to do over a long weekend!

> In either scenario, the committed code is done by Mallet, who was
> explicitly authorized by the system to commit code.  So the failure here
> is one of auditing, right?
>
> And i think the implementation recommendation that would solve the
> auditing problem here is "do not store fingerprints when you could be
> storing keys" -- right?
>
> Are there any other attacks we should be aware of due to failures of
> collision resistance in the fingerprint?

I'll note that this attack isn't due to a failure of collision
resistance in the fingerprint.  It's an attack due to the application
(on top of OpenPGP) truncating the fingerprint and throwing away extra
data.

Personally I don't see this as a bug in OpenPGP -- the data is there in
the OpenPGP data structures.  I see this as a bug in the application
built on top of OpenPGP that is throwing away data.

It's also an authorization issue; at some point someone needed to
authorize the M1 and M2 keys to commit, so someone *saw* the full
fingerprint at some point.  The fact that someone looked at the full
fingerprint and then threw away 60 bits just means they did a poor
design.

[snip]
>> Which you do probably depends on if you are using ECC or RSA. With RSA,
>> those 2048 bit keys start to bulk up...
>  [...]
>> It might sound a bit extreme, but since I started in the business, machines
>> have gotten roughly a million times faster and have a million times the
>> memory. 30 keypairs instead of one does not seem like a big deal.
>
> Following this logic, i think the answer is still that the endpoints
> should store the keys that they think are currently valid and not the
> fingerprints.  Fingerprints aren't for storage, they're either for
> discovery or for verification.

Or identification (e.g., the fingerprint/keyID of a signing key).  But
yes, the full key should be stored on the service when Mallet
registered.  There's yet another bug in the service (not OpenPGP) -- not
storing the keys of authorized users.

>           --dkg

-derek
-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant