RSA-KEM: minimal number of random bits

Question

I've already asked a few - as yet officially unanswered - questions about RSA-KEM with regards to the input secret encrypted using the public key here and (less on topic for this question) here.

CodesInChaos already commented in the first question linked to. It seems logical that having the most significant bit set to zero during generation of the random value $z$ to not impact security all that much.

Still, the use of random number generators for large amounts of data can be a draw back of the mode of operation, especially when they are required to generate 4096 bits of randomness for a single RSA operation. This could be an issue if said random number generator is slow or if insufficient entropy is available to the random number generator.

My related questions are:

1. Can we reduce the amount of input keying material to the KDF further without reducing the security of the RSA operation? If yes, by how much?

2. If yes, is there a good distribution of random bits required (half to the left, half to the right?)

3. If no, could we use a one-way primitive such as a XOF or indeed MGF-1 after retrieving the required number of bits for secure key derivation, and feed that to RSA-KEM?

Or should I just run away and use RSA OAEP instead if I run into situations where a fast DRBG is not available?

Answer 1

Theoretical concern. The standard security reduction of RSA-KEM to the RSA problem relies on the ability of the decryption oracle to handle most of the input space. If you don't feed all the bits into the KDF, or if you treat some inputs equivalently, you may shoot yourself in the foot, like failure to verify lHash in OAEP.

Practical concern. If you don't generate all of the bits of the element $x \in \mathbb Z/n\mathbb Z$ from which you derive a key $k = H(x)$, even if you spread them out so that the standard real number cube root attack doesn't work on exponent $e = 3$, you may nevertheless be walking headfirst into the Franklin–Reiter related-message attack, which applies even to exponent $e = 65537$ that everyone quietly accepts without the PTSD over $e = 3$ left from the dark ages of cryptography engineering in the '90s.

Performance concern. It costs at best about 20k cycles on a modern AMD CPU to compute $x^3 \bmod n$ for 2048-bit $n$—the faster half of RSA with the fastest exponent; any other exponent is slower (except perhaps in Rabin territory), and decryption is much slower. It costs at worst about 1k cycles to generate 2048 bits with Salsa20 using naive C code, and that's about the easiest option, not the cheapest option.

OAEP also needs to generate about $\lg n$ bits of data, but usually with a much more expensive PRNG (‘MGF’), such as SHA-256. Under what circumstances could the generation of $x$ be a bottleneck, but not the MGF computation of OAEP?