[email protected] (Niels Möller) writes: > Daiki Ueno <[email protected]> writes: > >> [email protected] (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 > > 1. 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, -- Daiki Ueno _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
