About

BLAKE2b is a cryptographic hash function defined in RFC 7693. It outperforms SHA-3, SHA-2, and MD5 in software while maintaining equivalent or superior security margins. The function accepts messages of arbitrary length and produces digests from 1 to 64 bytes (8 - 512 bits). Incorrect hash verification leads to undetected file corruption, failed integrity checks in deployment pipelines, and potential acceptance of tampered binaries. This tool implements the full BLAKE2b compression function with 12 rounds of the G mixing function, operating on 64-bit words. It does not rely on WebCrypto (which lacks BLAKE2b support) but computes every round in pure arithmetic.

The implementation handles UTF-8 text encoding via the TextEncoder API and binary file inputs through the FileReader API. Note: this tool performs all computation client-side. No data leaves your browser. For files exceeding several hundred megabytes, browser memory constraints may apply. The output digest is formatted as lowercase hexadecimal. Pro tip: BLAKE2b-256 (32-byte digest) is the most common configuration for general integrity verification.

Formulas

BLAKE2b operates on a 16-word state vector v of 64-bit words. The compression function F takes the current hash state h, message block m, byte counter t, and finalization flag f:

v_0..7 ← h_0..7

v_8..11 ← IV_0..3

v₁₂ ← IV₄ ⊕ t_lo , v₁₃ ← IV₅ ⊕ t_hi

v₁₄ ← IV₆ ⊕ f , v₁₅ ← IV₇

The G mixing function operates on four words at positions (a, b, c, d) with two message words x and y:

a ← a + b + x

d ← (d ⊕ a) ≫≫≫ 32

c ← c + d

b ← (b ⊕ c) ≫≫≫ 24

a ← a + b + y

d ← (d ⊕ a) ≫≫≫ 16

c ← c + d

b ← (b ⊕ c) ≫≫≫ 63

The rotation amounts are 32, 24, 16, 63 bits. Each compression round applies G to 8 combinations of the state vector columns and diagonals. After 12 rounds, the new hash state is: h_i ← h_i ⊕ v_i ⊕ v_{i + 8} for i ∈ {0..7}.

Where h = running hash state (8 × 64-bit words), IV = initialization vector (fractional parts of square roots of first 8 primes), t = byte offset counter (split into low and high 64-bit words), f = finalization flag (0xFFFFFFFFFFFFFFFF for final block), ⊕ = bitwise XOR, ≫≫≫ = right rotation.

Reference Data

Hash Function	Digest Size	Block Size	Rounds	Word Size	Speed (cpb)	Security Level	Standard
BLAKE2b-512	512 bits	128 bytes	12	64 bits	3.3	256 bits	RFC 7693
BLAKE2b-384	384 bits	128 bytes	12	64 bits	3.3	192 bits	RFC 7693
BLAKE2b-256	256 bits	128 bytes	12	64 bits	3.3	128 bits	RFC 7693
BLAKE2s-256	256 bits	64 bytes	10	32 bits	5.1	128 bits	RFC 7693
SHA-256	256 bits	64 bytes	64	32 bits	11.8	128 bits	FIPS 180-4
SHA-512	512 bits	128 bytes	80	64 bits	7.5	256 bits	FIPS 180-4
SHA3-256	256 bits	136 bytes	24	64 bits	8.2	128 bits	FIPS 202
SHA3-512	512 bits	72 bytes	24	64 bits	12.5	256 bits	FIPS 202
MD5	128 bits	64 bytes	64	32 bits	4.9	Broken	RFC 1321
SHA-1	160 bits	64 bytes	80	32 bits	6.0	Broken	FIPS 180-4
BLAKE (original)	512 bits	128 bytes	16	64 bits	5.4	256 bits	SHA-3 Finalist
Whirlpool	512 bits	64 bytes	10	8 bits	14.8	256 bits	ISO/IEC 10118-3
RIPEMD-160	160 bits	64 bytes	80	32 bits	7.0	80 bits	ISO/IEC 10118-3

Frequently Asked Questions

BLAKE2b is optimized for 64-bit platforms and produces digests up to 512 bits using 64-bit word operations. BLAKE2s targets 32-bit and embedded platforms with a maximum digest of 256 bits using 32-bit words. On modern desktop and server CPUs (x86-64, ARM64), BLAKE2b is faster. On microcontrollers (ARM Cortex-M, RISC-V RV32), BLAKE2s is the correct choice. If your digest requirement is ≤ 256 bits and your target is a 64-bit system, BLAKE2b-256 still outperforms BLAKE2s-256 on that hardware.

No. BLAKE2b is a general-purpose cryptographic hash optimized for speed. Password hashing requires deliberately slow functions to resist brute-force attacks. Use Argon2id, bcrypt, or scrypt for password storage. BLAKE2b is appropriate for message authentication (MAC via keyed mode), file integrity verification, digital signatures, and proof-of-work systems.

BLAKE2b handles empty inputs correctly per the specification. The compression function processes a single block of 128 zero bytes with the finalization flag set. For BLAKE2b-512 of an empty string, the digest is 786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce. This is a valid and well-defined output.

JavaScript's Number type uses IEEE 754 double-precision floating point, which provides only 53 bits of integer precision. This implementation represents each 64-bit word as two 32-bit unsigned integers (high and low). Addition carries overflow from the low word to the high word. XOR and rotation operate on individual 32-bit halves. This approach is exact - no precision is lost - because all operations stay within 32-bit unsigned integer boundaries before recombining.

Yes. The b2sum utility (part of GNU coreutils) defaults to BLAKE2b-512. Run "echo -n "your text" | b2sum" and compare the hex output. Ensure you use "echo -n" to avoid a trailing newline. For non-default digest sizes, use "b2sum -l BITS" where BITS is your desired output length in bits (e.g., 256 for 32-byte digest). This tool's output matches b2sum byte-for-byte for identical inputs.

The sigma permutation defines which two message words are fed into each G function call per round. BLAKE2b uses 10 distinct permutation rows, then repeats from the beginning for rounds 11 and 12 (indices 10 mod 10 = 0, 11 mod 10 = 1). The original BLAKE used 16 rounds. Cryptanalysis by Aumasson et al. demonstrated that 12 rounds provide a sufficient security margin - the best known attack on reduced-round BLAKE2b covers only 2.5 rounds. Reducing from 16 to 12 rounds yields approximately 33% speed improvement with no practical security cost.