Release Signing Keys are Susceptible to Attack

Release Signing Keys are Susceptible to Attack

[R0b0t1]

After downloading and verifying the releases on
ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA
keys with SHA1 content digests. 1024 bit keys are considered to be
susceptible to realistic attacks, and SHA1 has been considered broken
for some time.

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf, p17
https://shattered.io/

SHA1 is weak enough that a team of researchers was able to mount a
realistic attack at no great cost.

As compilers and their utilities are a high value target I would
appreciate it if the maintainers move to more secure verification
schemes.

Respectfully,
     R0b0t1.

Re: Release Signing Keys are Susceptible to Attack

[Richard Biener]

On Thu, Aug 17, 2017 at 4:23 AM, R0b0t1 <r030t1@gmail.com> wrote:
> After downloading and verifying the releases on
> ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA
> keys with SHA1 content digests. 1024 bit keys are considered to be
> susceptible to realistic attacks, and SHA1 has been considered broken
> for some time.
>
> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf, p17
> https://shattered.io/
>
> SHA1 is weak enough that a team of researchers was able to mount a
> realistic attack at no great cost.

It looks like gpg2 uses SHA1 as digest algorithm by default.  I use
a 2048bit RSA for signing, that should be ok, no?

I suggest to report the issue to gnupg upstream (I'm using 2.0.24
with libgcrypt version 1.6.1).  It looks like the OpenPGP standard
mandates SHA1 here and using --digest-algo is stronly advised
against for interoperability reasons.

Richard.

> As compilers and their utilities are a high value target I would
> appreciate it if the maintainers move to more secure verification
> schemes.
>
> Respectfully,
>      R0b0t1.

Re: Release Signing Keys are Susceptible to Attack

[Paul.Koning]

> On Aug 17, 2017, at 4:39 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Thu, Aug 17, 2017 at 4:23 AM, R0b0t1 <r030t1@gmail.com> wrote:
>> After downloading and verifying the releases on
>> ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA
>> keys with SHA1 content digests. 1024 bit keys are considered to be
>> susceptible to realistic attacks, and SHA1 has been considered broken
>> for some time.
>> 
>> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf, p17
>> https://shattered.io/
>> 
>> SHA1 is weak enough that a team of researchers was able to mount a
>> realistic attack at no great cost.

I agree that 1024 bit RSA or DSA keys are not a good idea.  Since DSA is fixed at 1024 bits, that means DSA is obsolete.  Fortunately RSA can use any key size (if you wait for it), and 2048 is a good choice at the moment.

As for SHA1, your statement misses some critical detail.  There are two basic attacks on hash functions:

1. Construct a pair of messages that have the same hash.
2. Given message X, construct message Y different from X that has the same hash.

What has been demonstrated is #1.  But that doesn't break signatures of existing data -- only #2 would.  #2 is much harder and has not been demonstrated.  It is true that #1 is a significant weakness and indicates SHA1 is at risk, but there is no emergency relating to the use of SHA1 in digital signatures of data such as GCC kits.

> It looks like gpg2 uses SHA1 as digest algorithm by default.  I use
> a 2048bit RSA for signing, that should be ok, no?
> 
> I suggest to report the issue to gnupg upstream (I'm using 2.0.24
> with libgcrypt version 1.6.1).  It looks like the OpenPGP standard
> mandates SHA1 here and using --digest-algo is stronly advised
> against for interoperability reasons.

In spite of what I said above about SHA1, I would argue that warning is obsolete and the spec needs to be updated accordingly.  Current gpg clearly supports SHA-2 (as "sha256", "sha384" and "sha512") and it would make sense to use it.

If you want to be extra accommodating, you could publish signatures both with sha512 and with sha1, the latter not quite as strong but available for those who can't handle the newer algorithm.

	paul