Re: [PATCH v5 2/2] crypto: add test vectors for blake2b

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 18 Oct 2019 at 15:00, David Sterba <dsterba@xxxxxxx> wrote:
>
> On Thu, Oct 17, 2019 at 12:22:57PM +0200, Ard Biesheuvel wrote:
> > On Mon, 14 Oct 2019 at 11:17, David Sterba <dsterba@xxxxxxxx> wrote:
> > >
> > > Test vectors for blake2b with various digest sizes. As the algorithm is
> > > the same up to the digest calculation, the key and input data length is
> > > distributed in a way that tests all combinanions of the two over the
> > > digest sizes.
> > >
> > > Based on the suggestion from Eric, the following input sizes are tested
> > > [0, 1, 7, 15, 64, 247, 256], where blake2b blocksize is 128, so the
> > > padded and the non-padded input buffers are tested.
> > >
> > >           blake2b-160  blake2b-256  blake2b-384  blake2b-512
> > >          ---------------------------------------------------
> > > len=0   | klen=0       klen=1       klen=32      klen=64
> > > len=1   | klen=32      klen=64      klen=0       klen=1
> > > len=7   | klen=64      klen=0       klen=1       klen=32
> > > len=15  | klen=1       klen=32      klen=64      klen=0
> > > len=64  | klen=0       klen=1       klen=32      klen=64
> > > len=247 | klen=32      klen=64      klen=0       klen=1
> > > len=256 | klen=64      klen=0       klen=1       klen=32
> > >
> >
> > I don't think your vectors match this table. It looks to me that you
> > used the first column for all of them?
>
> You're right, the script that generated each digest picked the key/len
> sequence from the beginning and I did not catch that, sorry.
>
> > > +               .plaintext =
> > > +                       "\x00\x01\x02\x03\x04\x05\x06\x07"
> > > +                       "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
> > > +                       "\x10\x11\x12\x13\x14\x15\x16\x17"
> > > +                       "\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
> > > +                       "\x20\x21\x22\x23\x24\x25\x26\x27"
> > > +                       "\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f"
> > > +                       "\x30\x31\x32\x33\x34\x35\x36\x37"
> > > +                       "\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f",
> >
> > Given the number of occurrences of this sequence, I suggest we break
> > it out of this data structure, i.e.,
> >
> > static const char blake2s_ordered_sequence[256] = {
> >   ...
> > };
> >
> > and use
> >
> > .plaintext = blake2s_ordered_sequence
> >
> > here, and in all other places where the entire sequence or part of it
> > is being used.
> >
> > I'm adopting this approach for my Blake2s tests as well - I'll cc you
> > on those patches.
>
> That's a great simplification, I'll do the same then.

Excellent. If you cc me on the next revision, I'll do the big endian
tests I promised you.



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux