On Fri, Oct 20, 2017 at 6:04 AM, Kristian Fiskerstrand <[email protected]> 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
