Rule
identity-signature-key
A successful history passes a known identity point to the pinned Schnorr verifier.
Specimen 10 of 96 · Audit-default ordinary rules
- Severity
- medium
- Confidence
- high
- Maturity
- experimental
- Selection
- Audit default
- Policy intent
- not required
- Release
- v0.1.1
- Engine facts used
resolved-callsconstantssuccessful-signature-calls
Selection and scope#
Selected by the default audit profile, so an ordinary scan runs it.
./.nightshade/node_modules/.bin/nightshade ./contracts --detectors identity-signature-key
./.nightshade/node_modules/.bin/nightshade detector show identity-signature-keyThe 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/4 | 4/4 | 4/4 | 0/0 | 0 |
Deviations recorded for this rule:
| Case | Kind | Expected to observed lines | Issue |
|---|---|---|---|
| synthetic-regressions.json / identity-signature-key-71 | positive | [6] to [] | miss, exact expectation mismatch |
| synthetic-regressions.json / identity-signature-key-71 | lookalike | [7] to [] | exact expectation mismatch |
| synthetic-regressions.json / identity-signature-key-96 | positive | [4,7] to [] | miss, exact expectation mismatch |
| synthetic-regressions.json / identity-signature-key-96 | lookalike | [5,9] to [] | exact expectation mismatch |
| synthetic-regressions.json / identity-signature-key-97 | positive | [10,13] to [] | miss, exact expectation mismatch |
| synthetic-regressions.json / identity-signature-key-97 | lookalike | [11,15] to [] | exact expectation mismatch |
These are behavior checks on synthetic fixtures, not a precision or recall estimate. See evaluation.
Rule documentation#
From docs/detectors/identity-signature-key.md at v0.1.1.
Availability: default-on; severity medium, confidence high. No application policy is needed. This rule reports only a statically known identity key on a modeled successful history, not every unconstrained verification key.
Example and scenario#
assert(jubjubSchnorrVerify<1>(message, signature, default<JubjubPoint>), "signature");
round.increment(1);An identity verification key does not supply the intended signer authentication. The known-key diagnosis is factual; the analyzer does not construct a signature, prove exploitability, or infer a deployed application's intended signer.
Recommendation#
Reject the identity key and bind the verification key to the intended trusted signer. A nonidentity check alone does not establish trusted ownership or complete key validity. The pinned stable 0.35.0 and 0.35.0-rc.1 standard-library verifiers reject identity keys internally; profile support is a ZKIR2 subset, and upgrades need compatibility review.
Evidence and known false positives#
Canonical resolved stdlib calls retain separate key operands on successful histories. Aliases, helpers, known zero multiplication and caller equality refinements are supported. Rejected histories and same-named application circuits are quiet. No new observation is enabled in projects without the canonical verifier. Observation exhaustion remains explicitly incomplete.
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 identity-signature-key -- 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.