Re: [PATCH v4 0/5] BLAKE2b generic implementation

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Oct 13, 2019 at 09:50:52PM +0200, David Sterba wrote:
> On Fri, Oct 11, 2019 at 10:57:40AM -0700, Eric Biggers wrote:
> > The choice of data lengths seems a bit unusual, as they include every length in
> > two ranges but nothing in between.  Also, none of the lengths except 0 is a
> > multiple of the blake2b block size.  Instead, maybe use something like
> > [0, 1, 7, 15, 64, 247, 256]?
> 
> Just to clarify, do you mean the block size defined by BLAKE2B_BLOCKBYTES?
> That's 128, so that makes 0 and 256 the multiples.

Yes.

> 
> > Also, since the 4 variants share nearly all their code, it seems the tests would
> > be just as effective in practice if we cut the test vectors down by 4x by
> > distributing the key lengths among each variant.  Like:
> > 
> >           blake2b-160  blake2b-256  blake2b-384  blake2b-512
> >          ---------------------------------------------------
> > len=0   | klen=0       klen=1       klen=16      klen=32
> > len=1   | klen=16      klen=32      klen=0       klen=1
> > len=7   | klen=32      klen=0       klen=1       klen=16
> > len=15  | klen=1       klen=16      klen=32      klen=0
> > len=64  | klen=0       klen=1       klen=16      klen=32
> > len=247 | klen=16      klen=32      klen=0       klen=1
> > len=256 | klen=32      klen=0       klen=1       klen=16
> 
> That's clever. I assume the 32 key length refers to the default key,
> right? That's 64 bytes (BLAKE2B_KEYBYTES), so I'll use that value.
> 

Yes, I meant key lengths [0, 1, 32, 64].  I forgot that BLAKE2b has a max key
length of 64 bytes rather than 32.

- Eric