Possible impact of signature verification deviating from specifications

Findings ref↗, ref↗, and ref↗ imply that an attacker can generate valid signatures for a key they control, which, however, are erroneously rejected by Verify (ref↗ and ref↗) or generate invalid signatures for a key they control, which are erroneously accepted (ref↗ and ref↗). The impact of this deviation is dependent on how signatures are otherwise used in the entire system that uses the Secp256r1 library that we audited.

The main point of possible concern would be if the same signature is independently verified in two (or more) places, with different code. The system as a whole might be built on the assumption that a signature is either valid or invalid and that all signature verifications will agree on validity. Bugs like the three referenced above then imply that an attacker could craft a signature that breaks this assumption. Consequences of this in concrete cases would be highly dependent on the specific scenario and require careful reasoning to analyze the interplay between all involved components.

When considering a cryptographic library for signature verification such as Secp256r1, we thus consider signatures being accepted if and only if they are valid according to their specification to be the central guarantee the library makes to users. We thus consider any deviations that can be triggered in practice to be bugs of high severity.