blake2/libb2

C library providing BLAKE2b, BLAKE2s, BLAKE2bp, BLAKE2sp

BLAKE2

This is the reference source code package of BLAKE2, which includes

• ref/: C implementations of BLAKE2b, BLAKE2bp, BLAKE2s, BLAKE2sp, aimed at portability and simplicity.

• sse/: C implementations of BLAKE2b, BLAKE2bp, BLAKE2s, BLAKE2sp, optimized for speed on CPUs supporting SSE2, SSSE3, SSE4.1, AVX, or XOP.

• neon/: Implementations of BLAKE2{s,b} using the NEON/ASIMD ARM instruction set.

• power8/: Implementations of BLAKE2{s,b} for POWER8, using the VSX and Altivec extensions.

• csharp/: C# implementation of BLAKE2b.

• b2sum/: Command line utility to hash files, based on the sse/ implementations.

• bench/: Benchmark tool to measure cycles-per-byte speeds and produce graphs copyright.

All code is triple-licensed under the CC0, the OpenSSL Licence, or the Apache Public License 2.0, at your choosing.

More: https://blake2.net.

Contact: [email protected]

libb2's Issues

API docs?

Thanks.

why does blake2*_final need outlen?

blake2*_final() asks for outlen only to check if it's the same as the internal one:

int blake2b_final( blake2b_state *S, uint8_t *out, size_t outlen )
{
  if(S->outlen != outlen) return -1;

why is that?

Data Race in x86/x64 pointer to function CPU dispatching

There is a data race in blake2-dispatch.c x86/x64 pointer to function CPU dispatching.

Internal calls are made through function pointers to functions that initially point to corresponding dispatch function that detects the CPU features available and updates the corresponding pointer to function.

For example blake2b_init_ptr initially points to blake2b_init_dispatch. The data race is the blake2b_init_ptr pointer update:

int blake2b_init_dispatch( blake2b_state *S, size_t outlen )
{
  /* data race, non-atomic write to blake2b_init_ptr */
  blake2b_init_ptr = blake2b_init_table[get_cpu_features()]; /*
  return blake2b_init_ptr( S, outlen );
}

All *_dispatch functions are likewise affected:

• blake2b_init_dispatch
• blake2b_init_key_dispatch
• blake2b_init_param_dispatch
• blake2b_update_dispatch
• blake2b_final_dispatch
• blake2b_dispatch
• blake2s_init_dispatch
• blake2s_init_key_dispatch
• blake2s_init_param_dispatch
• blake2s_update_dispatch
• blake2s_final_dispatch
• blake2s_dispatch

Improve release management

Please consider improving release management:

• Use tags reflecting released versions of libb2.
  I advise using standard v<VER> style. (So latest one would be v0.98, pointing to commit 60ea749.)
  Then GitHub's tarballs (tar.gz) available in Tags page will be created just like using git archive --format=tar.gz --prefix="<REPONAME>-<VER>/" v<VER>. (So libb2-0.98 for latest one.)
  But if for some reason your official tarballs on blake2.net differ than those generated automatically using this method, then please upload them to the GitHub release too, so blake2.net won't be the only source of them.
• Put all official libb2 tarballs in one place with directory listing enabled.
  Some suggestions: files.blake2.net, blake2.net/files/, blake2.net/dist/.
  It makes automated scanning for new versions much easier.
• Do not include git repository data in libb2 tarballs.
  https://blake2.net/libb2-0.98.tar.gz (614300 bytes, last modified on 2018-02-02 13:04:19 UTC) that is currently available would be much smaller if generated in the standard fashion (~270 KB).
• Make libb2 existence more official.
  Mention it and link to its latest tarball from the blake2.net front web page.
  libb2 is only mentioned in the context of Rust binding created for it.

setting parameters on big endian systems

It looks like functions like blake2b_param_set_node_offset convert their argument to little-endian on the way in. But those functions aren't exposed in the blake2.h API. Is the expectation that callers (who plan on supporting big endian platforms) will convert their parameters to little endian on their own? Or maybe the plan was to expose the setter functions in blake2.h eventually?

mingw msys errors, libgomp

I am getting errors at the linking stage, when compiling on mingw msys.

Do I need to compile with -fopenmp or something else, such as installing a libgomp library? What steps would I follow to do that exactly?

Thank you.

--

.libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0xc): undefined reference to omp_get_thread_num' .libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0x7c): undefined reference to omp_get_thread_num'
.libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0x5ea): undefined reference to omp_set_num_threads' .libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0x626): undefined reference to GOMP_parallel'
.libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0x9d8): undefined reference to omp_set_num_threads' .libs/libb2_la-blake2sp.o:blake2sp.c:(.text+0xa1d): undefined reference to GOMP_parallel'
.libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0xc): undefined reference to omp_get_thread_num' .libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0x7c): undefined reference to omp_get_thread_num'
.libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0x6ba): undefined reference to omp_set_num_threads' .libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0x6f2): undefined reference to GOMP_parallel'
.libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0xabb): undefined reference to omp_set_num_threads' .libs/libb2_la-blake2bp.o:blake2bp.c:(.text+0xb0c): undefined reference to GOMP_parallel'
collect2.exe: error: ld returned 1 exit status

why does blake2 and libb2 have different API in e.g. the "simple" apis?

blake2:

 /* Simple API */
  int blake2s( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );
  int blake2b( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );

  int blake2sp( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );
  int blake2bp( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );

  int blake2xs( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );
  int blake2xb( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );

  /* This is simply an alias for blake2b */
  int blake2( void *out, size_t outlen, const void *in, size_t inlen, const void *key, size_t keylen );

libb2:

// Simple API
  BLAKE2_API int blake2s( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen );
  BLAKE2_API int blake2b( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen );

  BLAKE2_API int blake2sp( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen );
  BLAKE2_API int blake2bp( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen );

  static inline int blake2( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen )
  {
    return blake2b( out, in, key, outlen, inlen, keylen );
  }

I mean.... using system headers then is a total hit and miss? And seriously no one cares about this all this time? I been using the source in projects so ok, didn't notice, and I been building systemlibs with blake2 but now I am on guest system, and header is from libb2 and it blows up. Surely, someone, somewhere had to look at this and think... Oh dear...? arrays, then lengths sure, but "fat" array tuples looks both nicer and I think associatively makes more sense. Kinda gonna be wild now to unite it.. Blakes are not going away so better nip this whilst you can guys imo.

Cheers.

avx xor illegal instruction

Hello, seems that we are getting illegal instructions on Xen CPUs, when libb2 is built with fat mode on.
this is how libb2 is built [1] and this is the assembly strace

│0x7ffff39b900a <blake2b_init_avx+10> vpxor %xmm0,%xmm0,%xmm0 │
│0x7ffff39b900e <blake2b_init_avx+14> sub $0x48,%rsp │
│0x7ffff39b9012 <blake2b_init_avx+18> mov $0x101,%eax │
│0x7ffff39b9017 <blake2b_init_avx+23> vmovaps %xmm0,(%rsp) │

AVX XOR is not available there

see the complete bug report here [2].
Do you have any clue?

[1] https://buildd.debian.org/status/fetch.php?pkg=libb2&arch=amd64&ver=0.97-4&stamp=1507640440&raw=0

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884958

Installation depends on automake

On OS X:

$ ./autogen.sh
./autogen.sh: line 2: autoreconf: command not found

$ brew install autoreconf
Error: No available formula with the name "autoreconf"

~ googles ~

$ brew install automake

$ ./autogen.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4 
autoreconf: configure.ac: tracing
autoreconf: running: glibtoolize --copy --force
Can't exec "glibtoolize": No such file or directory at /usr/local/Cellar/autoconf/2.69/share/autoconf/Autom4te/FileUtils.pm line 345, <GEN2> line 5.
autoreconf: failed to run glibtoolize: No such file or directory
autoreconf: glibtoolize is needed because this package uses Libtool

Do you think you could throw in a configure script or something?

Ubuntu 22.04: can't install the built library, and autotools config uses obsolete macros

(Opening on behalf of a friend of mine)

Thanks for this project, which is very useful!

• The generated Makefile doesn't seem to install the libs.
• Running ./autogen.sh on an Ubuntu 22.04 (autoconf 2.71) produces a number of warnings

This seems to be similar to https://gitlab.com/openconnect/openconnect/-/issues/413.

I see from the 2.71 announcement that there are some compat breaks with 2.69 and older, and this package currently targets >=2.61. See also the autoconf changelog.

Install issues

$ sudo make -j install
Making install in src
make[1]: Entering directory '/home/user/src/libb2/src'
make[2]: Entering directory '/home/user/src/libb2/src'
 /usr/bin/mkdir -p '/usr/local/lib'
 /usr/bin/mkdir -p '/usr/local/include'
 /bin/bash ../libtool   --mode=install /usr/bin/install -c   libb2.la '/usr/local/lib'
 /usr/bin/install -c -m 644 blake2.h '/usr/local/include'
libtool: install: /usr/bin/install -c .libs/libb2.so.1.0.4 /usr/local/lib/libb2.so.1.0.4
/usr/bin/install: cannot stat '.libs/libb2.so.1.0.4': No such file or directory
make[2]: *** [Makefile:883: install-libLTLIBRARIES] Error 1
make[2]: Leaving directory '/home/user/src/libb2/src'
make[1]: *** [Makefile:1484: install-am] Error 2
make[1]: Leaving directory '/home/user/src/libb2/src'
make: *** [Makefile:440: install-recursive] Error 1

autogen warnings

$ ./autogen.sh
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
<snip>
autoreconf: running: /usr/bin/autoconf --force
configure.ac:11: warning: The macro `AC_LANG_C' is obsolete.
configure.ac:11: You should run autoupdate.
./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
configure.ac:11: the top level
configure.ac:13: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:13: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
configure.ac:13: the top level
configure.ac:39: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:39: You should run autoupdate.
m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
configure.ac:39: the top level
configure.ac:44: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:44: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:44: the top level
configure.ac:54: warning: The macro `AC_HELP_STRING' is obsolete.
configure.ac:54: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:54: the top level
autoreconf: running: /usr/bin/autoheader --force
<snip>
autoreconf: Leaving directory '.'

Build/Test failures on mips/s390x

this is on mips

make[3]: Leaving directory '/<<PKGBUILDDIR>>/src'
make  check-TESTS
make[3]: Entering directory '/<<PKGBUILDDIR>>/src'
make[4]: Entering directory '/<<PKGBUILDDIR>>/src'
PASS: blake2s-test
PASS: blake2b-test
PASS: blake2sp-test
FAIL: blake2bp-test
====================================
   libb2 0.97: src/test-suite.log
====================================

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: blake2bp-test
===================

and s390x

make  check-TESTS
make[3]: Entering directory '/<<PKGBUILDDIR>>/src'
make[4]: Entering directory '/<<PKGBUILDDIR>>/src'
PASS: blake2s-test
PASS: blake2b-test
FAIL: blake2bp-test
PASS: blake2sp-test
====================================
   libb2 0.97: src/test-suite.log
====================================

# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: blake2bp-test
===================

error
FAIL blake2bp-test (exit status: 255)

============================================================================
Testsuite summary for libb2 0.97
============================================================================
# TOTAL: 4
# PASS:  3
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to [email protected]

can you please help? seems some endianess issue

new release ?

is a new release planned ? several commits were done since lastest release.

Also consider applying #38 before, it is really faster than autotools

Test failure on alpha

Hello, please note: alpha is not an official release architecture, so I don't care too much :)

make[3]: Leaving directory '/<<PKGBUILDDIR>>/src'
make  check-TESTS
make[3]: Entering directory '/<<PKGBUILDDIR>>/src'
make[4]: Entering directory '/<<PKGBUILDDIR>>/src'
PASS: blake2b-test
PASS: blake2s-test
FAIL: blake2sp-test
FAIL: blake2bp-test
====================================
   libb2 0.97: src/test-suite.log
====================================

# TOTAL: 4
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: blake2sp-test
===================

error
FAIL blake2sp-test (exit status: 255)

FAIL: blake2bp-test
===================

error
FAIL blake2bp-test (exit status: 255)

============================================================================
Testsuite summary for libb2 0.97
============================================================================
# TOTAL: 4
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to [email protected]

Should dispatch pointer loads/stores be atomic?

Could some obscure microcontroller somewhere read a torn pointer from the dispatch functions, if they happened to get called from two threads at the same time? Would relaxed atomics be appropriate there?

Make b2sum part of libb2

b2sum may be added as an example of library usage, i.e. not built by default unless explicitly asked (e.g. make b2sum). This repository should then become the canonical location of b2sum.

If you don't like this idea, then please consider putting b2sum in its own repository, most likely BLAKE2/b2sum. Having it in BLAKE2/BLAKE2 may work for BLAKE2 reference material, but doesn't really work for distributions and package maintainers. If you'll decide to create such repo, don't forget about release management for it too (tags, tarballs, etc.).

It will substantially help in greater adoption of this utility.

Fix Coverity scan

Maybe it's worth repeating this PR?

cmake support?

I think libb2 is really a great library, thanks for the nice work!

Would it be an option to consider cmake support? Its just much simpler to build software in a cross-platform way with cmake. Also, cmake is a very widely used build system, and its much easier to find (younger) people that have some cmake knowledge than autotools knowledge.

Missing 0.98 tarball

In Homebrew we're using https://blake2.net/libb2-0.97.tar.gz but it looks like the current version in the repository here is 0.98. Yet there is no https://blake2.net/libb2-0.98.tar.gz

support pkg-config?

it seems to be the standard way how to determine location of header/library files, library names, etc.:

https://en.wikipedia.org/wiki/Pkg-config

SSE detection is broken on arm64 macos

Hello,

on arm64 macOS configure detects the following:

checking whether C compiler accepts -msse2... yes
checking whether C compiler accepts -mssse3... yes
checking whether C compiler accepts -msse4.1... yes
checking whether C compiler accepts -mavx... yes
checking whether C compiler accepts -mxop... yes

Looking into config.log shows the following:

configure:12899: checking whether C compiler accepts -mavx
configure:12918: gcc -c -g -O2 -O3  -mavx  conftest.c >&5
clang: warning: argument unused during compilation: '-mavx' [-Wunused-command-line-argument]
configure:12918: $? = 0
configure:12926: result: yes

The right fix would be to check the target cpu family and restrict the SSE/AVX checks to the Intel family.

A more hacky way would be to check for a working -Werror=unused-command-line-argument flag and pass it to the AX_CHECK_COMPILE_FLAG macro as extra parameter.

Thanks,
Gregor

crypto_generichash_blake2b_salt_personal equivalence

Hello folks,

is there an equivalent 'crypto_generichash_blake2b_salt_personal' call provided by libsodium inside libb2?

And if yes, where I can find an example on how to convert the call from libsodium to lib2?

Thanks,
Mark

BLAKE2bx and BLAKE2sx?

Those have longer hash lengths than BLAKE2, might be useful.