crytic / crytic/slither

Feature request: detector for quantum-vulnerable signature schemes (ecrecover / ECDSA.recover)

Open
#3,070 1 comment 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Python
Stars
6.4k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

### Describe the desired feature

## Desired feature

A detector that flags contracts relying on `ecrecover()` or OpenZeppelin's `ECDSA.recover()`
for signature verification, informational-severity, noting that secp256k1/ECDSA-based signatures
are not resistant to a cryptographically-relevant quantum computer (CRQC).

## Motivation

The Ethereum Foundation formed a dedicated Post-Quantum Security team in January 2026
(pq.ethereum.org), and NIST's PQC standards (ML-DSA, ML-KEM) are now finalized. As migration
tooling starts to matter for the ecosystem, static analysis for "which contracts even rely on
quantum-vulnerable signature verification" seems like a useful, currently-missing capability I couldn't find an existing detector or open proposal covering this (searched issues for
"quantum" and "post-quantum": no results).

## Distinct from #1950

This is a different concern from #1950 ("Improper usage of ecrecover"), which is about
*correctness* of ecrecover usage (malleability, missing zero-address checks, yellow-paper
compliance). This proposal is about *cryptographic-scheme readiness* flagging that a
contract uses ECDSA at all, regardless of whether it's used correctly, since even a "correct"
ecrecover call is still quantum-forgeable in the long run. Different severity model
(informational/awareness, not a bug), different audience (protocol teams doing PQ migration
planning, not auditors looking for exploitable bugs).

## Proposed scope (v1)

- Detect calls to `ecrecover()` and `ECDSA.recover()` (OpenZeppelin)
- Classification: Informational
- Output message references NIST PQC standards and links to pq.ethereum.org for migration context
- No changes to detection of ecrecover *misuse* that stays in #1950's scope

Happy to build this if the maintainers think it's a good fit let me know if you'd want it
scoped differently before I put together a PR.

Contributor guide

Open the contributing guide

Research direction

Start by locating the existing detector for improper ecrecover usage referenced as #1950 and review how detector severity and messages are defined. Add coverage for ecrecover() and OpenZeppelin's ECDSA.recover() without changing misuse detection. Done means both call forms produce an informational finding with the requested PQC and pq.ethereum.org context.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, solidity
Domain
security
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.