[v6,0/2] BLAKE2b generic implementation

Message

David Sterba Oct. 23, 2019, 12:12 a.m. UTC

The patchset adds blake2b reference implementation and test vectors.

V6:

Patch 2/2: test vectors fixed to actually match the proposed table of
key and plaintext combinations. I shamelessly copied the test vector
value format that Ard uses for the blake2s test vectors. The array
blake2b_ordered_sequence can be shared between 2s and 2b but as the
patchsets go separate, unification would have to happen once both
are merged.

Tested on x86_64 with KASAN and SLUB_DEBUG.

V1: https://lore.kernel.org/linux-crypto/[e-mail]/
V2: https://lore.kernel.org/linux-crypto/[e-mail]/
V3: https://lore.kernel.org/linux-crypto/[e-mail]/
V4: https://lore.kernel.org/linux-crypto/[e-mail]/
V5: https://lore.kernel.org/linux-crypto/[e-mail]/

David Sterba (2):
  crypto: add blake2b generic implementation
  crypto: add test vectors for blake2b

 crypto/Kconfig           |  17 ++
 crypto/Makefile          |   1 +
 crypto/blake2b_generic.c | 413 +++++++++++++++++++++++++++++++++++++++
 crypto/testmgr.c         |  28 +++
 crypto/testmgr.h         | 307 +++++++++++++++++++++++++++++
 include/crypto/blake2b.h |  46 +++++
 6 files changed, 812 insertions(+)
 create mode 100644 crypto/blake2b_generic.c
 create mode 100644 include/crypto/blake2b.h

Comments

Ard Biesheuvel Oct. 23, 2019, 9:01 a.m. UTC | #1

On Wed, 23 Oct 2019 at 02:12, David Sterba <[e-mail]> wrote:
>
> The patchset adds blake2b reference implementation and test vectors.
>
> V6:
>
> Patch 2/2: test vectors fixed to actually match the proposed table of
> key and plaintext combinations. I shamelessly copied the test vector
> value format that Ard uses for the blake2s test vectors. The array
> blake2b_ordered_sequence can be shared between 2s and 2b but as the
> patchsets go separate, unification would have to happen once both
> are merged.
>
> Tested on x86_64 with KASAN and SLUB_DEBUG.
>

Tested-by: Ard Biesheuvel <[e-mail]> # arm64 big-endian


> V1: https://lore.kernel.org/linux-crypto/[e-mail]/
> V2: https://lore.kernel.org/linux-crypto/[e-mail]/
> V3: https://lore.kernel.org/linux-crypto/[e-mail]/
> V4: https://lore.kernel.org/linux-crypto/[e-mail]/
> V5: https://lore.kernel.org/linux-crypto/[e-mail]/
>
> David Sterba (2):
>   crypto: add blake2b generic implementation
>   crypto: add test vectors for blake2b
>
>  crypto/Kconfig           |  17 ++
>  crypto/Makefile          |   1 +
>  crypto/blake2b_generic.c | 413 +++++++++++++++++++++++++++++++++++++++
>  crypto/testmgr.c         |  28 +++
>  crypto/testmgr.h         | 307 +++++++++++++++++++++++++++++
>  include/crypto/blake2b.h |  46 +++++

Final nit: do we need this header file at all? Could we move the
contents into crypto/blake2b_generic.c? Or is the btrfs code going to
#include it?



>  6 files changed, 812 insertions(+)
>  create mode 100644 crypto/blake2b_generic.c
>  create mode 100644 include/crypto/blake2b.h
>
> --
> 2.23.0
>

David Sterba Oct. 23, 2019, 6:11 p.m. UTC | #2

On Wed, Oct 23, 2019 at 11:01:25AM +0200, Ard Biesheuvel wrote:
> On Wed, 23 Oct 2019 at 02:12, David Sterba <[e-mail]> wrote:
> > Tested on x86_64 with KASAN and SLUB_DEBUG.
> 
> Tested-by: Ard Biesheuvel <[e-mail]> # arm64 big-endian

Thanks!

> >  crypto/Kconfig           |  17 ++
> >  crypto/Makefile          |   1 +
> >  crypto/blake2b_generic.c | 413 +++++++++++++++++++++++++++++++++++++++
> >  crypto/testmgr.c         |  28 +++
> >  crypto/testmgr.h         | 307 +++++++++++++++++++++++++++++
> >  include/crypto/blake2b.h |  46 +++++
> 
> Final nit: do we need this header file at all? Could we move the
> contents into crypto/blake2b_generic.c? Or is the btrfs code going to
> #include it?

The only interesting part for btrfs would be the definition of
BLAKE2B_256_DIGEST_SIZE instead of hardcoding the number. As the patches
go through separate trees I have to use the hardcoded number anyway.

The header would make sense for the library version of blake2b, similar
to what the wireguard blake2s patches do, but there's no need for that
right now so I guess the header can be folded to .c.