Splitting up symmetric key to be able to encrypt using 1024 bit RSA public key

Question

The application which I am writing generates a 256 bit symmetric key everytime it wants to communicate with the server and encrypts the data and sends it to the server. This is to avoid storing the symmetric key on the machine. Now, to encrypt the symmetric key, I am using a 1024 RSA public key installed on the machine whose private key resides on the server. The application sends the encrypted symmetric key as well to the server.

Now, the size limit for encryption using 1024 bit public key with PKCS#1 v1.5 is 117 bytes. Is it secure to split the symmetric key into multiple parts and encrypt them separately using the public key and send them to the server. At the server side, I decrypt them using private key, construct the 256 bit symmetric key back and decrypt the data.

Is this scheme secure? I apologize if you find this question daft.

Answer 1

Firstly, 256 bits is 32 bytes, which is less than 117 bytes, so that fits and there is no need for any kind of splitting.

It could be argued that it is useless to have a 256-bit key for symmetric encryption if it is protected with a 1024-bit RSA key, because, due to its mathematical structure (the structure which enables the public/private key magic), the RSA key is of much lower robustness against attacks, down to the relatively low strength of "about" 80 bits (that's still out of reach of what can be done right now, but at least a machine which breaks 1024-bit RSA key can be designed and its price computed, contrary to a brute force search on a 256-bit symmetric key space, which is way beyond Science and even science-fiction).

The kind of splitting you are asking for would not be trivial to do securely. This would require some careful analysis. No such analysis has been performed yet, to my knowledge, because there is no practical situation which calls for it.

But, most importantly, thou shallt not reinvent the wheel. Establishing a secure communication between a client and a server, with a key exchange and then symmetric encryption, is very tricky to do correctly. There is a standard solution called SSL (well, now it is called TLS, but that's the same). This protocol has been broken and repaired and analysed and optimized for almost two decades, and now it seems safe enough. It is highly doubtful that you (or, for that matter, any human being) could produce something as good (or at least "not worse") by yourself, in substantially less time. There are zillions of design and implementation details which can go wrong. So do the smart thing, use SSL; even smarter, use an existing implementation of SSL instead of writing your own. It will save you a lot of worries, time and money.