Reject non-canonical Ed25519 signatures - #54
Conversation
|
Changes to the validation criteria are significant and potentially breaking. They should be discussed in an issue first before any changes are made. We inherit ref10 semantics which certain other libraries have chosen to maintain or embrace in the form of ZIP-215. Though the documentation does say RFC8032 which would lean towards the canonical scalar check. Note Ed25519 signatures are still malleable with this change. |
|
Agreed. This changes verification semantics and the ref10, ZIP-215, and RFC 8032 tradeoff needs project-level consensus before code. The audit treated canonical S as an unconditional hardening, which was too simplistic, and the malleability wording was overstated. I am closing this PR rather than forcing a validation policy change without a prior design issue. |
|
I opened #55 about this issue |
Checks signature byte size and requires the encoded S scalar to be below the RFC 8032 group order before provider verification. This rejects malleable S+L encodings accepted by both providers today.
Verified against all 151 official C2SP/Wycheproof vectors (88 valid accepted, 63 invalid rejected) and the full upstream suite.