I've done research about this subject, but I can't find the answer I'm looking for.
I'm making a server (using xinetd) 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 the server 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?
0: Pre-requirements: User needs to upload a public key to the web-interface (Like github or bitbucket). And it is stored like
username = *public-key*dictionary
1: Client connects to the service
2: Server sends an unique uuid (uuid v4)
3: Client sends username and signs the uuid
4: Server verifies the signed uuid by the user uploaded public-key in step 0. Server then generates an 2048-bit RSA key-pair. And now when the user is verified, all communication can be encrypted using the public key from the user. So the server sends the newly generated public-key encrypted with the user's public-key.
5: Client decrypts the public-key, and now sends back the command to the server, encrypted with the server's public-key.
6: Server decrypts the command, and executes it. And then send a final response.
7: Both client and server ends the connection