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 90BA21396D9 for ; Fri, 20 Oct 2017 23:38:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6F730E0E52; Fri, 20 Oct 2017 23:38:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 267AFE0E45 for ; Fri, 20 Oct 2017 23:38:36 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id B4EB533BF55; Fri, 20 Oct 2017 23:38:34 +0000 (UTC) Message-ID: <1508542710.6784.2.camel@gentoo.org> Subject: Re: [gentoo-dev] Manifest2 hashes, take n+1-th From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sat, 21 Oct 2017 01:38:30 +0200 In-Reply-To: References: <1508440120.19870.14.camel@gentoo.org> <1508446837.29653.1.camel@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: 0e3556c1-ef39-44ff-aedc-8c393777f297 X-Archives-Hash: 001295d5c5837b06540226a776e2105f W dniu pią, 20.10.2017 o godzinie 00∶20 +0200, użytkownik Francesco Riosa napisał: > 2017-10-19 23:00 GMT+02:00 Michał Górny : > > > W dniu czw, 19.10.2017 o godzinie 21∶08 +0200, użytkownik Michał Górny > > napisał: > > > > > > 4. The new hashes that are stronger and commonly available are > > > SHA3/Keccak (using sponges) and BLAKE2 (HAIFA). Both are diverse from > > > our current algorithms, so either is a good candidate. The choice of > > > Keccak is purely arbitrary (because it's the winner?). > > > > > > > Actually, a small correction here: we support more implementations > > of SHA3 than BLAKE2, so the first one is less problematic for us. > > > > Not researched in depth but: > B2sum provided by coreutils is quite satisfacting*, it's pretty fast, while > sha-3 is deemed to be slower than sha-2, maybe this could be weighted while > choosing the algorithm wanted. > > Both seem to take advantage of modern multicore CPUs but sha-3 does 11.7 > [cpb]#0 (see #1) while an email seen on the internet say blake2 can reach 1 > [cpb] (see #2) > > #0 cpb = cpu cycles per byte > #1 https://en.wikipedia.org/wiki/SHA-3#Speed > #2 http://www.metzdowd.com/pipermail/cryptography/2016-May/029297.html > * (in my limited experience) I've taken a closer look at BLAKE2 possibilities, and it seems that it's going to be our choice after all. I'm adding dev-python/pyblake2 as a fallback implementation now. Curious enough, after disabling the 'optimized' SSE2 assembly, the plain register implementation is 2.5 times faster than the SSE2 implementation that is used by default, and two times faster than the built-in SHA2 implementation in Python. -- Best regards, Michał Górny