# Is Blake2b vulnerable to length extension attacks?

There are very few resources for Blake2b apart from the official documentation and website. I would like to know if Blake2b is not vulnerable to length extension attacks unlike SHA2. I would like your help as soon as possible.

• the original BLAKE hash was a SHA3 finalist, there's no way BLAKE would make it all the way to the final round of the SHA3 competition (where it lost to Keccak) with a length extension vulnerability :) (btw BLAKE3 might interest you: github.com/BLAKE3-team/BLAKE3/blob/master/README.md ) Aug 4 '20 at 1:43

All from the BLAKE2 paper BLAKE2: simpler, smaller, fast as MD5

First of all

BLAKE2b is optimized for 64-bit platforms — including NEON-enabled ARMs — and produces digests of any size between 1 and 64 bytes.

and from the abstract of the article

BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision resistance, immunity to length extension, indifferentiability from a random oracle, etc

The reason for the resistance to length extension attack

The countermeasure comes from the compression function. The last parameter is set to false when the processed chunk is not the last one.

Compress(h, chunk, cBytesCompressed, false)


It is set to true when the last chunk is compressed.

Compress(h, chunk, cBytesCompressed, true)


So, if an attacker tries to extend a hash, during the recalculation the verifier will arrive in a different hash value then the attackers provided.

• Thank you so much. I was under the gun all day long. I must have overlooked it when I read the paper. Aug 2 '20 at 19:42
• It happens to all. At least you got it fast :) Aug 2 '20 at 19:43