Skip to content

fix(keypairs): Ed25519 verify_strict for canonical-encoding enforcement (#283)#301

Open
satyakwok wants to merge 2 commits into
XRPLF:mainfrom
satyakwok:fix/ed25519-verify-strict-283
Open

fix(keypairs): Ed25519 verify_strict for canonical-encoding enforcement (#283)#301
satyakwok wants to merge 2 commits into
XRPLF:mainfrom
satyakwok:fix/ed25519-verify-strict-283

Conversation

@satyakwok

Copy link
Copy Markdown

Closes #283.

Summary

Ed25519::is_valid_message was calling VerifyingKey::verify, which the dalek 2.x docs explicitly mark as permissive — it accepts malleable / non-canonical encodings and torsion-point edge cases that RFC 8032 §8.4 forbids.

Switch to verify_strict, which:

  • Rejects non-canonical `R` encodings.
  • Rejects signatures whose `R` has small-order torsion components.
  • Matches rippled's verification semantics, avoiding the consensus-divergence class where this client accepts a signature rippled rejects (or vice versa).

One-line change inside the existing if let Ok(value) = public { ... } arm.

Smoke gate

  • `cargo build` ✓
  • `cargo test --lib core::keypairs -- --skip asynch` — 13 passed, 0 failed (covers Ed25519 + secp256k1 sign/verify round-trips).

…nt (XRPLF#283)

`Ed25519::is_valid_message` used `VerifyingKey::verify`, which the dalek
2.x docs explicitly call permissive — it accepts malleable / non-canonical
encodings and torsion-point edge cases that RFC 8032 §8.4 prohibits.

Switch to `verify_strict`, which matches rippled's verification semantics
and avoids the consensus-divergence class where one client accepts a
signature the other rejects (or vice versa).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ed25519 verification uses permissive verify instead of verify_strict

1 participant