What this BLAKE2s generator does
This tool computes the BLAKE2s hash of any text, with a digest length you choose from 1 to 32 bytes. BLAKE2s is the compact, 32-bit member of the BLAKE2 family defined in RFC 7693, designed for embedded systems and constrained platforms while remaining fast and cryptographically secure on any hardware.
How BLAKE2s works internally
BLAKE2s (RFC 7693) processes input in 64-byte blocks using a state of eight 32-bit words, initialised from the BLAKE2 initialisation vector XOR’d with a parameter block. The chosen digest length is encoded into that parameter block, making each output size a distinct and independent hash function — not a truncation.
Each block runs ten rounds of the G mixing function applied across columns and diagonals of a 4×4 matrix of 32-bit words:
G(a, b, c, d):
a = a + b + m[sigma[i][2r]]
d = (d XOR a) rotateright 16
c = c + d
b = (b XOR c) rotateright 12
a = a + b + m[sigma[i][2r+1]]
d = (d XOR a) rotateright 8
c = c + d
b = (b XOR c) rotateright 7
The rotation amounts (16, 12, 8, 7) are tuned for 32-bit CPUs — they differ from BLAKE2b’s constants (32, 24, 16, 63), which are tuned for 64-bit lanes. The final block sets a last-block flag before compression, and the low bytes of the eight state words are serialised as the digest.
BLAKE2s vs BLAKE2b — which should you use?
| Property | BLAKE2s | BLAKE2b |
|---|---|---|
| Word size | 32 bits | 64 bits |
| Block size | 64 bytes | 128 bytes |
| Rounds | 10 | 12 |
| Max digest | 256 bits (32 bytes) | 512 bits (64 bytes) |
| Best on | 32-bit / embedded CPUs | 64-bit desktop / server CPUs |
| RFC | 7693 | 7693 |
On a modern 64-bit machine BLAKE2b is faster. Choose BLAKE2s when targeting microcontrollers, IoT devices, or when a 256-bit output is all you need and you want the lighter implementation.
Choosing the output length
The fact that BLAKE2s mixes the digest length into the initial state means a 16-byte BLAKE2s output is not just the first 16 bytes of the 32-byte output — it is a distinct, fully mixed digest. This makes BLAKE2s useful when you need a compact tag (for example, 8 or 16 bytes for a message authentication tag) without the security penalty of blindly truncating a longer hash.
Reference values
These are the canonical BLAKE2s test vectors from RFC 7693:
| Input | Output length | Digest |
|---|---|---|
| (empty) | 32 bytes | 69217a3079908094e11121d042354a7c1f55b6482ca1a51e1b250dfd1ed0eef9 |
abc | 32 bytes | 508c5e8c327c14e2e1a72ba34eeb452f37458b209ed63a294d999b4c86675982 |
You can verify the tool against these values by typing abc and checking the 32-byte output.
Where BLAKE2s fits — and where it doesn’t
BLAKE2s is a general-purpose cryptographic hash: fast, collision-resistant, and designed to replace MD5 and SHA-1 in any non-password context. Matching it to the job matters:
| Need | BLAKE2s? | Better choice if not |
|---|---|---|
| File/content integrity, dedup, content addressing | Yes | — |
| HMAC-style keyed MAC | Yes — use its built-in keying, no HMAC wrapper needed | — |
| Password storage / KDF | No | Argon2 (uses BLAKE2 internally), scrypt, bcrypt |
| Digital signatures over large data | Yes (as the hash) | SHA-256 if a standard mandates it |
| FIPS-validated environments | No | SHA-256 / SHA-3 (BLAKE2 is not FIPS-approved) |
| Very high throughput on 64-bit servers | Prefer BLAKE2b or BLAKE3 | — |
The one recurring mistake is reaching for BLAKE2s (or any fast hash) to store passwords. Speed is a virtue for integrity and a liability for password hashing, where you deliberately want a slow, memory-hard function so brute-force attacks are expensive. BLAKE2’s own keying feature is why it sits inside Argon2 — but use Argon2, not raw BLAKE2s, for credentials.
Keying, salting, and personalization
Unlike SHA-2, BLAKE2 has a MAC and domain-separation built into the algorithm rather than bolted on:
- Keyed mode turns BLAKE2s into a MAC directly —
BLAKE2s(key, message)— with no need for the HMAC construction SHA-2 requires, and without HMAC’s length-extension concerns (BLAKE2 is not vulnerable to length extension in the first place). - Salt and personalization parameters let two systems derive independent hash functions from the same input, so identical data hashes differently in, say, a file-index versus a cache-key context. This is the mechanism protocols use for domain separation.
This tool computes the unkeyed digest; the same RFC 7693 machinery underlies the keyed and personalized variants.
Practical uses
- Embedded firmware integrity — compact enough to run on microcontrollers without a hardware accelerator.
- Short authentication tags — 16-byte BLAKE2s tags are common in cryptographic protocols for lightweight authenticated encryption.
- Content addressing — BLAKE2s is fast enough to hash files during a directory scan to detect changes, even without hardware acceleration.
- Key derivation building block — used inside Argon2, where BLAKE2b/s’s keying feature lets it serve as a pseudo-random function.
Sources and references
- RFC 7693 — The BLAKE2 Cryptographic Hash and MAC — the authoritative BLAKE2s definition, including the test vectors used above
- BLAKE2 official site — the reference implementations and design rationale
- RFC 9106 — Argon2 password hashing — where BLAKE2b is used as an internal primitive
Maintained by the Gera Tools editorial team. The 32-bit word size, 10 rounds, and digest-length-in-state behaviour follow RFC 7693; verify the tool with the abc → 508c5e8c… vector. BLAKE2s detects corruption and can authenticate, but choose a KDF for password storage. Last reviewed 2026-07-02.