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.

[thogiti]

Crafting specific inputs that cause the internal state to reach conditions where lo exceeds 0x100000000 (causing multiple carries) is non-trivial due to the complexity of the Blake2-512 algorithm. But, may be you can implement a targeted unit test that artificially manipulates the internal state to simulate the buggy carry handling.

import { Blake512 } from './Blake512'; // Path to Implementation 

// Mock the 'g' function to force 'lo' to exceed the carry threshold
function mockGWithHighLo(v: number[], m: number[], i: number, a: number, b: number, c: number, d: number, e: number): void {
    let lo = 0x2FFFFFFFC; // Force 'lo' to a high value
    console.log(`Mocked lo: ${lo.toString(16)}`); // Logging

    v[a * 2] = (v[a * 2] + ((m[sigma[i][e] * 2] ^ u512[sigma[i][e + 1] * 2]) >>> 0) + v[b * 2] + ~~(lo / 0x0100000000)) >>> 0;
    v[a * 2 + 1] = lo >>> 0;

    // Continue with the rest of the function as per the original 'g'
    // ...
}

// Replace the original 'g' function with the mocked version for testing
Blake512.prototype.g = mockGWithHighLo;

// Create a hash instance and perform updates
const blake = new Blake512();
blake.update(Buffer.from('test input'));

// Finalize the hash
const hash = blake.digest();

// Verify that the carry handling was incorrect
console.log(hash.toString('hex'));

@artwyman

[cedoor]

@Arch0125 are you going to work on the PR you opened: #361

btw, @thogiti I tagged you in a comment there