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?

  • 1
    Then I understood that encryption can eventually be broken given enough time. If enough time is the age of the universe times the age of the universe, then you're absolutely correct. Only neither the data, nor will you survive that long. Jan 31 at 20:32
  • 3
    "Then I understood that encryption can eventually be broken given enough time." - This assumption is wrong, at least with "in enough time" in the meaning of "in practically relevant time". I’m voting to close this question because it is based on false assumptions. Also, if your data are that important that somebody would be willing to spend huge $$ to crack it, then they would likely just use cheaper and faster methods described in xkcd.com/538 Jan 31 at 20:35
  • 3
    @user9203881: If you don't trust any cryptography in general then you should not ask about "cryptographic techniques that could somehow circumvent that issue". If you worry about the security of specific algorithms combine multiple algorithms (i.e. encrypt with algorithm A, then with algorithm B ...). But, it is likely much more a problem to long-term protect the secrets used to encrypt the data against loss or leak, than using long-term algorithms for encrypting the data, i.e. the weakness is not the algorithm but protection of the keys. Jan 31 at 21:48
  • 1
    @user9203881: See Kerckhoffs's principle. Security through obscurity does not give any security. You should assume that the attacker knows everything about your software and about your processes. This includes splitting files and storing parts separately. The only thing unknown to the attacker is the password. Your security should rely on the strength of encryption method and strength of the password. Symmetric encryption (AES, ChaCha20, ThreeFish, ...) is the best what we have now days.
    – mentallurg
    Feb 1 at 7:10
  • 1
    @user9203881 You are over-simplifying the issues and then wanting a simplified answer. things don't work like that. Is there a risk that an encrypted archive could have a weakness that emerges in the future that would allow someone with access to the archive to decrypt it? Of course, but you can see the layers of things that would need to happen. So, then, "shouldn't we refrain from transferring encrypted archives to a remote server"? No, that's too simplistic of a reaction. It's a risk that needs to be weighed.
    – schroeder
    Feb 1 at 13:22

3 Answers 3


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.

  • Good answer! The caveat with strong keys is that those keys must not only be truly random, but must then be stored in a secure manner. This is the difficult part. And part of why the 2022 LastPass breach was so disastrous is that some encryption keys were derived from weak passwords by a weak method. Quantum computing is effectively irrelevant here, because AES doesn't rely on the types of problems where quantum algorithms are known. If OP is really concerned about this, they can nest multiple encryptions (with different keys!) so that an attacker would have to break all of them.
    – amon
    Feb 1 at 13:55
  • Good answer, but a small nitpick, which I'm throwing out for criticism too: most of the encryption is based on PRNGs so there are always seeds used afaik, MEANING that given enough information (in this case TLS packets) or entropy variety you can determine the initial seeds and the forthcoming values. For more info see youtube.com/watch?v=-h_rj2-HP2E Feb 1 at 20:05
  • Another small nitpick - " a 256 bit random key will not be cracked.". I would add if you're lucky ;) Feb 1 at 20:07
  • 1
    @SirMuffington - I'm glad you bring that stuff up. Many details like that are not discussed enough. One of the biggest is that no one has ever been able to mathematically prove the advertised security of any of the widely used symmetric cipher algorithms! The symmetric cipher that we have a security proof for is practically useless in most cases (OTP). Then there are the "smaller" technical details: mode of operation, key storage, entropy sources, etc... the catch is of course, if any of those "small" technical details fail, the entire security collapses. It's a real house of cards :)
    – Amit
    Feb 1 at 21:53

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.

  • If backups are properly made (on multiple devices) then it's not a problem to lose access to one of the split files: those two remote servers count as one in this case, and you shall never have just one backup in my opinion. Do you know if it's possible to make the (split) data unrecoverable by sending those encrypted split archives to two separate backup servers? Feb 2 at 16:23
  • It's possible to split data and send to different backup servers, but you have to assume that an attacker that gets access to your system will get access to the backup procedure, the servers, and credentials to those servers.
    – ThoriumBR
    Feb 3 at 14:54
  • I don't rule out the possibility, but my question was mostly about what happens outside of my (small) server Feb 4 at 18:08

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 :)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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