New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to encrypt buffer with length 256 with 2048 bit RSA #14

Closed
timnew opened this Issue Jan 28, 2013 · 3 comments

Comments

Projects
None yet
2 participants
@timnew

timnew commented Jan 28, 2013

I got error when encrypt 256-bytes-long buffer with RSA 2048.

It says "Error: error:0407906E:rsa routines:RSA_padding_add_PKCS1_OAEP:data too large for key size"

And I found the maximum buffer length that RSA 2048 can handle is just 214 bytes, much less than 256 as expected.

Is this caused because of a bug or it is designed behaviour?

And what should I do if I want to process the data larger than this size?

@dlongley

This comment has been minimized.

dlongley commented Aug 5, 2013

It's a limitation of RSA encryption + padding. If you weren't using any padding, then you could encrypt up to 256 bytes (or rather, up to the modulus). The padding is added before the encryption operation, so you can think of it as if it's part of the message if that helps to understand why it's an issue. Padding is absolutely essential to the security of RSA encryption, however, so don't consider not using any (very bad idea).

If you want to encrypt large data, you should be using a symmetric cipher. If you need to include RSA in the mix, you can generate a one-time use symmetric key, encrypt that using RSA, and then encrypt the message using the symmetric key. Then send the encrypted key (and any IV if your symmetric cipher algorithm required it) and the encrypted message where it needs to go. The recipient can use their RSA private key to decrypt the encrypted symmetric key which they can then use to decrypt the message.

@timnew

This comment has been minimized.

timnew commented Aug 6, 2013

Thanks @dlongley , I have solved the issue by using hybrid encryption, just as you mentioned.
But I still feel a little bit confused about the maximum capability of the encryption

@timnew timnew closed this Aug 6, 2013

@dlongley

This comment has been minimized.

dlongley commented Aug 6, 2013

@timnew, with RSA encryption the mathematical operation looks like this:

c = m^e mod(n), where 'c' is the cipher text, 'm' is the message, 'e' is the public key exponent, and 'n' is the modulus. The 'e' and 'n' components make up an RSA public key.

You can think of this as though the message you want to encrypt is "interpreted" as a big integer. It is then raised to the power of 'e' and then the remainder of that result divided by the modulus yields the cipher text. If you think about this -- it means that there are only 'n' possible cipher texts. For any value of m^e less than n, there is only one possible cipher text. If you go over n, you'll start getting repeats. If that's still not clear, imagine the scenario with small numbers:

Let e = 2 and n = 2:

0^2 mod 2 = 0
1^2 mod 2 = 1
2^2 mod 2 = 0 again
3^2 mod 2 = 1 again, etc.

So in the above example, you can only encrypt a message 'm' that is either 0 or 1 and then you'll start repeating yourself. Think about what would happen when you try to decrypt -- was the message '3' or '1'? You can't tell.

Now add padding into the mix. The padding is added before the encryption operation. So that means it is effectively part of 'm'. That means that if your actual message says Foo bar and there are 10 bytes of '0' padding, 'm' ends up being: Foo bar0000000000. Obviously, padding schemes are more complicated than that, but the point is that the padding is part of 'm' -- so your actual message size is something less than the maximum you could get out of 'm' (you must leave room for the padding).

Hopefully that helps explain it a bit. There's plenty of reading out there on the subject if you're more interested.

@quartzjer quartzjer referenced this issue Jun 4, 2015

Closed

cannot enc data #91

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment