# Does encrypting a result of AES block cipher provide more security?

I would like to know if encrypting a result of AES256 block cipher provides more security.

Concretely, I am developing a system in which a client sends to a server a ciphertext encrypted with AES256. The server needs to store it in the database and later send it back to the client. Incidentally, the ciphertext is an encryption of some key important to the client, and is sensitive.

On the server side, there are two options:

1. Save the ciphertext without further processing
2. Encrypt the ciphertext again with a different key, and save the result (let's call it c). When the server needs to send the original ciphertext back to the client, it will decrypt c to the get original ciphertext, and send to it the client.

Option 2 sounds more secure, but I am unsure if it really provides more security. Any ideas?

• Do you expect the client to be able to convert the hash back into the original plaintext? If so, then having the server hash it may be problematic... – poncho Mar 19 at 2:11
• @poncho You're right. The client needs to convert it back to the plaintext, and the question does not make sense because hashing is one-way. I have edited my question. Thanks for pointing it out. – Sung Cho Mar 19 at 2:14
• It still doesn't make sense, unless the server tells the client what key it used. – poncho Mar 19 at 2:17
• Rather than telling the client what key was used by the server, the server will decrypt the ciphertext and then send the result to the client. I have edited the question to be more specific: crypto.stackexchange.com/posts/68113/revisions – Sung Cho Mar 19 at 2:20
• You asking about the security but you did not mention about the threat model. Does the server is honest, semi-honest or malicious? What are the attack models on the database server? Where does the key for the 2. option is stored? What will happen to clients data if the key is lost? – kelalaka Mar 19 at 8:56

Long Story Short

If you only want to store the data as a backup service, do your double encryption yourself, have a backup somewhere. If you want to process the data, you may need FHE, but you need integrity, authentication, and freshness.

Let assume that the client wants to store some data on the cloud and the cloud service provider (SP) offers the client two ways as in your question.

Let's define the models for the service provider;

• Honest: obeys the protocol
• Semi-honest; obeys the protocol but tires to extract information. Can copy but cannot modify.
• Malicious: Doesn't need to obey the protocol. Can diverge from the protocol whenever appropriate.

Assuming that SP doesn't add encryption.

• In this case, if the data has no semantic security, The semi-honest SP can extract information by frequency analysis.

• A malicious SP has much more power on your data than semi-honest SP. When the client requests data $$d$$, SP can return $$d'$$ where the $$d'$$ can be some other data or the previous version of $$d$$ and we call it the freshness (rollback) problem. There is no easy way for the client to believe that the data is authentic without storing some information about the data he uploads to the server as Merkle-Tree.

If the SP offers additional encryption as in your case 2, then;

• The semi-honest SP can still extract information as in no encryption case since the encryption is performed by the OP.

• The malicious SP same as no encryption with more power, he doesn't need to store with double encryption, he can store as you sent him.

What about the attackers. In short, we can talk about the attackers as malicious SP. Some may claim that the frame of the attacks is short, but not necessary.

The biggest problem here, the attacker may steal the data and the encryption key of SP. So, SP encrypted or not the data can be accessed by the attackers as the client uploaded. Some cay says that Hardware Secure Modules can store the encryption keys, but the attackers can use them as an encryption/decryption oracles as the SP does.

So, the second encryption may not give much benefit as one consider.