# How much data can I encrypt with RSA before I need to change the key

How much data can be encrypted with the same RSA key before it has to be changed?

I looking for the total amount of data that can be encrypted for a single key pair, not the maximum length of data per iteration.

As an example, let's take a 2048-bit RSA key with a PKCS#1 "v1.5 padding". We can compute that the the maximum size of data which can be encrypted per iteration is 245 bytes (2048 bits - 88 bits). How many times can I reuse that key assuming that it encrypts 245 bytes each time?

I find a lot of information on this for AES but almost nothing for RSA.

• There is a good aswer in security.stackexcahge for this question. No need to repeat the D.W. answer. – kelalaka Nov 13 '18 at 19:48

## 1 Answer

The reason that you won't find much is that RSA is generally not used for bulk encryption, instead hybrid encryption is used.

For RSA using PKCS #1 v1.5 padding you generally don't want to go above $$2^{31}$$ but hopefully significantly fewer iterations. This is because of the birthday bound on the random padding used. If the random padding is identical to an earlier random padding then you can distinguish if a message is identical to a previous message.

Of course, this would assume you use all the 245 bytes of the possible payload, leaving you with significantly less than 1TB to encrypt. How much less depends on the risk you want to take with regard to duplicate ciphertext values. Note that if you would use less then 245 bytes for payload, then the number of padding bytes increases. If you would use only 237 bytes of payload then the random padding is about 128 bits and you would not have any problems with repeated ciphertext anymore.

If you just use hybrid encryption: encrypt an random AES data key with full padding then the amount of times RSA can be used is virtually without limit. To be more secure you should look at hybrid encryption with OAEP padding and preferably an authenticated mode for AES such as AES-GCM. For larger messages this will be more efficient (regarding CPU and ciphertext expansion - not to mention the taxation of the RNG) as well as more secure.