nisse@lysator.liu.se (Niels Möller) writes:
Daiki Ueno ueno@gnu.org writes:
nisse@lysator.liu.se (Niels Möller) writes:
if (mpz_sizeinbase(m, 2) > bits) goto cleanup;
(one might also move initial size checks before the allocations).
I think the above check is too rigid, since it is based on bit-length, it wouldn't tolerate some cases such as m is 1016 bits and bits is 1015, where both can be represented in 127 octets.
I see, a bit odd to tolerate that case. Can it ever happen for a valid signature created according to spec? Section 8.1.1 on signing says
- EMSA-PSS encoding: Apply the EMSA-PSS encoding operation (Section 9.1.1) to the message M to produce an encoded message EM of length \ceil ((modBits - 1)/8) octets such that the bit length of the integer OS2IP (EM) (see Section 4.2) is at most modBits - 1, where modBits is the length in bits of the RSA modulus n
If this EM is the same EM recovered when verifying the signature, then it must still correspond to an integer of size at most modBits - 1.
Yes, that seems to be correct, as both EMSA-PSS-ENCODE and EMSA-PSS-VERIFY takes emBits (= modBits - 1), which is defined as "maximal bit length of the integer OS2IP (EM)".
I am sorry for the confusion.
Regards,