# Why blake2b is the fastest despite it being 512 bits hashing algorithm?

I am struggling to understand why blake2b is faster than blake2s, despite that blake2b is 512 bits hashing. I hope someone can clarify that for me. I read the official paper for blake2b, but I am not a very technical guy. I didn't understand much of it.

• I would be over the moon, if one of the authors answered my question. I am doing a research on blake2b vs SHA3-512, and I will be presenting my findings to a large audience. – Hinton Zsh Aug 5 '20 at 8:41
• – Richie Frame Aug 5 '20 at 17:17

I am struggling to understand why blake2b is faster than blake2s, despite that blake2b is 512 bits hashing.

Comparing is not easy. They designed

• BLAKE2b for 64-bit platforms including NEON enabled ARMs. That can produce between 1 and 64-byte digest

• BLAKE2s for 8- to 32-bit platforms. That can produce between 1 and 32-byte digest

They are fast on their target

Each one is portable to any CPU, but can be up twice as fast when used on the CPU size for which it is optimized; for example, on a Tegra 2 (32-bit ARMv7-based SoC) BLAKE2s is expected to be about twice as fast as BLAKE2b, whereas on an AMD A10-5800K (64-bit, Piledriver microarchitecture), BLAKE2b is expected to be more than 1.5 times as fast as BLAKE2s.

Even BLAKE2b does 12 rounds, and BLAKE2s does 10 rounds it still faster on their platform. And the CPU word size has a huge effect, too.

They modified the original design of BLAKE with the confidence it's security well tested. From the Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition

Keccak received a significant amount of cryptanalysis, although not quite the depth of analysis applied to BLAKE, Grøstl, or Skein

Some of the modifications; BLAKE2b uses 24-bit rotations that use SSS3 and can perform two rotations on parallel. Originally BLAKE was using 25 (now 24) and 11 (now 63) bit rotations. In addition, the 63-bit rotation can be also fastened on some recent Intel CPUs.

AVX and AVX2 (Advanced Vector Extensions) can boost any code whenever applicable. BLAKE2b benefits form AVX/2 whenever available. More detail can be found at BLAKE and 256-bit advanced vector extensions paper.

As having past experience on Cray Vector Machines, I can pretty surely say that if your code is vectorizable, you gain huge speed up.

• Thank you so much Kelalaka. You are a great guy. You answers are well explained and concise. Thank for answering and providing me with the link to the paper. Much appreciated. – Hinton Zsh Aug 5 '20 at 15:38

BLAKE2s handles a file in 32 bit chunks where as BLAKE2b handles a file in 64 bit chunks. On a 64 bit processor (most modern processors) a single 64 bit operation and a 32 bit operation will take the same amount of time, but since the file is likely more than 64 bits (unless its like 8 letters) taking it in chunks of 64 rather than 32 is faster since you need half as many itterations.
The final hash size doesnt really matter since files are much larger than the hash. Additionaly, it appears the extra hash length is directly caused by using 64 bit numbers imstead of 32 bit.

• handles a file in 32 bit chunks? I hope you're not confusing compression function block size and algorithm integer word size, and bits and bytes... – DannyNiu Aug 5 '20 at 9:25
• "The final hash size doesnt really matter"; actually, it rather does, at least for cryptographical hashes. We expect that an $n$ byte hash would require the attacker to perform circa $16^n$ operations to find a collision (and $256^n$ operations to find a (second) preimage); for larger $n$, this means that we allow the attacker a larger computational budget (and hence we have more stringent requirements on the hash function) – poncho Aug 5 '20 at 13:08
• @poncho They meant - as far as the performance (speed) of hashing is concerned. The number of the file read operations matter much more. It was not about the attacks. – tum_ Aug 5 '20 at 14:08
• yes, I ment performance, hadh size matters quite a bit for security. – Jesse McDonald Aug 5 '20 at 20:46