From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Gerwitz Newsgroups: gmane.emacs.devel Subject: Re: The SHA1 sunset Date: Tue, 05 Jan 2016 01:38:06 -0500 Message-ID: <87d1tg8rap.fsf@gnu.org> References: <83fuyead32.fsf@gnu.org> <87si2eayc5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1451975935 21305 80.91.229.3 (5 Jan 2016 06:38:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2016 06:38:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 05 07:38:48 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGLGY-0008Cn-V5 for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2016 07:38:47 +0100 Original-Received: from localhost ([::1]:48302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGLGY-0006c0-9B for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2016 01:38:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGLGI-0006bk-CP for emacs-devel@gnu.org; Tue, 05 Jan 2016 01:38:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGLGH-0005No-7o for emacs-devel@gnu.org; Tue, 05 Jan 2016 01:38:30 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGLGH-0005Nk-43; Tue, 05 Jan 2016 01:38:29 -0500 Original-Received: from localhost ([::1]:52638 helo=mikegerwitz-pc.gerwitz.local) by fencepost.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aGLGG-0002OT-K3; Tue, 05 Jan 2016 01:38:28 -0500 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 04 Jan 2016 23:14:06 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197647 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, Jan 04, 2016 at 23:14:06 +0100, Lars Magne Ingebrigtsen wrote: >> https://sites.google.com/site/itstheshappening/ > > I'm not sure why you're linking to that site? This was the recent paper describing the only SHA-1 collision which was directly addressed in Ballot 152 in determining whether to continue issuing SHA-1 certs through 2016: https://www.grc.com/sn/sn-529-notes.pdf > The question isn't whether the NSA are able to do SHA-1 collisions > (which I think everybody assumes that they can, albeit expensively), but > whether they can create certificates. The jury is out on that one, and > many people think that it's not a thing (yet) (with certificates with > the recommended entropy in serial numbers and dates). That's all good when those suggestions are actually implemented. > https://blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-certificate-t= han-it-is-to-find-a-sha-1-collision/ > >> Such a warning will not be bogus, and it would be a service to warn >> users even if others don't. > > It will almost certainly be bogus (now). Next year, perhaps not. SHA-1 is broken, which we can agree on. The proposal by CloudFlare to randomize serial numbers with at least 20 bits of entropy is a band aid atop of a broken cryptosystem. It should work for the meantime---for those CAs that actually implement it---but this is not an alternative to issuing SHA-2 certificates, and it won't help already issued certs. Personally, I prefer not to rely on bandages for my crypto. Since this mitigation attempt is dependent on CAs adopting it, that can only get _better_ with time. Considering SHA-1 to be broken (period), then presumably, a year from now, we'd only be in a better position if new SHA-1 certs are issued with a randomized serial number, given the relative increase in computing cost/power. We would be in a worse position for SHA-1 certs that haven't expired a year from now, since they'll be cheaper to exploit. CloudFlare also wrote about browser support for SHA-2: https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ =2D-=20 Mike Gerwitz Free Software Hacker | GNU Maintainer https://mikegerwitz.com FSF Member #5804 | GPG Key ID: 0x8EE30EAB --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWi2TOAAoJEPIruBWO4w6r2ScQAMWk6MCYzXxN9qA2bq2yG0CI +hmbscZZVR1k/QDXolEKuUNynx7MBtD3FosiLGkaV7bbop2ixGgbCZvFwXDwaOeS 8rzFDm4Z6V0Tx94KeF8ASD3wGbNPmMem8I7ZiWVRyIILayV+ujJuBh/WyQUH6+c6 4ftu1NEot0tctlDNUvZq2xjtcb09VGH8Ds/W/uIKzy9pPQuiaRR4+eFP7UptFkbG Jm7RCjRuSDBAirXMNOX52PUeVOubTynF3oZK/mHLU7CFhUOBUFXdkIaBnOrbTAXg BuJaC8/bHnaI1CzxS1KvQt+/SKV08R69Vi8LbguzZ5UrYIzI9KEu6X+Rz20gLzBF Q7K2ZFneVg/V2yL4QcQo1Vsg+znnKTg1xD+ZSMFM/Ac/OKS+EaEe2VReIUtP9OP/ c3m5yB91gUgoSXa7GGDBimBoDgMgoT+d3RaIui5tGt474ImbrHfLImGyFJ9x0PJz SObWEom3ZWihKs9KGZhNdQT3rMBBhx2KTevmXy8W54GvyXWKK0HYq0yn39aMiytF Qm88vpySrz8FPfNiE2MdG0ZMWkzkFVF2vqVFQruuTDpaMIQ3marlcS/s0kP1Yl9A 7cELjOmsV8iwNI66j4DB04oYVteiDzLjf8rCHtJyynL+/1IagYmpktoqM4NdX+Eq bZfAsfnEDE3i4gy6rw+j =YvdW -----END PGP SIGNATURE----- --=-=-=--