laying groundwork for an eventual migration away from SHA1 with gpg

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed May 6 16:30:37 CEST 2009


On 05/06/2009 09:45 AM, Werner Koch wrote:
> Using a 4k RSA key for an automated signing keys or for role purposes is
> not a good idea at all: It makes the user believe that the archive is
> secure at that level; but that is clearly not the case.  As usual one
> need to look at the weakest link and here we can find a lot of them: A
> hijacked developers box (Out of 10000 developers there is for sure at
> least one folk not protecting his box with all required due diligence),
> a ssh key floating around at several places, the upstream sources, the
> protection of all the boxes passed while uploading a package and so on.

I agree with your assessment -- the key for automated signing of the
debian archive is almost certainly *not* the weakest link in the chain.

On the other hand, if the ftp-masters make a probabilistic assessment of
the situation and decide that the archive itself is most likely "secure
at the level of DSA-768" because of the vulnerabilities you describe,
does that mean that they should sign the archive with a DSA-768 key?

I think the reason to have the archive signing keys be beefy is so that
the archive key *itself* does not end up being the weakest link, or even
a tempting point of attack.

I agree with you that it might give some users the wrong impression
about the security of the archive, but i'm not sure what a better
alternative is.  Certainly the explicit inclusion of the term
"automatic" in the user ID is helpful in getting users to understand the
lack of human judgment involved in the creation of the relevant signatures.

Do you have any suggestions for what to change?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090506/3c60c535/attachment.pgp>


More information about the Gnupg-devel mailing list