If all encryption schemes are eventually broken, shouldn't we avoid sending encrypted archives to a remote server?

Question

I need to protect a few gigabytes of private information. I had the idea of encrypting them and placing them in a 7z archive, which I would then upload hourly to a cloud storage provider.

Then I understood that encryption can eventually be broken given enough time.

While I wouldn't say it's realistic to expect our encrypted TLS traffic in particular to be captured by malicious actors ready to decipher it in a few decades (there's just too much data), data kept on a remote server, in my opinion, is a different thing.

Sensitive data leaks from servers are occasionally reported. Furthermore, an unauthorized person may eventually access the system and steal the encrypted data.

In light of this, shouldn't we refrain from transferring encrypted archives to a remote server? Cloud storage is very useful in theory, but I'm not sure about how realistic is the scenario I'm mentioning.

Are there any cryptographic techniques that could somehow circumvent that issue—the decryption of stolen encrypted data in the future?

An idea: Maybe splitting the archive in two and uploading each one to a different cloud storage server, if that makes sense?

Answer 1

When calculating the "strength" of an encryption algorithm, there are three things you need to look out for.

1. The computational power required to brute-force the algorithm.
2. The likelihood of a vulnerability, which reduces the computational power required. (e.g. Meet-in-the-Middle attacks)
3. The likelihood of making the algorithm trivial to crack.

Let's look at each of these and how they affect your scenario.

1. Computational Requirements

These are very well understood. For example, AES-256 uses 256 bits of random input as key. As long as your random number generator produces sufficient entropy, a 256 bit random key will not be cracked. This is also the reason why there is no AES-512, AES-1024, etc. - it is simply not necessary.

But for algorithms such as RSA, small key sizes are quite practical to brute force. So if you use RSA with 1024 bit long primes, then it is certainly plausible that a sufficiently powerful adversary could recover the private key in reasonable time.

In short: To defend against the growing computational power available to adversaries, use algorithms, which are considered "unbreakable" by conventional hardware.

2. Attacks giving adversaries an advantage

There are certain cryptographic attacks, which don't outright break a scheme, but make it easier for an attacker to recover the key. For example, DES uses 56 bits of entropy, which is considered insecure and can be recovered on modern hardware within reasonable amount of time. "Double-DES" would be 112 bits, right? 56+56 = 112 after all.

Not exactly. There is an attack called "Meet-in-the-Middle" (YouTube explanation), which reduces the computational complexity from a theoretical 112 bits down to 57, which means it's 2^55 or 36,028,797,018,963,968 times more effective. This is a significant gain.

So how can one defend against such attacks? By using well-studied algorithms. In general, older algorithms have been studied extensively, thus making it rather unlikely for new vulnerabilities to be found. I'm not saying it's impossible, but AES has been published in 1998 and subsequently analyzed extensively both by the global cryptography community and nation state actors. So far, only side-channel attacks against AES have been discovered, but no attacks, which offer significant advantage compared to brute-force.

Does this mean no attacks against AES can ever be found? No. It just means it is very, very unlikely that after 25 years of research, someone has a "Eureka!" moment and shows how this one weird trick can be used to crack AES.

What about quantum computers?

That is a great hypothetical question. Quantum computers already exist, but aren't yet powerful enough to pose serious risks. There is a whole field dedicated to this, called Post-Quantum Cryptography. It may be worth looking into this, if the lifetime of your data is sufficiently long. Again, this is still a small risk overall.

Answer 2

Then I understood that encryption can eventually be broken given enough time.

That time could be in the trillions of years. Or more. So it's good to encrypt things.

What can change the time to break encryption is the strength of the key (or the password). If you encrypt data using a standard procedure (AES-256, for example) generate a password large enough (16 random bytes or more), and protect this password so nobody gets it, it won't be cracked in the next couple billion years.

Furthermore, an unauthorized person may eventually access the system and steal the encrypted data.

That's why sensitive data must be encrypted. If there's absolutely no way for an unauthorized person to steal the data, there's no point in encrypting it.

Maybe splitting the archive in two and uploading each one to a different cloud storage server, if that makes sense?

It makes sense to encrypt the data and send copies to multiple providers. You don't want to upload the data to one single provider and risk losing it all if the provider gets out of business, if there's a disaster or something else that erases your files.

Answer 3

The following answer may sound heretical to some people, please don't jump on me for this :) I would love to hear criticism of course, this little prelude is only to promote openness.

Normally in Cryptography and Cybersecurity in general, obscurity is frowned upon. A lot of that has to do with standardization and compliance: if you're a customer of a corporation and trusting it with your private data, you won't accept a statement such as "we have great cryptographic protocols and security measures in place to protect your private data, but we can't disclose them, they are secret!", that would be ridiculous, right?

Now, I am pointing this out in order to emphasize that your situation is different. You want to protect your own private information and you can do that in any way you see fit, you are not bound by any compliance. In particular you may:

1. Use your own, "crazy" home-made crypto algorithms, which can either be partially based on existing standard ones, inspired by them, or completely unrelated to them.
2. On top of that, also employ standard "trusted" algorithms in a completely standards-compliant manner. The one doesn't contradict the other.

Now, the heretical suggestion is that for your private information you are probably better off doing just that. Let's suppose that in 20 years someone finds an attack on AES-256 that recovers any key in 10 seconds (why not). Now, by all means you may add an AES-256 encryption layer to your private data, but you're certainly better off if there's also a "secret algorithm" layer in addition to that, which protects your data. Even if the secret algorithm is weaker or as weak(/strong) as AES-256, you are still likely better off because anyone just grabbing your data and trying his favorite "Decrypt everything" tool in 20 years, will not be able to decrypt your secret algorithm.

Of course, once you develop your own secret algorithm, there are new pitfalls to consider: what happens if you lose it (that would be conceivable since by construction you don't want a lot of copies of this code hanging around) or, what happens if it gets leaked out. So you certainly need to be wary of such problems, should you choose to apply such a technique.

Again, I hope I am not rocking too many boats with this answer :)