[pallet-revive] ecRecover precompile accepts r/s >= N (consensus divergence and malleability)

[Nathy-bajo]

The 0x01 ecRecover precompile at ecrecover.rs checks v in {27,28} but never checks that r and s are in [1, N-1]. It calls sp_io::crypto::secp256k1_ecdsa_recover, whose v1 impl (lib.rs) uses parse_overflowing_slice and reduces s mod N instead of rejecting it, whereas go-ethereum returns empty output (Solidity address(0)) for r,s >= N.

Repro: submit any valid (r, s, v) as s' = s + N (still < 2^256). Ethereum yields address(0), pallet-revive recovers the same non zero signer.

Impact: consensus divergence, and malleability for any contract using ecrecover output for replay or uniqueness protection. The same class exists in the tx path (missing low s / EIP-2, unchecked y_parity/v, RLP decoders never asserting item_count()).

Fix: reject r == 0, s == 0, r >= N, s >= N before recovery, matching ValidateSignatureValues.

[burdges]

We've discussed this issue before revive, but I've long forgotten the resolution, or failure to reach one, except..

I've long suggested the k256 crate by the rustcrypto project, but without knowing if its 100% ETH compatible, but rustcrypto seems pretty contentious, so I'd think they'd accept a PR for a 100% entry point.

We cannot necessarily change our ECDSA hostcall anymore, but we envisioned using an ECC secp256k1 MSM hostcall to allow runtimes to have deployments that matched other chains exactly. We've maybe not added the secp256k1 MSM yet though:

https://github.com/polkadot-fellows/RFCs/blob/main/text/0163-ec-host-functions.md

[Nathy-bajo]

@burdges Agreed the host call is effectively frozen, but this can be closed at the precompile layer by rejecting r == 0, s == 0, r >= N, and s >= N before calling secp256k1_ecdsa_recover (matching ValidateSignatureValues with homestead=false, which still allows high s), needing neither the k256 switch nor an MSM host call. A dedicated secp256k1 host function in the spirit of RFC-0163 (which today only covers BLS12-381, Bandersnatch, and Pasta, not secp256k1) is the right long-term route to bit-exact parity, with this guard as a compatible stop-gap.