From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89592 invoked by alias); 17 Aug 2017 13:09:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 88524 invoked by uid 89); 17 Aug 2017 13:09:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=demonstrated, H*i:sk:0FHp9yF, H*f:CAFiYyc1v, H*f:sk:0FHp9yF X-Spam-User: qpsmtpd, 2 recipients X-HELO: esa5.dell-outbound.iphmx.com Received: from Unknown (HELO esa5.dell-outbound.iphmx.com) (68.232.153.95) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Aug 2017 13:09:50 +0000 Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 08:02:00 -0500 From: Received: from ausxipps306.us.dell.com ([143.166.148.156]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 19:02:12 +0600 X-LoopCount0: from 10.0.2.213 X-DLP: DLP_GlobalPCIDSS To: CC: , , , Subject: Re: Release Signing Keys are Susceptible to Attack Date: Thu, 17 Aug 2017 13:09:00 -0000 Message-ID: <01A2706F-1696-4D2E-A896-27C157055FE2@dell.com> References: In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-ID: <642383C1BA0E754A9C47A3A240454856@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2017-08/txt/msg00037.txt.bz2 > On Aug 17, 2017, at 4:39 AM, Richard Biener = wrote: >=20 > On Thu, Aug 17, 2017 at 4:23 AM, R0b0t1 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. >>=20 >> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.= pdf, p17 >> https://shattered.io/ >>=20 >> 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 fi= xed 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 bas= ic 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 exi= sting data -- only #2 would. #2 is much harder and has not been demonstrat= ed. 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 sign= atures 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? >=20 > 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 obs= olete and the spec needs to be updated accordingly. Current gpg clearly su= pports SHA-2 (as "sha256", "sha384" and "sha512") and it would make sense t= o use it. If you want to be extra accommodating, you could publish signatures both wi= th sha512 and with sha1, the latter not quite as strong but available for t= hose who can't handle the newer algorithm. paul