Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 3 Oct 2019 23:21:01 +0200
From:   David Sterba <dsterba@suse.cz>
To:     Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc:     David Sterba <dsterba@suse.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH] crypto: BLAKE2 reference implementation
Message-ID: <20191003212101.GV2751@twin.jikos.cz>
Reply-To: dsterba@suse.cz
Mail-Followup-To: dsterba@suse.cz,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        David Sterba <dsterba@suse.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" <linux-crypto@vger.kernel.org>
References: <cover.1569849051.git.dsterba@suse.com>
 <8087a8b358b5f97304963a38a17433a416d1382b.1569849051.git.dsterba@suse.com>
 <CAKv+Gu8tEL+5Q6c7TyQvmNjG+HnxfDa01RdE7UTH_YR+VhTpYQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKv+Gu8tEL+5Q6c7TyQvmNjG+HnxfDa01RdE7UTH_YR+VhTpYQ@mail.gmail.com>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi,

thanks for the review.

On Thu, Oct 03, 2019 at 02:18:55PM +0200, Ard Biesheuvel wrote:
> On Mon, 30 Sep 2019 at 15:12, David Sterba <dsterba@suse.com> wrote:
> > The patch brings support of several BLAKE2 algorithms (2b, 2s, various
> > digest lengths). The in-tree user will be btrfs (for checksumming),
> > we're going to use the BLAKE2b-256 variant. It would be ideal if the
> > patches get merged to 5.5, thats our target to release the support of
> > new hashes.
> 
> So this will be used as an alternative to crc32c, and plugged in at
> runtime depending on the algo described in the fs superblock?

Yes, exactly like that. One checksum for the whole filesystem,
specificed by a number in the superblock item.

> Is it performance critical?

I'd put it that performance is important and blake2 has been selected as
the fastest from the modern hashes (ie. sha3 was rejected for that
reason). We're going to add cryptographically strong hashes (blake2,
sha256) and a fast one (xxhash). So the users should choose what's the
best for their usecase given the trade-offs.

If the question is inspired by the current discussions around wireguard
and library versions, we're fine with using the current API as it's
reasonable for the hash algorithms.

Improvements regarding reduction of the overhead would be welcome but
is not important at the moment.

I'll send v2 with the review comments addressed. Thanks.

d.