Which padding is used by javax.crypto.Cipher for R

问题:

I need to decrypt messages via RSA in order to send it over an unsecured channel, but I'm afraid of the Padding Oracle Attack. Therefore I already have asked the follwoing questions:

1. How to verify the integrity of RSA encrypted messages?
2. How to ensure message integrity for RSA ciphers by using javax.crypto.Cipher

Like suggested in the first question,

However, since you are using a high level cryptographic library, this is something you shouldn't have to worry about. The writers of that library should have taken care of it.

I shouldn't consider about. As far I know, the RSA implementation of PKCS#1 v1.5 is vulnerable to the Padding Oracale Attack whereby OAEP isn't (assumed it's implemented correctly)

Hence I want to know which padding implementation is used by javax.crypt.Cipher by Java 7

回答1:

It depends on the chosen or default provider which padding is actually used when you instantiate a Cipher without fully qualifying it like:

Cipher.getInstance("RSA")

Doing so is a bad practice, because if you switch Java implementations, there might be different defaults and suddenly, you won't be compatible with the old ciphertexts anymore. Always fully qualify the cipher.

As I said before, the default will probably (there are many providers, one can't be sure) be PKCS#1 v1.5 padding. If you need another, you would have to specify it. If you want to use OAEP, here is a fully qualified cipher string from here:

Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

回答2:

That's not a good advice given in the first link to the cryptography site. You should never rely on the defaults of cryptographic libraries cryptographic algorithms. There are quite a few reasons for this:

1. Different implementations, different defaults (there are no requirements for cryptography providers concerning defaults, although most will copy the Oracle/Sun defaults);
2. What's secure now may not be considered secure tomorrow, and because for backwards compatibility, you can never change the default;
3. It's unclear to anybody reading your software what the default is (you could document it, but in that case you might as well write it out).

The SunJCEProvider provided by Oracle defaults to PKCS#1 padding ("PKCS1Padding") for historical reasons (see reason #2 above). This is not well documented.

At that time that default was set you basically had just the insecure textbook RSA ("NoPadding") and the PKCS#1 v1.5 version ("PKCS1Padding" or RSAES-PKCS1-v1_5 in the PKCS#1 v2.1 standard). At that time RSAES-PKCS1-v1_5 was definitely the more secure choice. Changing the default now to OAEP would break every RSA implementation out there that uses the default.

The advice of otus (in the first link within this answer) is be better suited to protocol implementations in libraries than to cryptographic algorithms. In the end you should be able to defend the security of the choices made, whatever you choose.