From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 645161396D9 for ; Sat, 28 Oct 2017 04:55:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B16372BC070; Sat, 28 Oct 2017 04:54:54 +0000 (UTC) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 52CE8E0C47 for ; Sat, 28 Oct 2017 04:54:54 +0000 (UTC) Received: by mail-yw0-x242.google.com with SMTP id k11so7417532ywh.1 for ; Fri, 27 Oct 2017 21:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=ej5r7+EAFVEsAoWnS8ZIquNsrDyrodlcvK/H9tRobNs=; b=VEyuc02XZe9r+buWzWzZ4aj7HyfFRS40p9vhRXoJ8EHyGFVTo/P2PFzRRBBtkxwTsq rtYHebUJh5ep84Sa7ZyfkhMfpFv2Zc2iSbmFshpNwYdvr+LhmOESCcqZ7dZrQthxtQ9m rkLE+CW58pePbE9KgMGc2of0n/lLOlDI2s2NULY+2roj1Vllk1NM27Sxtx7ZpD9ohG95 8FCpmi2k2COmAnPXb4bhQNp6aBpl8izo34z6ojFYQc0gfPAiiIizpYFVzKPLJdwEY4QB 7Qe67h9hzIq5zmU9IGz0tGA/qUqNohQoWL+w3HBepaWcXBQ5IqC/saPMtR4VBJGQWd1w BiCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=ej5r7+EAFVEsAoWnS8ZIquNsrDyrodlcvK/H9tRobNs=; b=TNsxh3Z7P1SdEDEofJ1kEQ1ZotlQEpCNHnqp3E5cSnVegSewYPCEBhL37eWqYY+B6q 4pVUuOeq6NOgO8lBbhTfPlAAgQmkSHDvljvGJGJonWQcjUbopiPyQeHW4IDAcqgfio8M TAHAlOZfD1xmZzT0ViWpMY+y4dCPAXVDs5BIl8nEsgYwKyGCJsOXFmh/Fp035YGASjDZ 5moAbYakruNNqukaSMrFONjLNQWA5lIkdmAEg0GqKKihdImxmuVTGcobAbXIeovaGmhz 9NArawWmWpjuzxCHfF/xnmc0pINDUcwxCWCMYDVz1FuiBjzEqAhk5ZA6Ha2wq+qVPFXq Qg9Q== X-Gm-Message-State: AMCzsaVKacxxhqOqgrtjECZrJVDs8GvMxS3/JfO+xn8ivFVxOXSLDpoD ZBjctU3nnbaqECPXZy08PIEP4FaIU1A+2DUtfnrVHg== X-Google-Smtp-Source: ABhQp+SP7sPhE8F5NFeL3tP5//dQ+8umxrmZpF+DOytBUq8bvB63JYmz7VelYlcYbV2NjjRnacUsJ1MTbVVP4ANxuRg= X-Received: by 10.129.145.68 with SMTP id i65mr1764788ywg.259.1509166492901; Fri, 27 Oct 2017 21:54:52 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.129.153.84 with HTTP; Fri, 27 Oct 2017 21:54:52 -0700 (PDT) In-Reply-To: References: <1508440120.19870.14.camel@gentoo.org> <26AE424C-19DF-4059-A7DE-8ED6D605FF2C@gentoo.org> <1508817879.1688.6.camel@gentoo.org> <1508818272.1688.7.camel@gentoo.org> <73ce6032-2c65-676c-cf5c-233810555df5@gentoo.org> <1508851547.25623.0.camel@gentoo.org> <64bba51d-5ba1-c1cc-44e7-68df468669e7@allanwegan.de> From: R0b0t1 Date: Fri, 27 Oct 2017 23:54:52 -0500 Message-ID: Subject: Re: [gentoo-dev] Manifest2 hashes, take n+1-th: one hash to decide them all To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 81686875-070a-4a17-b43b-7314aaee3653 X-Archives-Hash: dfc8c3bc69d67f54250b6f02c31d7628 On Tue, Oct 24, 2017 at 9:40 PM, Robin H. Johnson wrot= e: > On Tue, Oct 24, 2017 at 11:33:39PM +0200, Allan Wegan wrote: >> >> That is currently the case with portage, but not an inevitable >> >> consequence of having 3 hash functions in the Manifest. Portage could >> >> be made to check only one or two of them (even by default), giving >> >> the tie-breaking ability to those who need it, and speeding up things >> >> for those who don't. >> > No, it can't. The specification (GLEP 59) requires it to check all >> > hashes. >> >> Of course it can: The code of the specification just has to be changed >> before changing the code of portage. The question is not whether it is >> possible to make portage skip hash verification - but whether it is a >> good idea to make it do that... >> >> I would not mind as long as the default is to always check all the >> hashes and the option to disable it is properly named (like >> "--disable-hash-verification" or something similar) and documented. > At that point, and this is a serious proposal: > The package manager shall decide which hashes to check, but is required > to check at least one hash. The choice may be 'fastest', 'most secure', > or any local factor. > > For local values of 'most secure' or 'fastest'. > > I wrote GLEP59, and specified at the time that all hashes should be > checked, based on prior experience with hash implementation problems. > > Skipping them entirely is a bad idea, but only checking one of them is a > reasonable suggestion. > The talk on gentoo-dev related to the security of hash functions still has me confused as to why anyone would want to remove the alternatives. Arguably this gives the setup most of its security. I acknowledge Mr. B=C3=B6ck's observation that most programs only use one hash. When I first encountered portage, I thought the use of multiple hashes was a very novel and security conscious design choice. The cost is negligible compared to the difficulty it adds to generating a collision. Of course, the difficulty of generating a collision that results in usable code is still very high, but there was an interesting paper that described how it could be easier than most people think. I am not sure how to find it again. It was based on the principle that the solution space for collisions that were valid was actually far denser than the solution space of all collisions. One of the results of this is that finding usefully malicious collisions is probably easier than finding a collision in general, although there may be more non-useful collisions overall. > I retract my prior suggestion that there should be 3 hashes, as I > realize a key statements in GLEP59 that were NEVER implemented: >>> - Removal of depreciated checksums shall happen after no less than 18 >>> months or one major Portage version cycle, whichever is greater. >>> ... >>> After the majority of Portage installations include SHA512 support: >>> - Remove SHA256. > > This GLEP to update the GLEP59 specification should state the following: > - The package manager or verification tool is required to verify at > least one hash, preferably the strongest supported hash. > - Multiple hashes may be present for transitional periods. > - SHA3 or BLAKE2B shall be added to the official Manifest2 hashes. > I'm still kind of confused as to why these changes are being made. Can they be justified? > For implementation: > - Generation of WHIRLPOOL and SHA256 shall be disabled in the next > Portage minor release (as soon as possible) > - Generation of the next choice of hash, SHA3 or BLAKE2B shall be > enabled in an upcoming minor Portage release (soon) > - 18 months after the next GLEP is approved, SHA512 shall be dropped > (put the date into the Portage code so it happens automatically this > time, unlike SHA256 that should have been removed in 2010!). > This makes sense, but I would hope deprecation can be justified in a useful= way. Cheers, R0b0t1