Rule
conditional-hash-range
Conditional unsigned subtraction reaches a fixed-width native persistent-hash input without a qualified inactive-case range invariant.
Specimen 59 of 96 · Other active opt-ins / Privacy and cryptographic derivations
- Severity
- low
- Confidence
- low
- Maturity
- experimental
- Selection
- Opt-in
- Policy intent
- not required
- Release
- v0.1.1
- Engine facts used
resolved-source-referencesresolved-typescanonical-native-calls
Selection and scope#
Not selected by default. Select it with --detectors or the detectors list in nightshade.json. Either one replaces profile selection, so list every rule you want.
./.nightshade/node_modules/.bin/nightshade ./contracts --detectors conditional-hash-range
./.nightshade/node_modules/.bin/nightshade detector show conditional-hash-rangeThe first command runs only this rule; --detectors takes a comma-separated list. The second prints the rule's metadata from your installed version.
Severity is review priority. It does not express exploitability or impact. Confidence is detector metadata, not a probability. All built-in rules are experimental.
Compiler scope: the engine supports the pinned profiles 0.28.0, 0.29.0, 0.30.0, 0.31.1, 0.33.0-rc.2, 0.34.0, 0.35.0-rc.1 and 0.35.0, with ZKIR2 by default. Support for this rule can be narrower; the rule documentation below states any narrower scope.
Corpus checks#
Synthetic corpus checks for this rule in the 0.1.1 proof run. A check counts only with compiler acceptance and complete analysis.
| Positive detected | Corrected quiet | Lookalike quiet | Other negative quiet | Incomplete |
|---|---|---|---|---|
| 1/1 | 1/1 | 1/1 | 0/0 | 0 |
No deviations were recorded for this rule.
These are behavior checks on synthetic fixtures, not a precision or recall estimate. See evaluation.
Rule documentation#
From docs/detectors/conditional-hash-range.md at v0.1.1.
Availability: opt-in compiler compatibility review, no policy required. Severity/confidence: low/high. Select with --detectors conditional-hash-range.
A conditional unsigned subtraction can feed a fixed-width native hash input while its underflow assertion is guarded. In the qualified Compact0.34.0/ZKIR2 output, a direct Uint<128> subtraction feeds persistentHash<Uint<128>>'s 16-byte input without selecting safe operands when the source branch is inactive. The generated JavaScript keeps the computation inside the source branch; this rule does not describe that JavaScript as executing the inactive hash.
import CompactStandardLibrary;
export ledger digest: Bytes<32>;
export circuit update(enabled: Boolean, a: Uint<128>, b: Uint<128>): [] {
if (disclose(enabled)) {
const difference = (a - b) as Uint<128>;
digest = disclose(persistentHash<Uint<128>>(difference));
}
}The finding identifies the subtraction, native hash input and controlling source branch. It is a static review relationship, not proof of an invalid input, proof failure, runtime rejection or deployed vulnerability. Earlier surviving unconditional ordering evidence and qualified safe inactive operand selections are quiet controls. A check inside the same conditional establishes only its active-case constraint.
Select safe operands using the actual controlling condition before computing the hash preimage, and preserve intended active validation. Merely guarding the ledger assignment does not supply an inactive-case hash range invariant. Inspect the project's generated compiler output before relying on version-specific behavior. A direct hash of an already constrained Uint<128> input is a quiet lookalike.
Suppress a match#
If a match is intentional, suppress it on the line before with the exact rule ID and a reason of at least eight characters:
// nightshade-disable-next-line conditional-hash-range -- Reason this match is intentionalDiagnostics cannot be suppressed, and an unmatched directive for a selected rule makes analysis incomplete. See configuration for fingerprint suppressions and baselines.