Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> 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
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp