On Wed 2015-07-29 10:31:22 -0400, Phillip Hallam-Baker wrote:
OK one thing from the meeting I forgot to mention, the security
considerations have to address the use of a birthday attack by someone
generating keys.
I'll echo Vincent here and ask what specific attack you're concerned
about.
My current understanding of OpenPGP fingerprints is that we do not need
collision resistance as a property of the fingerprint mechanism.
We've discussed the possibility of birthday attacks against fingerprints
by someone generating keys before, and i've yet to hear a concrete
description of any attack that this permits. If there is such an
attack, then we need to be really concerned about it now, since the
current fingerprinting mechanism (SHA-1) is likely subject to a birthday
attack by a motivated and well-financed attacker.
If we are doing ECC, it is quite practical for someone to generate 2^50
keys and then pick the two that match in the first 100 bits. This can then
be used for attacks, particularly if the keys are not enrolled in some sort
of blockchain.
if we want to discuss append-only logs of key material, i'd be happy to
see that discussion happen formally in a separate thread, or over in the
certificate transparency WG where that sort of thing is already under
way. I think dragging blockchains into a discussion on OpenPGP
fingerprint mechanisms is a distraction.
The other bit I left out is the idea of compression. The idea here being
that the person generating the key looks for a fingerprint that has 0s for
the first n bits. Then the fingerprint starts with a version number that
says 'the first 32 bits are 0s' or whatever.
[...]
My preference is to just truncate and use the inferred length. That allows
us to minimize the amount of data we need to put in front of the user
without compromising security.
These two proposals seem incompatible to me. If you give me a
fingerprint that is shorter than the expected length, and both
mechanisms are available, how am i supposed to know whether you've given
me a truncated fingerprint or a "compressed" fingerprint?
Lets say that in 2020 Alice meets Bob and they exchange their fingerprints
via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the
corresponding profile which has Bob's key and full 512 bit fingerprint. The
phone then stores the big fingerprint for Bob in her contacts directory.
Wouldn't the phone just store the key itself instead of the fingerprint?
Why does the fingerprint matter in this scenario after the initial
introduction?
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp