The original commenter said, "using RSA 1024 bit keys with exponent of 3" was a flaw in DRM systems he or she had reviewed. Your response was "e=3 is fine, so long as you remember to pad" and then "what kind of attacks remain when using proper padding (e.g. OAEP)?"
I feel a bit queasy any time I read "just do this" as a solution to crypto flaws[1]. Such answers assume way too much about the system the proposed fix applies to and make it sound trivial to secure. They also leave out all the steps behind what things "just pad" means (e.g., receiver must verify the padding and sender must properly generate).
When a developer hears "just pad", they think "append a string of zeros" when implementing a sender or "skip" when writing a receiver because that's what it means in other contexts.
In particular, your response assumed the DRM system in question:
* Was performing RSA encryption of a message, not signing or verification
* Used a public exponent e=3, not a private exponent d=3
Assuming the reader knows enough about RSA and cryptography to know what "just pad" implies, it may still be insufficient to solve the problem.
For example, if the commenter meant d=3, "just pad" wouldn't fix Wiener's attack.
Or, in the cases of RSA used for purposes other than message encryption, the suggestion of OAEP does not apply. Consider the attacks against the TMN secret sharing protocol and Franklin/Reiter verifiable signature sharing scheme (sections 5.1 and 5.2 of this paper).
The F/R scheme involves RSA encryption of signatures. But signatures must be the full modulus size (no padding possible) unless you use a larger RSA key for encryption than for signing. So again, OAEP would not fix this flaw.
Remember that the commenter was mentioning DRM, so jumping to the conclusion that they were using RSA for straightforward message encryption and with e=3 was not warranted. There are lots of applications for RSA in DRM (verifying a signature on a license key, calculations under homomorphic encryption, etc.)
For many scenarios, "just pad" would not solve the problem, even with the generous assumption that the reader knows exactly what that means and applies it correctly.
[1] I'm not picking on you here. The most astounding of these kinds of errors was when Colin Percival (who I highly respect) said "use AES-CTR mode + HMAC" and then later found he had made a fatal flaw in his own implementation of exactly that.
Great response, thanks; I had not even considered the d=3 possibility. I'd just like to say in my defense that mentioning OAEP wasn't assuming the application was encryption: it was simply the first provably secure padding that came to mind.
Ok, glad to help. I agree with your defense, and e=3 is the obvious assumption for most situations.
You're right that RSA with e=3 can be as secure as e=65537, assuming an application where you use proper encryption/signing padding and verification. But it is more brittle in that partial failures in padding randomness or encryption of related messages can lead to compromise. Unless carefully reviewed and appropriate fail-closed measures are not present, it's better to avoid e=3.
