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 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.
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.