You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe that the signature is valid and the bug is in Botan's PointGFp_Multi_Point_Precompute class. What's special about the given example is that the public key is -G (the negation of the base point). So when you use PointGFp_Multi_Point_Precompute in the ECDSA_Verification_Operation class, the input to its constructor is G and -G. Thus the precomputation of the 15 values for Shamir's trick results in several infinity points. However, the class does not take this possibility into account because it's written to work with the affine point representation. When you call PointGFp::force_all_affine() on these points in the constructor, the function finishes without throwing any exceptions, but all the precomputed points are now zeroed. As a result, when you compute the value of R in ECDSA_Verification_Operation::verify(), it comes out to be the infinity point and signature validation inevitably fails.
At the very least this scenario should result in an exception being thrown by PointGFp::force_all_affine(), just like PointGFp::force_affine() does. But to be fair, -G is a valid public key, so PointGFp_Multi_Point_Precompute should be fixed to accommodate this scenario.
The text was updated successfully, but these errors were encountered:
I believe you are correct this is a bug in Botan. Thank you @andrewkozlik for the report and analysis, and as always @guidovranken thanks for cryptofuzz
We were recently contacted by @guidovranken, who alerted us that our signature verification function in https://github.com/trezor/trezor-firmware/tree/master/crypto accepts the following signature as valid whereas Botan does not:
I believe that the signature is valid and the bug is in Botan's
PointGFp_Multi_Point_Precompute
class. What's special about the given example is that the public key is -G (the negation of the base point). So when you usePointGFp_Multi_Point_Precompute
in theECDSA_Verification_Operation
class, the input to its constructor is G and -G. Thus the precomputation of the 15 values for Shamir's trick results in several infinity points. However, the class does not take this possibility into account because it's written to work with the affine point representation. When you callPointGFp::force_all_affine()
on these points in the constructor, the function finishes without throwing any exceptions, but all the precomputed points are now zeroed. As a result, when you compute the value ofR
inECDSA_Verification_Operation::verify()
, it comes out to be the infinity point and signature validation inevitably fails.At the very least this scenario should result in an exception being thrown by
PointGFp::force_all_affine()
, just likePointGFp::force_affine()
does. But to be fair, -G is a valid public key, soPointGFp_Multi_Point_Precompute
should be fixed to accommodate this scenario.The text was updated successfully, but these errors were encountered: