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 7B5921396D9 for ; Fri, 20 Oct 2017 13:32:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D735E0EEF; Fri, 20 Oct 2017 13:32:30 +0000 (UTC) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 1053EE0ED5 for ; Fri, 20 Oct 2017 13:32:29 +0000 (UTC) Received: by mail-pf0-x241.google.com with SMTP id e64so11097657pfk.9 for ; Fri, 20 Oct 2017 06:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=GX7Boniu3GOul476O085bkXHF91nXhTEaAz8ZCEjkGI=; b=qSO0jJHfepGIGU0yp3hTtoh2B49zw+58DU/PnIh9MiPthfXsXYK9I1K3YOjq7xVkfh vtCIQmQfesbf5WXge4E9or8M0n6JEHRwoZQBFJ8C3Qj6i18EsT1FyLdj0iypKGB0xeBf 7f7qMJb5X5vN+lDjQN+PW6zCP3HkhET4Hw3oSZRrD0tVnki+C7JrSckkr+H2Y2zBMp0m /86ADt7cuy3Y1ioR4fNBA2jCbx8XkVCaRr6Gm35INtbz0+FFB/PVY0stqupLP6tEMxVZ Yh0c9azwxtc2102U68OQ5Cy4D0XefODeGIFFfEVRqAA795pwYmG3zyfUuupJkZC+o7cq 2S7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=GX7Boniu3GOul476O085bkXHF91nXhTEaAz8ZCEjkGI=; b=KMUcHHEGXbDbaG/0npaLLVr2pAFmBEV4lYOAD6FcN4vGimMo8zKpsRGkdqlrWg2srF Ctl33/bh1/IVoGK7PG+aulPXhgmejxjdCELl67+D3jJffnnCnQ76kr3Qsew1K95HYO5D jUNSi/5sp2IHXc4bd7kZkEuS0nir7tr6NjnpbWwcBdiCqy8SmmtIDZH4456+V5Z4HQIg g4p6pCWnLgFrKxRjkjhk0WLgFnnL+qbmK5cGyVLLWUorwbkVhFyBLdA1Qtxy+/uo6h1S WFVCFwPjO9Q3KTKAtvp2N/RAsKYSLXU0QHP/UJGqr0rgwvX77QnOO5Wyjeg7pYfFLCC/ 5IgQ== X-Gm-Message-State: AMCzsaUOJlF97BKtxfSEtbdLXGX6qOLP2jQgSxpi6uI45AzBou1igC+n /7SWrz4np5eQGB35SXOEkKJNt1xlz5XttXtcUmIlkA== X-Google-Smtp-Source: ABhQp+SHBTBYgayd7b17wNren7pmlqjOkZHf5mzg+1F0/3X7J+4ftMkt3gblzpOvw/QaF6sggSO1Hh45pNx9lvThATs= X-Received: by 10.84.128.68 with SMTP id 62mr4167184pla.442.1508506347926; Fri, 20 Oct 2017 06:32:27 -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 Sender: freemanrich@gmail.com Received: by 10.100.155.67 with HTTP; Fri, 20 Oct 2017 06:32:27 -0700 (PDT) In-Reply-To: <493bb327-9729-1698-ac07-d74a8ee3a14b@gentoo.org> References: <1508440120.19870.14.camel@gentoo.org> <20171020003258.7ad4695b@pc1> <493bb327-9729-1698-ac07-d74a8ee3a14b@gentoo.org> From: Rich Freeman Date: Fri, 20 Oct 2017 06:32:27 -0700 X-Google-Sender-Auth: 6R6e9jVW7Ak9WjrO4Yh_BoyssHM Message-ID: Subject: Re: [gentoo-dev] Manifest2 hashes, take n+1-th To: gentoo-dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 80235907-15dc-44da-a4d6-2dce61db2376 X-Archives-Hash: 64b4d3d7a8861759b1336e75508c65f7 On Fri, Oct 20, 2017 at 6:04 AM, Kristian Fiskerstrand wrote: > On 10/20/2017 11:10 AM, Dirkjan Ochtman wrote: >> >> I support Hanno's suggestion of doing just SHA512, but would be >> interested in hearing opinions from others who have apparent >> security/crypto experience. Maybe the Security project can weigh the >> suggestions as well? >> > > The whole discussion is moot so long as we don't have OpenPGP signed > gentoo repository in rsync. > > SHA2-512 is generally quicker than sha256 on 64 bit architectures, but > considerably slower for some architectures. Introducing a non-optimized > keccak on top of it will have a significant negative performance impact > for these arches without much security gain. > > if we still want two separate hashes, the choice of sha2 and sha3 > compination is a good one given they are based on separate constructs. > > But IMHO we should start where things matter and complete an > implementation for OpenPGP signatures of MetaManifests in Portage. > Nobody is stopping you from implementing this. However, saying that we can't improve any other aspects of the security of Gentoo until somebody improves this one aspect (that people have been talking about for a decade) seems like a false dependency. I do get that a chain is as strong as its weakest link, but there are attacks that an unsigned hash protects us against. If somebody has the ability to modify the upstream binary but not the ability to modify our hashes, then the hash protects us even if it is unsigned. Sure, it would be better still if it were signed, but that is no reason to make improvements all the same. IMO having two hash functions makes sense. Sure, the last two times a hash has failed have had a decade of warning. However, there is no theoretical reason why this has to be the case. At best you can make hand-waving arguments. I wouldn't look at md5/sha1 and take from them the lesson that we can relax because if a hash function fails we have plenty of warning, or that we don't have to worry because we use more bits today. Rather I would look at md5/sha1 and take from them this lesson: They were never intended to be defeated in less than brute force time, and yet both were. Adding more bits makes it take longer to brute-force, but that provides no assurance against an attack that runs faster than brute force. No such attack should exist, but the same was true of md5/sha1. Sure, some hash failures are worse than others, and we're lucky in that a less severe failure was discovered first, but there is no theoretical reason that failures have to be discovered in some particular order. If it were a matter of adding support for multiple hash functions to portage that would be one thing. However, all our tools already support this, so why not continue to take advantage of this in the most efficient manner possible? Why give up a layer of security that costs us little but a bit of CPU. -- Rich