The way RSA key exchange has been implemented everywhere involves padding. RSA-KEM[1] has been available since forever and no padding is required, though no one uses it for some reason.
RSA-KEM is also trivial to implement as it's virtually identical to textbook RSA, with the sole restriction that m has to be randomly sampled from 1 .. n-1. The shared secret (technically, the encapsulated key) is the hash of the randomly sampled number.
And just like that, no padding oracles or the headache of implementing padding in the first place.
RSA-KEM is nice, but RSA keygen is expensive. That makes using RSA for ephemeral key exchange less attractive than ECDHE. RSA-KEM is fine for static-static key exchanges, and RSASSA-PSS is fine for signatures. But we often want ephemeral-static or ephemeral-ephemeral key exchange, and there RSA is slow for little benefit.
One aspect of RSA that may help it become relevant again is that the key size can be arbitrary by utilizing multiple primes (RSA-MP[1]) and therefore increase the qubit requirement for a successful quantum attack. This could lead to a situation where large RSA keys would remain secure for decades longer than ECC keys, and if quantum computers hit a growth wall then those RSA keys could remain secure forever.
RSA-MP would then serve as a hedge (by either ending up completely secure, or buying time) against novel* PQC algorithms being broken. The cost being large public keys, large ciphertexts, slow decryption and very slow keygen.
Another option is to come up with enormous safe primes for good old DH. This would result is very fast keygen, and decryption performance will equal encryption - but will probably be worse than RSA anyway. The biggest public DH safe prime I'm aware of is 16384 bits (unofficially released by someone who worked on some DH standard which ended on 8192 bits).
* McEliece is not novel but did not see as much scrutiny as RSA. And has huge public keys - so might as well be paired with RSA?
Any RSA scheme must pad messages, otherwise you can leak huge amounts of information.
A high level approximation of what I vaguely recall from back when I worked on crypto (non scam money version) you get stuff along the lines of ((p^m1 mod N) * (p^m2 mod N)) mod N being the same as (p^(m1+m2) mod N). The padding also acts as something of a nonce, and prevents you from inferring the length of the message itself (e.g. you want 'no', 'yes', 'of course I still love you despite you losing all our money investing in beanie babies' to be the same length).
Of course all of this seems more relevant for protocols that are optimized to perform small data transfers in the key exchange itself due to the monumentally giant key exchanges RSA needs to achieve the same security as ECC (seriously people just use ECC), but I'm sure some cryptographers who understand math better than I ever will can explain why these problems also apply even if all you're doing is an exchange of truly random AES keys.
Comments
The way RSA key exchange has been implemented everywhere involves padding. RSA-KEM[1] has been available since forever and no padding is required, though no one uses it for some reason.
RSA-KEM is also trivial to implement as it's virtually identical to textbook RSA, with the sole restriction that m has to be randomly sampled from 1 .. n-1. The shared secret (technically, the encapsulated key) is the hash of the randomly sampled number.
And just like that, no padding oracles or the headache of implementing padding in the first place.
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism> , <https://datatracker.ietf.org/doc/html/rfc5990>
RSA-KEM is nice, but RSA keygen is expensive. That makes using RSA for ephemeral key exchange less attractive than ECDHE. RSA-KEM is fine for static-static key exchanges, and RSASSA-PSS is fine for signatures. But we often want ephemeral-static or ephemeral-ephemeral key exchange, and there RSA is slow for little benefit.
One aspect of RSA that may help it become relevant again is that the key size can be arbitrary by utilizing multiple primes (RSA-MP[1]) and therefore increase the qubit requirement for a successful quantum attack. This could lead to a situation where large RSA keys would remain secure for decades longer than ECC keys, and if quantum computers hit a growth wall then those RSA keys could remain secure forever.
RSA-MP would then serve as a hedge (by either ending up completely secure, or buying time) against novel* PQC algorithms being broken. The cost being large public keys, large ciphertexts, slow decryption and very slow keygen.
Another option is to come up with enormous safe primes for good old DH. This would result is very fast keygen, and decryption performance will equal encryption - but will probably be worse than RSA anyway. The biggest public DH safe prime I'm aware of is 16384 bits (unofficially released by someone who worked on some DH standard which ended on 8192 bits).
* McEliece is not novel but did not see as much scrutiny as RSA. And has huge public keys - so might as well be paired with RSA?
[1] <https://www.degruyter.com/document/doi/10.1515/JMC.2008.006/...>
Any RSA scheme must pad messages, otherwise you can leak huge amounts of information.
A high level approximation of what I vaguely recall from back when I worked on crypto (non scam money version) you get stuff along the lines of ((p^m1 mod N) * (p^m2 mod N)) mod N being the same as (p^(m1+m2) mod N). The padding also acts as something of a nonce, and prevents you from inferring the length of the message itself (e.g. you want 'no', 'yes', 'of course I still love you despite you losing all our money investing in beanie babies' to be the same length).
Of course all of this seems more relevant for protocols that are optimized to perform small data transfers in the key exchange itself due to the monumentally giant key exchanges RSA needs to achieve the same security as ECC (seriously people just use ECC), but I'm sure some cryptographers who understand math better than I ever will can explain why these problems also apply even if all you're doing is an exchange of truly random AES keys.
RSA-KEM isn't padded. It fills the whole modulus with random bits, transforms it, and then feeds that to a KDF to generate an encryption key.