Fix carry handling in the g function in blake.ts

[thogiti]

Incorrect Carry Handling in the g Function

The g function in Implementation in blake.ts uses ~~(lo / 0x0100000000) to compute the carry from the lower 32 bits of a 64-bit word.

Since lo can be up to 0x2FFFFFFFC (i.e., approximately 3 times 0x0100000000), the carry can erroneously be 2 or 3.

Impact

• Functional Integrity: Incorrect carry values can corrupt the internal state, leading to wrong hash outputs.
• Security Risks: The integrity of the hash function is compromised, potentially allowing for hash collisions or predictable outputs, which undermines the cryptographic strength of Blake2-512.

Recommendation

• Modify the carry calculation to ensure that only a single carry bit (0 or 1) is propagated. For example:

const carry = lo >= 0x100000000 ? 1 : 0;
v[a * 2] = (v[a * 2] + ((m[sigma[i][e] * 2] ^ u512[sigma[i][e + 1] * 2]) >>> 0) + v[b * 2] + carry) >>> 0;

• Alternatively, use BigInt for precise 64-bit arithmetic operations as in the original Blake implementation in the npm repo, which TypeScript supports, to handle carries correctly without manual intervention.

[cedoor]

A better solution for this issue might be to use the original Blake implementation directly, wrapping it with a TS class.

[hannahredler]

Hey, if you need someone to work on this I would be happy to do so and replace the custom implementation with a wrapper over this implementation

[cedoor]

@hannahredler sure, let us know if you'd like to work on this and we'll assign it to you.

[Arch0125]

@cedoor Hey ive built a wrapper around the original blake-hash implementation, let me know if i can open a PR for review

[cedoor]

Hi @Arch0125 , of course! I'll assign this issue to you

[Arch0125]

@cedoor ive raised a PR here #361

[artwyman]

Is there a known set of real inputs which can demonstrate this error? What's the likelihood of this occurring in the wild with non-malicious inputs? Two contexts in which I ask these questions:

• Zupass and related apps have already issued signed data in the POD format which makes use of the hashes in zk-kit. I'd like to know how likely we are to deal with signatures failing after this update.
• In fix(eddsa-poseidon): fixes carry handling of g function by introducing wrapper over original implementation #361 it would be great to validate the fix with a targeted unit test using an input which would produce incorrect results before the PR, and correct results after the PR. Assuming this bug doesn't exist in the circomlibjs implementation of blake512, such a test could fit in with the compatibility tests which compare results between the two libraries.