un-trusting MD5 in gpg
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed May 6 18:14:10 CEST 2009
On 05/06/2009 09:38 AM, Werner Koch wrote:
> This mixes trust with an algorithm, something we never did. With the
> same reasoning we could say: Don't trust a key with less than 1536 bits.
> The point here is that we can't take a decision for the signer - he
> might have valid reasons to use certain parameters which reflects the
> needs to fulfill a ertain goal.
I agree that we can't force a decision on the signer, and we can't force
a decision on the person interpreting the signature either. This option
would be mechanism to let signature-interpreters set policy like "i need
to be assured that the validation i'm seeing has a certain level of
This is why i framed it as "trust", because validating a signature does
indeed imply that you trust the algorithms behind that signature. If i
send you a message with a signature made over the simple 160-bit
checksum of the message (i know this isn't possible in OpenPGP -- it's a
hypothetical), you shouldn't trust that signature because you don't
trust the algorithm -- it's too easy to generate arbitrary content that
will match that signature.
And yes, we might also limit trust in keys by key length. Do you really
trust a signature made by a 512-bit RSA key?
> An option --disable-digest-algo better reflects what you want to do: I
> don't want to check signatures made using algorithm MD5. It is not a
> matter of trust but a decision by you and only you.
It's both, actually. it's a decision by me and only me that i do not
trust signatures using certain algorithmic parameters. I can even
specify this preference in a digest algorithms subpacket and broadcast
it to the world.
> We need to see whether we can use this option name without getting into
> problems with gpg2. I don't know right now. Another name might be
> something along the words --ignore-signatures-with.
I think --ignore-signatures-with makes more sense than
--disable-digest-algo simply because i can imagine wanting to add SHA1
to this list in a year and a half (for any work with US federal agencies
at least), but gnupg wouldn't even be able to calculate standard
fingerprints if SHA1 is completely ripped out.
> I can imagin adding a few new error codes; we already have:
> 43 GPG_ERR_WEAK_KEY Weak encryption key
> and new ones like:
> may be useful for further processing; not necessary to be dispalyed to a
> user but may be displayed as well in cases you describe.
This seems reasonable to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 890 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel