2
$\begingroup$

What is the current, year 2021, padding Recommendation for RSA? PCKS1? 7? 11? OAEP?

$\endgroup$
9
  • 3
    $\begingroup$ None, don't use RSA for encryption. Forget it about! $\endgroup$
    – kelalaka
    Commented May 31, 2021 at 22:28
  • $\begingroup$ @kelalaka what should I use instead? $\endgroup$
    – Leonardo
    Commented May 31, 2021 at 22:31
  • 2
    $\begingroup$ Have you ever heard the hybrid encryption? ECDH with AES-GCM or XChaCha20-Poly1305, etc. What is your aim? $\endgroup$
    – kelalaka
    Commented May 31, 2021 at 22:39
  • 1
    $\begingroup$ Encryption is a tool, not the aim. What do you want to with the credit card data? Who is the owner of the credit card data? Who can access it? What are the risks, etc.. $\endgroup$
    – kelalaka
    Commented May 31, 2021 at 22:59
  • 2
    $\begingroup$ Agreed with the other commenters here: you should almost certainly be using hybrid encryption. Is this a hobby/learning project? Are you trying to design a new technology to sell to Visa? On a job which involves handling CC data currently? If it's "for work", then you're almost certainly subject to rules such as PCI-DSS, which should all-but-preclude you from being in a position to make such low-level algorithmic decisions. $\endgroup$ Commented May 31, 2021 at 23:03

1 Answer 1

6
$\begingroup$

The best practice for RSA encryption padding¹ is RSAES-OAEP, with a hash such as SHA-256 or SHA-512, and the MGF1 mask generation function using the same hash. The only significant change since RFC 3447 of February 2003 is the deprecation of SHA-1.

RSAES-OAEP with RSA-2048 and SHA-256 is common. Using RSA-3072 and SHA-512 would be unobjectionable and supported by some HSMs, likely safe for decades, and with RSA-2048 and SHA-256 to serve as the canary in the coal mine for those worried² about hypothetical quantum computers usable for cryptanalysis. That allows to embed up to 3072-2×512-16=2032 bits per cryptogram, that is encipher up to 254 bytes of data in an RSA cryptogram of 384 bytes.

Beside the obvious and difficult (keeping private key and un-encrypted data confidential), care must be taken about side channels. In particular on decryption it must not be leaked information about where in the decryption process there is an error. One³ critical point that implementers have sometime missed is at the end of step 3.g in EME-OAEP decoding:

If there is no octet with hexadecimal value 0x01 to separate PS from M, if lHash does not equal lHash’, or if Y is nonzero, output “decryption error” and stop. (See the note below.)
Note. Care must be taken to ensure that an opponent cannot distinguish the different error conditions in (the above), whether by error message or timing, or, more generally, learn partial information about the encoded message EM. Otherwise an opponent may be able to obtain useful information about the decryption of the ciphertext C, leading to a chosen-ciphertext attack such as the one observed by Manger.

One can get away without a constant-time test of the three conditions by testing lHash = lHash’ before the other two conditions. That test itself needs not be constant time.

The reports of RSA's death are greatly exaggerated. When encryption or signature verification must be on a low-resource device, or is much more frequent than the private-key operation (e.g. for the signature embedded in a digital certificate, which is made once and potentially checked billions of time), RSA typically is the practitioner's best choice due to the low cost of the public-key operation.


¹ As pointed in comment, another safe practice is RSA-KEM, but it's not a standalone RSA encryption padding: to safely encrypt a payload, it requires an authenticated cipher, such as AES-GCM. Also, the final cryptogram is larger than with RSAES-OAEP, at equal security against factorization; and the confidentiality of the exact length of the plaintext is not protected, when it is with RSAES-OAEP.

² I'm much more worried about man-made degradation of life conditions on our planet, mass extinction due to asteroids, and new quantum sensors extracting information from my cryptographic devices, than I am about hypothetical quantum computers usable for cryptanalysis.

³ Others are is in the implementation of the private-key RSA function $x\mapsto x^d\bmod n$ itself.

$\endgroup$
3
  • 1
    $\begingroup$ I think this answer will be better if you indicate that the PKCS#1v1.5 padding is secure, (2018 paper) however, hard to implement correctly. This caused many attacks. $\endgroup$
    – kelalaka
    Commented Jun 1, 2021 at 17:41
  • 1
    $\begingroup$ Obligatory: a hybrid scheme using RSA-KEM is also a possibility. As it doesn't use a padding scheme, you could argue that this doesn't directly answer the question. OTOH, it does remove the annoying issues with not implementing the unpadding correctly. Oh, and my little random number generator scheme helps it to be somewhat more efficient. $\endgroup$
    – Maarten Bodewes
    Commented Jun 1, 2021 at 23:03
  • 1
    $\begingroup$ @kelalaka: If you are pointing this paper, also here, it seems to be only about RSASSA-PKCS1-v1_5 signature (and not with usual hashes for best security). Anyway I won't suggest PKCS#1 v1.5 encryption in any form: (A) to my knowledge there is no way to make a library that implements it's decryption in a way that prevent Bleichenbacher's attack. (B) It's current definition hard-codes a 64-bit security level against brute force under CMA: the minimum random padding is just too short. $\endgroup$
    – fgrieu
    Commented Jun 2, 2021 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.