linux-kernel - Re: [PATCH crypto v2] crypto: blake2s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 May 2022 15:20:53 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        gaochao <gaochao49@...wei.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH crypto v2] crypto: blake2s - remove shash module

Hi David,

On 5/27/22, David Laight <David.Laight@...lab.com> wrote:
> From: Jason A. Donenfeld
>> Sent: 27 May 2022 09:11
>>
>> BLAKE2s has no use as an shash, with no users of it. Just remove all of
>> this unnecessary plumbing. Removing this shash was something we talked
>> about back when we were making BLAKE2s a built-in, but I simply never
>> got around to doing it. So this completes that project.
> ...
>> diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
>> index c71c09621c09..716da32cf4dc 100644
>> --- a/lib/crypto/blake2s.c
>> +++ b/lib/crypto/blake2s.c
>> @@ -16,16 +16,43 @@
>>  #include <linux/init.h>
>>  #include <linux/bug.h>
>>
>> +static inline void blake2s_set_lastblock(struct blake2s_state *state)
>> +{
>> +	state->f[0] = -1;
>> +}
>> +
>>  void blake2s_update(struct blake2s_state *state, const u8 *in, size_t
>> inlen)
>>  {
>> -	__blake2s_update(state, in, inlen, false);
>> +	const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
>> +
>> +	if (unlikely(!inlen))
>> +		return;
>
> Does this happen often enough to optimise for?
> The zero length memcpy() should be fine.
> (though pedants might worry about in == NULL)
>

I don't know and don't care here. This is a straight copy and paste
for the removal. It is not the place for random performance
optimizations.

I have now witnessed you have random performance optimization ideas in
at least 7 threads, usually unrelated to whatever the topic is. As I
keep telling you every time: SEND A PATCH. Those capital letters are
intentional: I care about the same things you do, so please send a
patch so that all that stuff actually happens. Talk is cheap.

Jason