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 53ED11396D9 for ; Thu, 19 Oct 2017 21:00:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7F6CE0E56; Thu, 19 Oct 2017 21:00:43 +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 62006E0E43 for ; Thu, 19 Oct 2017 21:00:43 +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 D493133BEA7; Thu, 19 Oct 2017 21:00:40 +0000 (UTC) Message-ID: <1508446837.29653.1.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: Thu, 19 Oct 2017 23:00:37 +0200 In-Reply-To: <1508440120.19870.14.camel@gentoo.org> References: <1508440120.19870.14.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: e4c056b0-8a46-47ec-9b6c-00c5714b6299 X-Archives-Hash: 376c6d86f6cefc8142306145bd47e3b0 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. -- Best regards, Michał Górny