Skip to content

Proposal for configurable range checks on username within the circuit #295

@sifnoc

Description

@sifnoc

We've identified a potential vulnerability in our design where the prover can assign values exceeding the field limitation to the username. This risk is partially mitigated by hashing the username and truncating it outside of the circuit. Overflow Risk Mitigation in Merkle Sum Trees Using keccak256
Despite these measures, we propose introducing a constraint similar to what we've implemented for user balances. This would ensure that even if the hashing step is bypassed or forgotten, the circuit itself would prevent any value that exceeds the 252-bit limit from being used.

Objective:
The goal of this enhancement is to provide a flexible, secure, and configurable range check for preventing overflow in username value handling within our system, thereby safeguarding against potential overflow issues and enhancing the reliability of the MST

Feature Description:
The proposed feature would enable enforcement of username constraints directly within the circuit, akin to the existing range checks for user balances.

  • This would be controlled via configuration (i.e., a Rust feature flag) to enable or disable the functionality as needed.
    • For instance, by enabling the 'range_check_username' feature, the circuit would automatically apply range checks to the username column, ensuring values do not exceed predefined limits.
  • The range check chip is currently configured to check 64-bit values (where N_BYTES = 8 in test code). However, to accommodate varying requirements from different custodians who might need a broader range to prevent user anonymity issues, we propose making this limit more adjustable.
    • For example, custodians could configure the system to allow usernames up to 128 bits, effectively doubling the limit enforced by the range check chip.

This feature is designed to be a robust addition to our existing security measures, giving system administrators the discretion to implement it according to their operational needs and security policies.

Additional Context
For those looking to contribute, it may be helpful to familiarize yourself with the following resources:

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions