Topic: Is there any scenario where rlen=0/r=0 or slen=0/s=0 wouldn't fail CheckSig? (Read 112 times)
October 18, 2022, 07:10:41 AM
No, that line is checking to see if there is any bytes left in the array/stream (called input) it is reading from, before it reads the "lenbyte" value which is the rlen and could have a value of zero itself.
October 18, 2022, 06:09:47 AM
Doesn't this code in [1] close to the function beginning already check for zero r-lengths?
Code:
/* Integer length for R */
if (pos == inputlen) {
return 0;
}
if (pos == inputlen) {
return 0;
}
October 18, 2022, 01:54:30 AM
Looking at the code, when parsing dersig[1] if r or s length or value is equal to zero, the parser still returns true. Ignoring the strict der encoding enforcement (eg. pre-activation of BIP66) the code eventually ends up here[2] where it would reject the zero r/s values.
My question is if there is any scenario where somewhere in the middle of going from [1] to [2] that it would ignore ECDSA verification and returns true?
Or a better way of asking this question is why isn't the parser in [1] just reject invalid signatures (eg. rlen=0) and return false right there instead of letting it go to [2]?
[1] https://github.com/bitcoin/bitcoin/blob/e7a0e9627196655be5aa6c2738d4b57646a03726/src/pubkey.cpp#L35
[2] https://github.com/bitcoin/bitcoin/blob/c06cda3e48e9826043ebc5790a7bb505bfbf368c/src/secp256k1/src/ecdsa_impl.h#L216
My question is if there is any scenario where somewhere in the middle of going from [1] to [2] that it would ignore ECDSA verification and returns true?
Or a better way of asking this question is why isn't the parser in [1] just reject invalid signatures (eg. rlen=0) and return false right there instead of letting it go to [2]?
[1] https://github.com/bitcoin/bitcoin/blob/e7a0e9627196655be5aa6c2738d4b57646a03726/src/pubkey.cpp#L35
[2] https://github.com/bitcoin/bitcoin/blob/c06cda3e48e9826043ebc5790a7bb505bfbf368c/src/secp256k1/src/ecdsa_impl.h#L216
Jump to: