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
