Encryption Experts

I have a TrueCrypt container which uses AES-Twofish-Serpent encryption with a RIPEMD-160 hash. The password for container is 20 characters long containing uppercase, lowercase, symbols, and numbers.

Within the container are several documents which are encrypted with AxCrypt. I believe this uses AES with 128-bit keys. The password for these files are 14 characters long again containing uppercase, lowercase, symbols, and numbers.

My question is this, would the TrueCrypt container file be safe if hosted online? I was thinking of using DropBox, GDrive, or even SkyDrive to keep a backup online. Exactly how secure would the files be if I did this?

 

If only the encrypted file is put online (and the unencrpyted version is never moved online) there's no issue - no one is getting in.

 

So there is no chance of a brute-force attack on my container with the settings I have?

 

No, there is not.

 

Doco,

Even though Hungry man has already responded to you, but after reading your initial post, I had to to respond. I mean, holy cow man! what is so confidential that you have to encrypt it over and over 4 times! So, you have documents already encrypted with AxCrypt (AES), then you are going to put these documents in a container that is encrypted in cascade with AES-Twofish-Serpent! and then you are asking if someone can crack this by brute force! I mean, come on, this is already too much overkill of encryption. You can just upload your original AxCrypt AES encrypted documents and they are going to be fine, impossible to break with brute force.

On a side note, you should change your hash algorithm to a 512 bit one over the current 160 bit RIPMED. Either SHA-512 or Whirlpool will do fine.

 

This is way over my head, lol...guess I have a little homework to do....I have felt secure using VPN4ALL, and Comodo Secure DNS server, now, I'm thinking I haven't scratched the surface on security....

 

Extremely unlikely with a 20 character password. It would take supercomputers many many years to even begin to break it.

I routinely encrypt my important files and back them up to the "cloud." I am not worried about NSA, which would be the only organization on earth with any hope of breaking it.

 

It doesn't really matter which hash algorithm you use. Even if an attacker were bruteforcing MD5 at 20 characters it would take longer than the span of humanity and more energy than is available on the planet.

 

I'm going to throw out counter thoughts, because someone should.

Once you've uploaded a file to someone else's server you lose control over that file. Those that have access to the server will have access to your file. You should assume that additional copies will be created due to backups. You will have no reliable way to know how the file and its copies are handled. You will have no reliable way to know whether others acquire unauthorized access to that file or copies of it. You can never, in a verifiable sense, delete that file and copies that are made.

If the file hosting service advertises the use of encryption to protect files at rest and/or before upload, that has to be investigated very, very carefully. Since things are under their control it is arguably best to never rely upon that and to use your own method of encryption before the file ever touches their uploader. You are already on the right track there.

Remember, the time it might take for an opponent to successfully attack your encrypted file would be a range. The upper end number would be based on the attacker having to run through all possible other combinations before hitting on the correct one. The lower end number would be based upon the attacker happening to start with the correct one.

You just posted details of your encryption scheme in a public forum, which would certainly help someone if they could correlate your post with the file they acquired or the account they acquired it from. That's assuming you posted accurate info of course, which very well may not be the case.

We don't know what the future will hold in terms of break-throughs in computing power, attacks on encryption algorithms, etc. Your opponent could be someone in the future who is using a much more effective means of attack than what is available today. Take no comfort from the idea that you aren't important enough that someone would do this, because your file could just be one of the ones they happened to acquire.

It is best to maintain positive, physical protection over your files to the extent that you can. Unless you want a file stored in a distant location to protect against disaster and/or you want to frequently update or access the file, using a device stored at a nearby very trustworthy relative's home would arguably be a better solution than putting the file online. Even a safe deposit box would, I think, be better than putting it online. Assuming there is enough space between the storage location and your location that both wouldn't be taken out by a local disaster of some sort.

 

And at 20 characters it makes no difference. Even at 16 characters with half decent hashing it makes no difference. Or 8.

There's a reason you don't have to enter the hash used and encryption method every time you unpack an encrypted container via truecrypt - the information is already available.

Right but energy constraints won't change. Even if we took every super computer and threw out the energy constraints it wouldn't matter.

There's simply no way it's getting cracked without some ridiculous flaw in the encryption that somehow reveals everything, which wouldn't happen.

Even if we get some quantum algorithm for symmetric cryptography that can do a quadrillion guesses per second it would take literally trillions of years to crack a 20 character random password.

On top of that there are 14 character encrypted files within that. At another quadrillion guesses per second you're still going to be cracking for centuries just for those files alone.

For that quadrillion guesses you would need:
1) New technology that uses far less energy than anything we have now and works (with tha tless energy) 1,000x faster than anything we have now.
2) A huge network of these machines.
3) More time than the solar system's got (probably the galaxy, pretty sure we're set to collide with Andromeda in the next quadrillion years or so).

 

How is there no difference between running through all possible N characters vs *just happening* to start with the *correct* N characters?

 

Because even if you split the time it would take in half (averaging the highest and lowest possible combinations) it's not feasible.

For a 20 character password you go from practically a quadrillion years down to hundreds of thousands of trillions of years. For a 14 character passwords its the high end of thousands of centuries to the low end of thousands of centuries. Basically as long as you hit 12 characters it's not practical to crack.

And this is assuming basically every major entity wants your password and they're willing to put billions in resources into it to rent out the most powerful databases etc. So if you've stolen data on secret agents and the locations of ICBMs for a few countries you'll be A-OK.

 

There has been no discussion of password quality. Just because a 20-character PW contains uppercase, lowercase, numbers and symbols does not mean it is a strong password. If the PW consisted entirely of random characters then it would be quite strong, but suppose it contained mostly repetition? Is "D0g................." safe? Most assuredly not. It can be easily guessed (see Steve Gibson's "password haystacks" example), and it can also be brute-forced within a reasonable amount of time if the brute-forcing algorithm is designed to test for these types of passwords.

 

No it's not. There's no way to tell this in advance (unless the user chooses to make the information available, which he just did). TrueCrypt has to test all of the possible combinations until it finds the one that works. If the attacker can obtain this information in advance then he can save a considerable amount of time by skipping the unnecessary combinations.

 

But what if our opponent has above average luck? Really really really really above average luck? Anyway, I've at times thought of maintaining an online backup somewhere and I'd probably use TrueCrypt if I did it. I never thought it out, but one idea that popped into my mind was to make a reversible modification to the container file (XOR/grow primary header, XOR backup header) before doing so.

 

I'd have to argue this point a tad (More myself being nitpicky). While currently I'd agree we don't have the means yet, but the technology is quickly advancing. No one can say what the future holds or when technology will catch up to old encryption standards, and I won't even claim to really know.

However one thing I've learned over the years is never say never, encryption key guess times lower as different computing methodologies emerge and or new attack vectors are found. All it takes is one advancement/discovery to lower those computing times drastically, they are not set in stone nor the power to process them.

I'd even go as far as to say if the password is reused, i.e victim of one of the many data breaches over the past 5 years? All those passwords end up in publicly available word lists to run through. If it truly entropic then 20 characters in 2012 is plenty.

 

Here's the thing. I'm talking about quadrillions of passwords per second. That's already like we clustered the worlds super computers together without bandwidth/ energy restraints. (Remember we're talking about RIPEMD-160 which is only slightly faster than SHA512.)

At that point it's still trillions of years.

So even if we were to drop that drastically... it's just not feasible. Even if quantum computers somehow got optimized for symmetric crypto and they were 1000x faster than current system we're talking about millions of years.

And then maybe we drop a new tech bomb and we're talking another 1000x faster, ok then maybe we start getting down to the thousands.

And then we tap into some infinite energy soruce and just go nuts another 100,000x the speed. Well then sure they'd crack it in maybe a few months. And then they're stuck with a bunch of 14 character passworded files that still need to be cracked for a few more weeks.

So the conclusion here is that if you think your data is so important that a super intelligent race will be willing to put in the effective power of a couple thousand nukes to crack your data over a long amount of time yeah - jump up to 21 or 22 characters and put it off another couple thousand years.

I mean, as long as you can put it off about a quadrillion years it's fairly safe to assume life'll be done at that point anyways.

 

A 20 character password that is generated randomly from the standard 95 ASCII characters has 131 bits of entropy. If you had a CPU that could make one billion guesses a second and if you put one of those CPU's on every single inch of the earth's land surface, it would take them ~235,000 years, on average, to crack the key. And, of course, that says nothing about the energy requirements (we would need the energy of the sun).

BTW, I calculated this with a password generator program I wrote, which does it automatically each time a password is generated.

Now, all of this is true and it sounds really cool, but reality is not so great. Why? Well the above assumes none of the below are true:

1) Your adversary has not found some way to cryptanalyze the cipher successfully. For all we know NSA has already broken AES (there's been some rumors about it in the press, but no one really knows for sure). You could use a 100 character password, but if the cipher is broken, it wouldn't help.

2) Your implementation of said algorithm is correct and has no bugs.

3) Your RNG is correct and well designed. This isn't always the case as the RSA key fiasco recently showed.

4) Your hardware and/or OS has no backdoor in it.

5) You and only you have had physical access to the machine.

As you can see, the caveats get pretty large. This is why when people ask about which cipher and keylength to use, I always tell them it doesn't much matter. The cipher is by far the strongest part of the chain. There are *far* easier ways to attack your data than by attacking the cipher.

 

Cracking AES is fine if you're using multiple ciphers. I don't want ot get into another debate about the NSA having cracked it or not - there's 0 evidence to prove they have and it's that simple, any "belief" otherwise is purely a belief.

And I agree - cryptanalysis is not the way anyone's going to be breaking into these systems.

I'm confused as to how your program got that result. Entropy doesn't matter really - all that matters is avoiding a dictionary.

You don't get bonus points for getting close to a password, if the password is abcde and i guess abcdf I'm no closer than ever.

Character space of 95 with 20 characters: 3.62 x 1039 passwords.

Guessing each password would take 11.5 thousand trillion years at 100 trillion guesses per second.

 

Also we need to consider the fact that why would anybody waste this much resources to decrypt an unknown file, on an unknown server, belonging to an unknown person. So, unless you are the public enemy number one, of a technologically and economically superior country, you are okay with AES and a 8 bit or higher alpha numeric password.

 

Just a few thoughts. Just because there is no known vulnerability in an encryption algorithm, that doesn't mean that sometime in the future this won't happen. Let's say that 10 years from now a cryptanalyst finds a vulnerability in the encryption algorithm and it takes 3 months to decrypt the data and not the age of universe. Sure, until then, nobody will still use the vulnerable algorithm, but because your data is online and you lost control over it, you will not be able to switch to a secure algorithm and someone might be able to access it.

Of course this is just theoretical, and using multiple algorithms to encrypt data helps mitigating this risk, but what am I trying to say is that there is no ZERO risk when it comes to encryption.