0
$\begingroup$

I understand that a completion flag parameter with Boolean value of 1 is used by Blake2 when it’s compressing the final block of the digested message.

This ensures that one cannot load the state of a blake2 implementation with a blake2 digest and continue on (length extension attack).

However I was just thinking, given that blake2 is open source, couldn't one just create a variant of blake2 that doesn't contain the completion flag, run the original message through it to obtain a non 'completed' digest and then use this as the state to mount a length extension attack through the standard version of blake2?

Which seems so trivial, I'm surprised we consider it length extension proof.

Surely loading the state of SHA-256 is only slightly more hassle than forking blake2, modifying and loading the state.

$\endgroup$
4
$\begingroup$

BLAKE2 is not open-source. BLAKE2 is a specification.

The state is shuffled one last time after having set the final bit, ensuring that a small change, even a single bit, yields a completely different output, that cannot be reverted.

A length extension attack means that knowing M and Hk(M), you may be able to compute Hk(M||E) without knowing the key k.

But with BLAKE2, in order to compute Hk(M) before the finalization, you would need to know the key k. If you somehow know the secret key, you can already forge tags for arbitrary messages.

$\endgroup$
  • $\begingroup$ As always, thank you $\endgroup$ – Woodstock Sep 16 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.