# Does it increase security if the CBC chunks of a AES-256 encrypted bytestream are uploaded to different clouds?

I want to backup my data according to the 3-2-1 rule. I am already back up to 2 different drives (2 different systems) at home. In addition, I would like to use cloud storage (Google, Amazon, etc.). Considering the future weakening of cryptography by advancements in computing power (e.g. key guessing by quantum computing) I want my data to be as safe as possible because once it's uploaded it's prone to decryption in the future (i can't guarantee the data is deleted if I delete it from the cloud(s)).

Does it increase the security of my data if I split the CBC chunks to let's say 2 clouds? Uploading the even-numbered CBC elements to e.g. Google and the odd-numbered elements to Amazon. Since one storage hoster is constantly missing the next part of the CBC-Chain (1/2 in total) shouldn't this increase security of the data even if the AES key is known by the hoster(s)?

• AES-256 is quantum-resistant. AES-CBC doesn't provide authentication. You want that since you don't trust the host. HMAC the ciphertext or use an AEAD mode. CBC requires padding, which could expose you to active attack by the host at restore time. You probably want an AEAD mode. If the AES key is known by the host, all security guarantees are void. – SAI Peregrinus Dec 28 '20 at 16:31

First of all, AES-256 is considered the gold standard on the market by the industry. The quantum attack on a block cipher is performed by Grover's algorithm that can provide at most quadratic speed up on the key search. The qubit requirements, setup, and running time even for AES-128 is not easily solvable in a near future, and AES-256 is safe. The below table is from

$$\begin{array}{cccccc}\hline & \#gates & & depth & & \#qubits\\ k & T & Clifford & T & overall & \\ \hline 128 & 1.19 \cdot 2^{86} & 1.55 \cdot 2^{86} & 1.06 \cdot 2^{80} & 1.16 \cdot 2^{81} & 2953 \\ 192 & 1.81 \cdot 2^{118} & 1.17 \cdot 2^{119} & 1.21 \cdot 2^{112} & 1.33 \cdot 2^{113} & 4449 \\ 256 & 1.41 \cdot 2^{151} & 1.83 \cdot 2^{151} & 1.44 \cdot 2^{144} & 1.57 \cdot 2^{145} & 6681 \\ \end{array}$$

Does it increase the security of my data if I split the CBC chunks to let's say 2 clouds? Uploading the even-numbered CBC elements to e.g. Google and the odd-numbered elements to Amazon. Since one storage hoster is constantly missing the next part of the CBC-Chain (1/2 in total) shouldn't this increase security of the data even if the AES key is known by the hoster(s)?

This is a security question on unidentified risks. What if both X and Y are combining their power or they are forced by the government to combine the data, so no benefit there.

What if a huge regression occurs and one of the companies goes out of business so fast. Will you able to get the other chunk? and even in a more catastrophic scenario that your copies are already corrupted.

The hard disks are failing, DVDs degrading, computer systems are not perfect, etc. Solving these is out of Cryptography, the common techniques are multiple copies and raid system like NAS.

Your main issue is the integrity and authentication of your data. To solve this issue you need authenticated encryption and for CBC you can achieve this with HMAC, or better you can use authenticated encryption modes like AES-GCM, Chacha20-Poly1305 those will provide Confidentiality, Integrity, and Authentication. Each has pros and cons mainly take care of the $$(IV,key)$$ reuse problem.

I disagree that it is a foregone conclusion that it will one day be practical (or even possible) to brute force AES encryption keys. See Calculate time taken to break AES key and https://crypto.stackexchange.com/questions/1145/how-much-would-it-cost-in-u-s-dollars-to-brute-force-a-256-bit-key-in-a-year/1148 for some interesting reading on this subject - especially the references in both of these to the physics that Bruce Schneier worked out, as it pertains to this problem.

Notwithstanding, this is an interesting idea. The first thing that comes to mind is that you would want to store the IV with the service that is not storing the first block of ciphertext. Otherwise, the service that has the IV and the first block of ciphertext can attempt to brute force the encryption key, using the first block of ciphertext (if they have some idea of what the first block of plaintext should be).

Of course, all bets are off if the two services merge in the future, or decide to collude.