dshaw at jabberwocky.com
Mon May 18 04:20:16 CEST 2009
On May 17, 2009, at 8:36 PM, Daniel Kahn Gillmor wrote:
> This is a difficult tradeoff. Certifications themselves seem to be
> most likely place in the whole OpenPGP architecture where a keyholder
> will be signing material that is provided by a potential adversary.
> For example, if i meet Alice at a keysigning party, Alice provides me
> with a large chunk of fairly opaque data (her public key material,
> possible to use as a carrier for collision-specific perturbations?),
> or more User IDs (textual, more difficult to hide perturbations in),
> zero or more user attributes (JPEGs, which i think are relatively
> to perturb in ways that the signer can't be reasonably expected to
I would wager that IF an OpenPGP certification specific SHA-1
collision attack eventually appears, it would appear for photo IDs
first. There are a huge number of ways to twiddle bits in a JPEG (the
thing supports *comment fields* for crying out loud) in ways that
aren't visible in the image itself.
Incidentally, I don't sign photo IDs. It has nothing to do with this
theoretical attack - a photo ID does not make a statement that I am
willing to certify.
> I'm expected to issue one signature per UID (over key+uid) and per UAT
> (over key+uat), and the bitstream for each of these signatures is
> entirely specified by Alice. I can add subpackets to the hashing
> context *after* the material specified by Alice after i've signed it.
> But if Alice has found a collision, and her key+uat is "part A" of the
> collision, she can just append my provided subpackets to "part B" to
> preserve the digest collision.
> This makes me tend to concur with David Shaw we should stop making
> signatures over SHA-1 now:
I do think that people should stop issuing SHA-1 certifications, but
there are other considerations that need to be taken into account here
- not all clients can handle those signatures, and I don't think we're
at the point where defaults should be changed. It's not a black or
So, while I personally am issuing SHA-256 key certifications (and have
been for a while), I do not think that switching the default away from
SHA-1 is appropriate at this time. What is good for me is not
necessarily what is good for the whole world.
>> If the preference list is really a capability set, then
>> default-preference-list is fine as-is. We prefer to use SHA256, we
>> advertise we can use SHA256, there's no problem.
> If it's a capability list, it's currently incorrectly set because the
> OpenPGP client used by the keyholder (gpg, in this case), has many
> capabilities than those listed, including the longer digests in the
> SHA-2 family.
> If it's an ordered list of preferences, i think it's incorrectly set
> because we should be advertising our preference for stronger digests
> above SHA-1.
I see no conflict in the RFC: the list is ordered, and a random
selection is perfectly conformant. The list is ordered to give
implementations that want to do something useful with rankings
something to work with (and note that both of the "big two" of PGP and
GPG order their lists to varying degrees), but those implementations
that do not want to play with rankings are allowed to pick however
they like. It's similar, in a way, to the IETF meta-rule: be
conservative in what you generate, be liberal in what you accept.
So it's an ordered list of capabilities. Or perhaps a capability set
of preferences. ;-)
More information about the Gnupg-devel