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.
$\begingroup$
$\endgroup$
2
-
$\begingroup$ 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. $\endgroup$– Hinton ZshCommented Aug 5, 2020 at 8:41
-
1$\begingroup$ related crypto.stackexchange.com/questions/26336/… $\endgroup$– Richie FrameCommented Aug 5, 2020 at 17:17
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
1
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.
answered Aug 5, 2020 at 15:27
-
1$\begingroup$ 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. $\endgroup$ Commented Aug 5, 2020 at 15:38
$\begingroup$
$\endgroup$
4
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.
-
1$\begingroup$ 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... $\endgroup$– DannyNiuCommented Aug 5, 2020 at 9:25
-
1$\begingroup$ "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) $\endgroup$– ponchoCommented Aug 5, 2020 at 13:08
-
3$\begingroup$ @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. $\endgroup$– tum_Commented Aug 5, 2020 at 14:08
-
$\begingroup$ yes, I ment performance, hadh size matters quite a bit for security. $\endgroup$ Commented Aug 5, 2020 at 20:46