Overflow Risk Mitigation in Merkle Sum Trees Using keccak256

[sifnoc]

Problem Statement

@bbresearcher has identified a potential security risk related to overflow in the Merkle sum tree.
This theoretical issue could allow a Prover to generate identical identities for different users under certain conditions, despite having unique usernames.

For example:

• UserA's Identity: 0x30644e72e131a029b85045b68181585d2833e84879b9709143e1f593f0000002
• UserB's Identity: 0x1

In scenarios where both users have the same currency amount, a malicious Prover could exploit this flaw to provide the same cryptographic proof to different users.

Proposed Changes

To address this vulnerability, we propose the following change, as suggested by @alxkzmn :

• Use of keccak256 for Hashing Usernames: Implementing keccak256 to hash usernames significantly enhances collision resistance. This measure is crucial given the assumption of a global cryptocurrency user base of approximately $2^{30}$.

Impact on Security

• By utilizing keccak256, we greatly reduce the risk of username collision. The probability of two usernames resulting in the same hash is approximately $2^{-195}$, which is exceedingly low.
  This ensures that each username has a unique and secure identity within the MST.
• The hashed_username utilizes the full 256 bits produced by keccak256. However, to meet the requirements of the Poseidon hash function used in subsequent cryptographic processes, this output is subjected to a modulo operation to fit within the finite field (Fp) of 254 bits.
  This adjustment effectively reduces the bit length by approximately 2 bits, yet this reduction does not meaningfully impact the overall security.

Computational Feasibility

Even with a powerful hashing capability of $2^{30}$ hashes per second, the time required to encounter a duplicate hash result by chance would be about $2.7 \times 10^{21}$ years.
This is calculated using the formula:
$T = \frac{2^{127}}{2^{30}} \text{ seconds} $

where $2^{127}$ is the estimated number of attempts needed to find a collision based on the birthday paradox, highlighting the impracticality of such an event.

[alxkzmn]

For the record, I was suggesting using a hash function whose output size is less than or equal to 254 bits. Therefore, I have a question: can you perform an assessment of collision after modular reduction by 2^254?

[sifnoc]

For the record, I was suggesting using a hash function whose output size is less than or equal to 254 bits. Therefore, I have a question: can you perform an assessment of collision after modular reduction by 2^254?

I had also considered using SHA-224, which aligns with your suggestion regarding the output size. However, I noted that some applications prefer using a truncated message from SHA-256 because it is simpler and potentially more secure if the truncation is more than 224 bits. According to NIST SP 800-107 Rev.1, Section 5.1, the collision resistance is directly related to the length of the hash output. Therefore, SHA-224 offers a collision resistance strength of 112 bits, whereas a truncated SHA-256 to 254 bits provides 127 bits of collision resistance strength.

However, in this PR, there is no truncation process applied to the hash output for usernames. Instead, we pass the untruncated hash output directly to an Fp instance, which internally applies a modulo $p$ operation. Consequently, the Poseidon hasher would use the input as keccak(username) % p.

It's important to consider that the distribution of hash values modulo $p$ might be less uniform than a directly truncated hash output. For example, the hash results are expected to fall within the range $[0, (2^{256} - 1)]$. When using modulo (p), the hash results are constrained within ranges like $[0, (p-1)]$, [(p), $(2p-1)]$, up to $[(5p), [(2^{256} - 1)]$.

The last range, $[(5p), (2^{256} - 1)]$, is smaller than the others, which contributes to a non-uniform distribution. While this range still spans 252 bits, the slight discrepancy in range sizes may impact the uniformity of hash outputs, although it might be considered negligible given the large space covered by 252 bits.

If we want to avoid this non-uniform distribution, we can use 3bits truncated hash ouput for username, which is less than modulo $p$.

[alxkzmn]

Now it's clear to me, thank you for the explanation!