RSAES-PKCS1-v1_5 encoder emits padding strings as short as four bytes

The RSAES-PKCS1-v1_5 encoder accepts a message whenever valuelen + 7 fits the modulus frame. Because the encoding also consumes three fixed bytes, this permits a padding string of only four bytes. PKCS #1 requires at least eight, so near-limit plaintexts produce nonconforming and materially weaker encodings.

Vulnerable code

In cipher/rsa-common.c, function _gcry_rsa_pkcs1_encode_for_enc:

if (valuelen + 7 > nframe || !nframe)
  {
    /* Can't encode a VALUELEN value in a NFRAME bytes frame.  */
    return GPG_ERR_TOO_SHORT; /* The key is too short.  */
  }

if ( !(frame = xtrymalloc_secure (nframe)))
  return gpg_err_code_from_syserror ();

n = 0;
frame[n++] = 0;
frame[n++] = 2; /* block type */
i = nframe - 3 - valuelen;
gcry_assert (i > 0);

Why it matters

The weakness is reachable only for messages close to the RSA modulus capacity; typical callers use smaller, structured plaintexts or hybrid encryption. Nevertheless, emitted ciphertext can have substantially less random padding than the format promises, reducing the search space when plaintext structure is predictable. This is an encoding-policy failure, not evidence that arbitrary RSA ciphertext can immediately be decrypted.

Proposed fix

Require nframe - valuelen to be at least 11 bytes, expressed with subtraction after checking valuelen <= nframe to avoid arithmetic overflow. Keep random_override_len tied to the resulting padding length. Add boundary tests for message sizes yielding padding lengths seven, eight, and nine, and assert that only standards-compliant frames are produced and round-trip through the decoder.