Brute Force AES/Truecrypt with a simple password

[lupin]

What could truecrypt do to make the containers insusceptible to a password bruteforce?

I dont believe this is possible. Changing the password after a certain number of bad attempts means you need to be able to control the environment in which the password attempts are being made well enough to be able to make changes to the file under certain conditions. This basically means executing code on the TrueCrypt file, because the TrueCrypt file can only be changed if some sort of code runs. If the code to make this change is included in the TrueCrypt software, you just don't use the TrueCrypt software, or you edit that software to remove this particular bit of code. If the code is included in the TrueCrypt container, you either remove that code before attempting to crack the container or run the cracking process in an environment (like a debugger) that allows you to skip the appropriate password changing operations. Don't forget that this code would not be able to be included in the encrypted portion of the TrueCrypt file, because it would need to run before the file is decrypted.

BUT, to throw my own two cents in, simple password attempts prove futile when keyfiles are used. Also, it's a good idea to disguise containers as appropriately sized common files such as an iso, jpeg, or some random binary file. Who has the time to check the hash of every file in /usr/bin ?

There are ways to determine when keyfiles are used. One would be to check for files sitting alone on storage devices near the computer. Could that file be a keyfile? If you perform a forensic examination of the system and determine that that storage device was last inserted around the same time that the TrueCrypt volume was accessed, that's a good hint.

Another method is to check files that have a last access file stamp that roughly coincides with that of the TrueCrypt volume.

Also, you could check system memory to see if references to the keyfile exist.

Law enforcement, and other serious adversaries definitely have time, and the tools and techniques to confirm what files are what. And really, products like Encase can do most of the work for them. Its easy to eliminate large numbers of irrelevant files by using hash databases of known files and examining file magic which can tell you what type of file it is regardless of extension, which then allows you to concentrate on the much smaller number of unknown files.

A good piece of advice there vvpalin.
Making hidden containers inside one another is a great way to protect your data if you are very paranoid.

Yes, this is the most secure method. However it also imposes some significant use restrictions, such as using your decoy OS as much as your hidden one if you really want to maintain your plausible deniability, and it restricts the space available to your decoy OS.

It would require some real discipline to use this regularly, so Id suggest this as a method for the real "tinfoil hat" paranoids, or for those who have serious adversaries who would be able to use coercion to obtain a regular TrueCrypt password. Its probably overkill for most regular people. Don't forget security often involves a tradeoff with time, convenience and cost and too much security can be wasteful.

Does anyone here really use a hidden OS with TrueCrypt for regular use, and follow all of the secure use procedures?

[Archangel-Amael]

Here are some good resources to help those that may be interested in learning more

here
EDIT : changed this link here is more on the theme from above.

AES in general. More in depth on cryptography here
Laws of entropy here.

Just some good information to have available.
As we stated previously a good source of info on the subject is from the book secrets and lies.

[imported_vvpalin]

Here are some good resources to help those that may be interested in learning more

here
here is more on the theme from above.

I knew that if someone got ahold of your system while it was running with the right tools they could grab your pass, however i had never heard of memory degradation over time so i looked it up on the trucrypt site.

"Inherently, unencrypted master keys have to be stored in RAM as well. When a TrueCrypt volume is dismounted, TrueCrypt erases its master keys (stored in RAM). When the computer is cleanly restarted (or cleanly shut down), all TrueCrypt volumes are automatically dismounted and, thus, all master keys stored in RAM are erased by the TrueCrypt driver. However, when the computer is reset (not cleanly restarted), when the system crashes, or when power supply is abruptly interrupted, the TrueCrypt driver stops running and therefore cannot erase any keys".

Since i figured as long as there was no power then there was nothing to worry about i had never even thought of a clean shut down.

In other words thank you for posting that link

[lupin]

Some more on the subject.

Here's a link about a plugin for Volatility (a python based memory analysis framework) which allows Truecrypt passphrases to be found in a memory image. It also contains a link to a paper on the subject.

http://jessekornblum.livejournal.com/246616.html

[Archangel-Amael]

I knew that if someone got ahold of your system while it was running with the right tools they could grab your pass, however i had never heard of memory degradation over time so i looked it up on the trucrypt site.
In other words thank you for posting that link

No problem and I also changed one of the links above to the page that I meant, instead of two links to the same page.

Something else that I wanted to add since there may be some misconceptions (in the thread) about breaking with brute-force.
When using Truecrypt (tc) not only do we first need to find the encrypted data (which is hard enough) then we need to know the type of hash used as well as the type of encryption used. For the sake of the conversation lets say we have this info.
1st we need to know that with tc the password/phrase is salted with 512 when it is hashed. So for a 4 bit password you would (for a bruteforce tool) 16 different permutations of the password. Now for 512bit hashes as used by tc then one would need
13,407,807,929,942,597,099,574,024,998,205,846,127 ,479,365,820,592,393,377,723,561,443,721,764,030,0 73,546,976,801,874,298,166,903,427,690,031,858,186 ,486,050,853,753,882,811,946,569,946,433,649,006,0 84,096
possible permutations.
So think about the storage needed for one possible password.
Now if we have no idea what the password is then the amount of storage for creating a bf would be impossible.
This takes us back to the above reference to side channel attacks such as the cold booting of ram modules.

EDIT:
Also wanted to touch on the fact that it may be even given the correct resources and time that aes may still be unbreakable..
The resources required for a brute force attack scale exponentially with increasing key size, not linearly.
Meaning that doubling the keysize does not mean one would need to double the number of operations required to crack the key.
It would in fact square them. The Von Neumann-Landauer Limit is probably going to take over.
All of this may take some a bit of time to digest but having said that if there is a need to further discuss it I am all ears, and would love to.



EDIT: here is a nice video of the aes encryption process.
This link will show also how it is not easy to recover the password using known brute-force techniques.