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.

  • 1
    why do you want to split it? 117 bytes is much bigger than 256 bits (32 bytes) Commented Jul 30, 2013 at 19:40
  • And why is the size limit 117 bytes? Commented Jul 30, 2013 at 19:48
  • 1
    @AJHenderson: with PKCS#1 v1.5 encryption padding, the data which is to be encrypted must be preceded by a header of format 00 02 nnnn 00 where nnnn is a sequence of at least eight random non-zero bytes; so the header length is at least 11 bytes; but the total length post-padding must equate that of the public key modulus, here 128 bytes for a 1024-bit RSA key. 128 minus 11 equals 117. Commented Jul 30, 2013 at 19:55
  • @ThomasPornin - excellent. I didn't recognize the format being used from only having that limitation. I figured there was some header on the format being used, but wasn't sure which it was. Commented Jul 30, 2013 at 20:00

1 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.

  • Thanks for the answer. But I am using ssl for secure communication. What I am worried about is when the data gets stored on the server, since it is a shared server, I don't want anyone other than my application running on the server to be able to view the data. So I am encrypting using a symmetric key. But then I don't want to store the symmetric key at the client side. So I generate it everytime, the client wants to send something. Now, I want to protect the symmetric key as well as the data when it comes to the server. Hence this scheme.
    – Sumeeth
    Commented Jul 30, 2013 at 20:04
  • So you also want encryption for storage. SSL does only transfer. For storage, there again, this is more tricky than it seems. For a storage format which is appropriate, well analysed, and already implemented, consider OpenPGP; an opensource implementation of good repute is GnuPG. Commented Jul 30, 2013 at 20:25
  • Since you're securely transferring the data to the server using SSL, why not just continue to use SSL to transfer the data to the server, and have the server generate the encryption key to store the data on disk instead of the client generating the key? Your server application will have access to the encryption key anyway (since it decrypts it with its private key) so if someone with enough privileges to capture the decrypted SSL stream on the server wanted to see the data, they could just extract the private key and/or the encrypted data itself from the server app.
    – Johnny
    Commented Jul 30, 2013 at 23:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .