2 of 8
deleted 5 characters in body
Markus
  • 181
  • 1
  • 7

Hybrid encryption with RSA and AES versus spliting into multiple RSA messages?

I've done research about this subject, but I can't find the answer I'm looking for.

The background:

I'm making a network service that is used to transfer small amounts of data (less than 100bytes 90% of the time), to a small amount of users. When a known users connects it will generate a new RSA key-pair and send the public key to the client encrypted using a uniquely already known public key that the client uploaded before the connection began (using a web interface for example). Then both parts knows the other ones public keys and the channel is secured.

The problem is that the public key couldn't fit into the RSA key that the client have, and during encryption getting ValueError: Plaintext is too long.

The proposed solution is to do hybrid encryption by generating a secret key, sending the secret key encrypted with the clients public key, and then send the rest of the data encrypted using AES and the secret key.

I understand the performance is much better in this manner, but for me this feels like opening an extra door to the data. Even though no one would ever find my service interesting enough to try to decrypt the RSA or AES data. But now I have to trust and support two(!) algorithms for the client applications.

Everyone only seems to be speaking good about the hybrid solution, and I understand that it would be the best solution for anything with a lot of traffic going on. Since it's probably about serving users as fast as possible and its not good to waste resources on encrypting/decrypting data.

But theoretically the data is open to two attacks, either by brute-forcing the RSA and get the secret key to decrypt the AES, or directly by brute-forcing the AES. But then again, using 2048-bit RSA and 256-bit AES wouldn't be possible to brute-force any of them any time soon.

So the 256-bit AES must be harder than the 2048-bit RSA, else the data is now less secure somehow, but since AES is 'thousands of times' faster than RSA this doesn't feels true.

The idea I have is that I split my message into chunks, and encrypts each one of them using RSA, then concatenate them into one packet, and the client can then read each encrypted chunk and decrypt them and then concatenate them back to the original message.

Other than it's slower than a hybrid method, Is there anything wrong with this approach?

I've heard that RSA would still be able to encrypt/decrypt a few MBytes/s, and hence it wouldn't really affect my service, Is this correct?

So why would/wouldn't the hybrid encryption system be good for services like mine, where not serving a lot of users is on the priority list?

Markus
  • 181
  • 1
  • 7