3
votes
$\begingroup$

Consider GregS's comment to this question (more specific to bouncycastle's provider implementation):

https://stackoverflow.com/questions/11717646/bouncycastle-rsa-key-size-and-padding

The mode, ECB in this case, is ignored for RSA.Use PKCSPadding. The max amount of data you can encrypt is the size of the modulus in bytes minus 11.

I've read several articles that seem to state similar views, including this one:

http://armoredbarista.blogspot.com/2012/09/rsaecb-how-block-operation-modes-and.html

Although that article appears to make the case that it is only ignored when the data exceeds the size of the moduli.

Basically I have a small amount of data to encrypt (a username and password), a private key with a 2048 bit key length, and I'm using the RSA/ECB/PKCS1Padding cipher transformation for encryption. Is this considered "textbook" or "plain" RSA in Java?

I believe I am using a secure approach for our needs, but I need to be sure.

$\endgroup$

1 Answer 1

Reset to default
2
votes
$\begingroup$

ECB, CBC and such cipher modes are something that relate to symmetric cryptography. In context of RSA, it is important to study from documentation of the product what they mean as they do not ordinarily apply.

Based on the articles you provide, this statement is correct:

The mode, ECB in this case, is ignored for RSA.Use PKCSPadding. The max amount of data you can encrypt is the size of the modulus in bytes minus 11.

PKCS#1 standard defines many padding schemes. The more elaborate and less ambiguous name for this scheme and padding is RSAES-PKCS1-v1_5. You just need to ensure that the data you intent to encrypt is at most 245 bytes.

It is common to warn against using textbook RSA. This warning practically means "do not use RSA without using a padding scheme". Thus, RSA with any padding from PKCS#1 is not textbook RSA.

Secure?

In most protocols, what is encrypted with RSA with PKCS#1 padding is a secret key. Encrypting username and password is significantly less common occurrence. Using RSAES-PKCS1-v1_5 securely needs some care in the application. Long story short, it is possible that this padding scheme would not meet the needs of this use. However, as I don't know the context and other algorithms applied, I cannot know if this is secure or not in this context.

The intent of RSA encryption is to ensure that decryption is only performed by party that has access to the private key. RSA encryption does not authenticate the sender, anybody may send a message which appears correct as far as RSA and the padding scheme is concerned.

If sender authentication is needed (quite common), it is necessary to use a digital signature scheme, such as RSASSA-PKCS1-v1_5 in conjuction with the encryption algorithm.

There is a newer padding scheme (Optimal Asymmetric Encryption Padding), which addresses some of the outcomings of RSAES-PKCS1-v1_5. However, as a general advice, I would recommend trying to find a security protocol, which'll implement the entire security use case you have. Implementing any practical security protocol from small blocks like this RSA/ECB/PKCS1Padding is tedious and unfortunately error prone.

$\endgroup$
5
  • $\begingroup$ It's even harder since PKCS#1v1.5 encryption padding is broken in a way that requires the higher level protocol to carefully work around its weaknesses. If you use RSA by yourself, use OAEP padding, not v1.5. $\endgroup$
    – CodesInChaos
    Commented Nov 10, 2013 at 21:31
  • $\begingroup$ @CodesInChaos True. I improved the answer a tiny bit to address this. $\endgroup$
    – user4982
    Commented Nov 10, 2013 at 21:44
  • $\begingroup$ We have a separate authentication scheme for that username/password, and we "own" and setup the identity associated with it, so I'm not concerned about the signature per se. Also, the length will not exceed 245 bytes. My biggest concern is given access to the public key, access to an encrypted username/password, and knowledge of the padding scheme as RSA/ECB/PKCS1Padding, is it possible for a hacker to decrypt? $\endgroup$
    – user8601
    Commented Nov 10, 2013 at 22:42
  • $\begingroup$ @BrianReindel For what I know, it is likely hard to decrypt this scheme based on the public key and encrypted data. But, don't take my word for it. Instead, make your own risk assessment based upon your knowledge of the protocol. Useful detail for considering risk: The difference in security between PKCS#1 (v1.5) and OAEP is described e.g. here: What specific padding weakness does OAEP address in RSA?. $\endgroup$
    – user4982
    Commented Nov 11, 2013 at 15:44
  • $\begingroup$ Thank you for the additional clarification. I have reviewed that post on OAEP in the past, as well as the associated Wikipedia entries. I think much of the confusion comes from the fact that the mode is ignored, but when specified, the padding is not. The question then becomes, how good is the padding scheme, and what are the known disadvantages. $\endgroup$
    – user8601
    Commented Nov 11, 2013 at 15:58