2

I need to securely request and receive data from a server. The client has the RSA public key, and the server has the RSA private key. So I am generating a random key for AES-128/CBC cipher and encrypting my data using this cipher. The key is encrypted using RSA Public key and decrypted at server end, so both the client and server can communicate for the session.

Now, I have requirement where I need to do this in an offline fashion. The encrypted request will be sent to the server administrator and he will generate the encrypted response.The symmetric key should not be stored in Disk, for later usage. How should the server administrator share the symmetric key with client?

Perhaps, creating one more key pair, in which case the client will have the private key (other than a public key which it already has) and server will have a public key.

But is that secure?

2 Answers 2

3

The idea of using symmetric keys on top of asymmetric encryption is derived from the fact that online communication channel cannot afford the computation required for asymmetric encryption at all time, should they meet some performance criteria (e.g. time). Having an asymmetric handshake ensures the confidentiality of the symmetric key to be used with the cheaper symmetric algorithm for the session. This sessions is meant to have a rather short duration before you expire its key. This is due to the fact that the symmetric encryption can be broken in shorter times than the asymmetric one. However, the data transmitted over such a channel are usually no more relevant when this can theoretically happen (plus the fact that the message itself is not cached on extended period).

If your data cannot harm you if they are decrypted in let's say 3 months, then the symmetric encryption is a good way to go. However, you still need to ensure that you won't re-use the key of this communication for another communication (I guess this is what you meant by saying "the symmetric key should not be stored in disk" ?). If your data has a longer expiration date, you should probably look toward a two-way asymmetric encryption (with each client/server having a key pair that is). Being offline, the time required to encrypt the data is irrelevant and the offline process is more prone to leave "traces" of your encrypted data somewhere.

You asked also "is that secure". Well it depends on what "security" you are looking for. No security if perfect. Even asymmetric encryption requires you trust the mean used to get the public key. I hope the previous paragraph gave you enough clues as how to assess your risks, therefore decide how secure you are.

0

This is what I finally did. It may have security holes but I couldn't think of anything better:

I created an additional pair of keys for which Public key_2 is at Server and Private key_2 at Client Side. When data is to be sent to client in an offline fashion, Server creates a random AES 128 bit key, encrypts the data and the key is encrypted using Public key_2. In addition to that the encrypted data is hashed and hash is signed using Private key_1. All this when reaches the client, Client generates the hash again, compares it with the hash sent from server, verifies the signature using Public Key_1 and decrypts the AES key using Private key_2.

You must log in to answer this question.

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