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 3246D1396D9 for ; Mon, 13 Nov 2017 02:22:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73D03E1170; Mon, 13 Nov 2017 02:22:38 +0000 (UTC) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 27D6BE115B for ; Mon, 13 Nov 2017 02:22:37 +0000 (UTC) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id E4OOeGb8NvL1pE4OTeGXrd; Mon, 13 Nov 2017 02:22:37 +0000 Received: from [192.168.1.13] ([73.173.137.35]) by resomta-ch2-08v.sys.comcast.net with SMTP id E4OSeWI1GCr36E4OSevafw; Mon, 13 Nov 2017 02:22:37 +0000 Subject: Re: [gentoo-dev] Manifest2 hashes, take n+1-th: 3 hashes for the tie-breaker case To: gentoo-dev@lists.gentoo.org 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> From: Joshua Kinard Message-ID: <88fa2503-11de-2f34-b4a9-58159f14a1ac@gentoo.org> Date: Sun, 12 Nov 2017 21:22:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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 In-Reply-To: <1508818272.1688.7.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfPWZmBsLoFHsRIY+U/S/ULFNbB63nrc1nBdYWZQn9n4VPmp9VfRkOFkYdoL3YqSWKq8rWexXjgW6EVjk2nBkIO9h7W7z2qPJDxJ90QGYr6Du6X5irqgi dlWZRmvY5eCceOTIYZzCsNyVkhmDpEmI+mp+y6iQfcyVZyBSgE/qKk0WYIX7N1nHuNNVWgfAIBys0w== X-Archives-Salt: 15806331-7182-4112-a124-291d4c7ce740 X-Archives-Hash: c06938e1cdc62aebef7307cbdb9b13a1 On 10/24/2017 00:11, Michał Górny wrote: > W dniu wto, 24.10.2017 o godzinie 06∶04 +0200, użytkownik Michał Górny > napisał: [snip] >>> [BOBO06] is relevant research here, I cited it in the work that went into >>> GLEP59, the last time we updated the hashes. The less-technical explanation of it is: >>> "If you can express the output of H1(x)H2(x) in LESS bits than the combined >>> output size of H1,H2, then the attacks get a little bit easier" >>> >>> Some important pieces from it: >>> [J04] "showed that the concatenation of two Merkle-Damgard functions is not >>> much more secure than the individual functions.", but this holds ONLY if >>> the hash functions chosen are of the same construction (MD). >>> Choosing hashes with different constructions (Merkle-Damgard, HAIFA, >>> Sponge) is important, and given a black box environment, >>> >>> The original mail reached the same approximate decision, just to look >>> for diverse hashes, but decided that 2 was enough. >>> >>> Q: What are the odds of a simultaneous successful attack against two hashes? >>> A: IDK, but if the hash functions are truly independent, it must be provably >>> lower than the odds of an attack against a single hash. >> >> We're talking about really huge (→∞) numbers here. It's not a 'random' >> attack against one hash. It's an attack that allows to sneak a malicious >> code with unchanged file size (since we store that too), and no apparent >> side effects (what's the point of spending up that much resources >> if the user is going to notice?). >> >>> Q: What's the big difference between a bug and a successful attack in a hash? >>> A: Bugs are more likely initially, and attacks come later. >> >> Sounds like an entirely abstract point in time ;-). >> >>> All of that said, is there really a significant long-term gain in >>> multiple hashes? (setting aside the short-term advantage in a transition >>> period for changing hashes) >> >> No, and that's my point. One hash is perfectly fine. >> >> Two hashes are useful for transition purposes. If we take two fast >> hashes (e.g. proposed SHA512 + BLAKE2B which have similar speed), >> we can use 2 threads to prevent the speed loss (except for old single- >> core machines). Minor clarification, old single core //and// uni-processor. Some older machines have multiple physical CPUs that are single-core. Threading should be okay on these, as long as the thread count stays under NR_CPUS. I also have a really old single-CPU system, MIPS (obviously). Not the fastest on the block compared to the other equipment I've got, but does anyone know of any simple timing scripts/programs available that can benchmark some of these proposed digest hashes? If they turn out to be reasonably quick on my old machine, I doubt then that speed will be too much of an issue. Also, for whatever hashes we ultimately go with, what are considerations for the userland support for them on non-glibc systems? E.g., are they provided by third-party libraries or do they need implementations in uclibc/uclibc-ng/musl/*? And what about the Alt/BSD side of things? I assume FreeBSD implements this already, but worth verifying with all of the combinations of arches/libc's/kernels and whatnot. I mean, there still might be a lonely m68k install out there... -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic