Reject s == 0 or r == 0 in a ECC signature.

In ECDSA, this cases should all be caught by the later check that R is
not zero, so I don't believe there is any security danger.

However the GOST 34.10 implementation did not have either check.
Fortunately, the function that extracts the affine X coordinate from
the Jacobian coordinates will throw an exception if the point is at
infinity, so we would not in fact accept invalid signatures, but this
is mostly by luck. And still represents a bit of a DoS potential.

I checked the history, it looks like not checking for zeros at the
start traces back to the original InSiTo code, and I copied the ECDSA
code for GOST without thinking about it too much.

1 files changed, 4 insertions, 1 deletions

diff --git a/src/pubkey/gost_3410/gost_3410.cpp b/src/pubkey/gost_3410/gost_3410.cpp
index 507ebb5a0..97e0f4a5e 100644
--- a/src/pubkey/gost_3410/gost_3410.cpp
+++ b/src/pubkey/gost_3410/gost_3410.cpp
@@ -153,7 +153,7 @@ bool GOST_3410_Verification_Operation::verify(const byte msg[], size_t msg_len,
    BigInt s(sig, sig_len / 2);
    BigInt r(sig + sig_len / 2, sig_len / 2);
 
-   if(r < 0 || r >= order || s < 0 || s >= order)
+   if(r <= 0 || r >= order || s <= 0 || s >= order)
       return false;
 
    e %= order;
@@ -167,6 +167,9 @@ bool GOST_3410_Verification_Operation::verify(const byte msg[], size_t msg_len,
 
    PointGFp R = (z1 * base_point + z2 * public_point);
 
+   if(R.is_zero())
+     return false;
+
    return (R.get_affine_x() == r);
    }