Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
1  
why do you want to split it? 117 bytes is much bigger than 256 bits (32 bytes) –  CodesInChaos Jul 30 '13 at 19:40
    
And why is the size limit 117 bytes? –  AJ Henderson Jul 30 '13 at 19:48
    
@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. –  Thomas Pornin Jul 30 '13 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. –  AJ Henderson Jul 30 '13 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.

share|improve this answer
    
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 Jul 30 '13 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. –  Thomas Pornin Jul 30 '13 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 Jul 30 '13 at 23:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.