This is a portable, performant implementation of BLAKE2s using optimized block compression functions. The compression functions are tree/parallel mode compatible, although only serial mode (singled threaded, the common use-case) is currently implemented.

BLAKE2s is a 256 bit hash, i.e. the hashes produced are 32 bytes long.

All assembler is PIC safe.

The library can be initialized, i.e. the most optimized implementation that passes internal tests will be automatically selected, in two ways, neither of which are thread safe:

1. int blake2s_startup(void); explicitly initializes the library, and returns a non-zero value if no suitable implementation is found that passes internal tests

2. Do nothing and use the library like normal. It will auto-initialize itself when needed, and hard exit if no suitable implementation is found.

Common assumptions:

• When using the incremental functions, the blake2s_state struct is assumed to be word aligned, if necessary, for the system in use.

in is assumed to be word aligned. Incremental support has no alignment requirements, but will obviously slow down if non word-aligned pointers are passed.

void blake2s(unsigned char *hash, const unsigned char *in, const size_t inlen);

Hashes inlen bytes from in and stores the result in hash.

void blake2s_keyed(unsigned char *hash, const unsigned char *in, const size_t inlen, const unsigned char *key, size_t keylen);

Hashes inlen bytes from in in keyed mode using key, and and stores the result in hash. keylen must be <= 32.

Incremental in buffers are not required to be word aligned. Unaligned buffers will require copying to aligned buffers however, which will obviously incur a speed penalty.

void blake2s_init(blake2s_state *S)

Initializes S to the default state.

void blake2s_keyed_init(blake2s_state *S, const unsigned char *key, size_t keylen)

Initializes S in keyed mode with key. keylen must be <= 32.

void blake2s_update(blake2s_state *S, const unsigned char *in, size_t inlen)

Updates the state S with inlen bytes from in in.

void blake2s_final(blake2s_state *S, unsigned char *hash)

Performs the final pass on state S and stores the result in to hash.

size_t bytes = ...;
unsigned char data[...] = {...};
unsigned char hash[32];

blake2s(hash, data, bytes);

Hashing incrementally, i.e. with multiple calls to update the hash state.

size_t bytes = ...;
unsigned char data[...] = {...};
unsigned char hash[32];
blake2s_state state;
size_t i;

blake2s_init(&state);
/* add one byte at a time, extremely inefficient */
for (i = 0; i < bytes; i++) {
    blake2s_update(&state, data + i, 1);
}
blake2s_final(&state, hash);

There are 3 reference versions, specialized for increasingly capable systems from 8 bit only operations (with the world's most inefficient portable carries, you really don't want to use this unless nothing else runs) to unrolled 32 bit.

• Generic 8-bit: blake2s_ref
• Generic 16-bit: blake2s_ref
• Generic 32-bit: blake2s_ref

• 386 compatible: blake2s_x86
• SSE2: blake2s_sse2
• SSSE3: blake2s_ssse3
• AVX: blake2s_avx
• XOP: blake2s_xop

• SSE2: blake2s_sse2
• SSSE3: blake2s_ssse3
• AVX: blake2s_avx
• XOP: blake2s_xop
• AVX2: blake2s_avx2

From what I've seen, the x86-64 compatible version is usually slower than the optimized SIMD version for that platform, so it is not included.

• ARMv6: blake2s_armv6

I attempted a NEON version, but it is almost entirely serial NEON, and the NEON latencies were too high to overcome the ARMv6 version.

See asm-opt#configuring for full configure options.

If you would like to use Yasm with a gcc-compatible compiler, pass --yasm to configure.

The Visual Studio projects are generated assuming Yasm is available. You will need to have Yasm.exe somewhere in your path to build them.

./configure
make lib

and make install-lib OR copy bin/blake2s.lib and app/include/blake2s.h to your desired location.

./configure --pic
make shared
make install-shared

./configure
make util
bin/chacha-util [bench|fuzz]

Benchmarking will implicitly test every available version. If any fail, it will exit with an error indicating which versions did not pass. Features tested include:

• One-shot hashing
• Incremental hashing
• Counter handling when the 32-bit low half overflows to the upper half

Fuzzing tests every available implementation for the current CPU against the reference implementation. Features tested are:

• Arbitrary starting state
• Arbitrary starting counter

Only the top 3 benchmarks per mode will be shown. Anything past 3 or so is pretty irrelevant to the current architecture.

Timings are with Turbo Boost and Hyperthreading, so their accuracy is not concrete. For reference, OpenSSL and Crypto++ give ~0.8cpb for AES-128-CTR and ~1.1cpb for AES-256-CTR, ~7.4cpb for SHA-512, and ~4.5cpb for MD5.

Timings are with Turbo on, so accuracy is not concrete. I'm not sure how to adjust for it either, and depending on clock speed (3.1ghz vs 4.0ghz), OpenSSL gives between 0.73cpb - 0.94cpb for AES-128-CTR, 1.03cpb - 1.33cpb for AES-256-CTR, 10.96cpb - 14.1cpb for SHA-512, and 4.7cpb - 5.16cpb for MD5.

I don't have access to the cycle counter yet, so cycles are computed by taking the microseconds times the clock speed (666mhz) divided by 1 million. For comparison, on long messages, OpenSSL 1.0.0e gives 52.3 cpb for AES-128-CBC (woof), ~123cpb for SHA-512 (really woof), ~49.11cpb for SHA-256, ~16.38 for SHA-1, and ~9.6cpb for MD5.

Public Domain, or MIT