TrueCrypt Security Assessment [pdf]
opencryptoaudit.org
opencryptoaudit.org
Until TrueCrypt gets patched to use scrypt for key derivation, roughly how long should a volume password be to put it out of reach?
Edit: There's a table in the scrypt paper from 2002 [1] that estimates the cost of various brute force attacks. Back then, a PBKDF2 iteration count of 86,000 and a password of length 40 would cost $200K to crack. TrueCrypt's choice of 1000-2000 iterations look staggeringly low in comparison. And that's not even accounting for hardware advances in the last 12 years.
[1] page 14, http://www.tarsnap.com/scrypt/scrypt.pdf
If you're using AES-128, if you have a random password with a 128 bits of entropy it shouldn't matter what key derivation function you use. That means, if your password can contain any printable ASCII character, a password length of 20 would be sufficient [1].
The huge caveat here is that the password has to be random, and most people are either incapable of remembering such a password or have no way of securely storing it.
But I have no qualifications in this area, so don't take my word for it...
[1] http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_...
You are wrong about the key derivation though, and here's why: A key-derivation function that is very cheap and fast to calculate means it is easy for an attacker to brute-force lots of passwords to find one that matches your key. Using a slow, expensive KDF makes an attack much less feasible, by a factor of a thousand or more.
With that said, if your "key" actually consists of 128 bits (16 bytes) of secure random data (with all the conditions associated with that), then you're right: the choice of KDF is mostly immaterial, so long as it preserves entropy. That's why, for example, if you're just generating a symmetric key for bulk encryption, you just grab (say) 128 bits of random data and use that as the key directly with no KDF involved.
KDFs really only enter the scene when: (1) you want to generate multiple keys from one "master key" or (2) you want to generate "secure" keying material from "insecure" keying material (say, a user's password).
The choice of KDF, however, mostly depends on the strength of the original keying material. For instance, if you have 256 bits of secure random information as your keying material, using something like scrypt is unnecessary; something like HKDF would be more appropriate there. (No one will ever brute-force your 256-bit value. It's just not happening: ever.) On the other hand, where the original keying material is weak, like in the case of passwords, you want to use something that prohibits rapid guessing, e.g. scrypt.
> By using a key derivation function which requires 2s cryptographic operations to compute, the cost of performing a brute-force attack against passwords with t bits of entropy is raised from 2t to 2s+t operations [19].
1,000 iterations is just shy of 2^10.
Bear in mind that's a 40 character english text password which they estimated at 56bits of entropy.
40 completely random characters is ~1x10^79 (95^40 - assuming a character space of 95), i.e. 100% completely infeasible to crack forever, even if you could do a hundred trillion guesses every microsecond
100bit entropy is probably fine to avoid brute force attacks for the foreseeable future, which is around 16 completely random ascii characters (95 character space)
The goal is to make it at least as difficult to break the master password as it is to simply brute-force the resultant symmetric key. If the key is 256 bits long, this is true even for a one-round SHA256 KDF if the password has 256 bits of entropy. Of course, that's at least a fifty-character long alphanumeric password from /dev/random. A password structured for a typical human to remember it should probably be 5-10x as long or more to meet a similar standard.
Fortunately TrueCrypt does not use one-round SHA256, it seems to use 1000 rounds in a PBKDF2 construction. That doesn't mean we can use a password 1/1000th as long, because SHA256 is still very fast. Someone could use a Bitcoin ASIC to get a cost structure where hashing 1000 times is about as costly as verifying the aes256 key.
Speculation: You can maybe go down to 25 random or 150-200 human-memorable characters.
It'd never work that way, right? You get to use a password with log2(1000) bits less. So e.g. if you use 2^24 iterations, and figure 80 bits is strong enough, then you can use a 56-bit password.
I was the first to crack the majority of the TrueCrypt volumes in the 2012 Defcon - Crack Me if You Can password cracking contest using TCHead running on an old Intel Celeron processor.
Write-up: http://16s.us/software/wm/Defcon/cmiyc_2012.txt
Contest Page (3rd table down): http://contest-2012.korelogic.com/stats.html
TCHead: http://16s.us/software/TCHead/
I'd love to see someone try. Here, an md5, those are super vulnerable right? This is a 9 character password. Piece of cake if I should believe the news.
f1f107c27cae21b5b5b01002e9c9ead8Fair enough. I'm still curious about the generation method though: I can imagine that testing all texts ever published takes $200k if you go up to 40 characters, but if you use a unique text it might be different. There are a lot of variables here, including honest misspellings, punctuation use, spacing (non-tech people seem to find spaces weird in passwords), capitalization, usage of names, etc.
It bugs me that even today, more systems (hello banks) don't support more open passwords. Even what's on a US Ascii keyboard would be nice. Two of my banks only support letters and numbers, no special characters and case insensitive.
I think while typing them in is when they are most susceptible to being stolen.
would be more appropriate
Using non-optimized, managed code on my laptop, I just went through 250 million iterations of plain text in ten minutes. You didn't specify what counts as a character, but let's assume it's a printable ASCII character. 95^9 = 630249409724609375 possibilities.
Divide by 250 million, and we get about 2520997639 times ten minutes for the time it would take me to enumerate all possible plain text passwords. That's a long time, about 47000 years. Not going to happen today on my laptop. But if I were a government, maybe I'd get a few thousand laptops together and set about calculating this over the next five years or so. In 1997.
But if I were to throw some purpose built hardware at this problem or use the video card to speed this up and not just laptops with general purpose CPU's, it's very likely I could decrease this time by thousands of times.
At the end I's have all MD5's for all passwords, and now the problem becomes a rainbow table lookup. And I only have to do this once and I forever gain the capability to break any 9 character (and below) password with just a lookup.
And that's assuming that MD5 is a perfectly secure hash with no shortcuts allowing you to narrow down the input set.
[1] https://www.wolframalpha.com/input/?i=%28630249409724609375+...
(Edit: Also being limited to alphanumeric for hashes and printable ascii for input gives you pretty good compression potential.)
Precomputed hash chains are a simplistic way of explaining how rainbow tables work. http://en.wikipedia.org/wiki/Rainbow_table#Precomputed_hash_...
Oh I thought you were going to say per second. I can recall reaching 500 MHash on some 2008 nvidia gpu with barswf.
Anyway, you're right of course. A nine character password is not really military-grade safe for countries with a security budget like the NSA's. But 9 characters ought to be many, orders of magnitude easier than 40 characters, and md5 is many orders of magnitude easier than pbkdf2 even at a weak security setting. This md5 might just be within reach of governments, but 40 characters certainly isn't.
For some fun performance figures, check http://golubev.com/gpuest.htm
A new AMD Radeon™ R9 295X2 is pretty speedy, clocking in at 23GHash for single MD5 (there are cheaper per $, but this is extremely impressive imo). Dividing 630249409724609375H by 23e9H/s leaves us with 27e6s, or 0.8 years. That means we'd need 42 cards to crack it in a week, costing somewhere in the region of $80k (1.5k/card + extras). That puts us easily within the range of governments, companies and just generally rich geeks. You can get ~ twice the hashes/$ so maybe $40k, and if you're cheap about the computers you connect with then probably lower.
But that's consumer kit. There are also speedy MD5 FPGA cores, I've not got a great reference but found one from 2007 which did 44MHash / core using a Cyclone II which I can only find described as "built for low cost". Assuming a 5x cost/hash reduction would grab us at $8k which would be in the range of hobbyists.
Beyond this, several private companies have been able to build double SHA-256 ASICs (for bitcoin mining). You could buy a while ago kit that did 7GHash for $300ish, and there's supposedly some 1THash ones in development. Granted, double SHA-256 is not equivalent to MD5, but I'd be surprised if MD5 was significantly harder, and expect it to be a lot simpler. Now the development cost of these is the expensive bit, but then your hashing rate would be insane.
Ramble over, if anyone has any figures for FPGAs or ASICs then I'd be really interested.
If you have a decent GPU, you can try several billion MD5 hashes per second: http://www.golubev.com/hashgpu.htm -- so if you stick with, um, lowercase alpha only should be crackable in under 10 minutes. If you choose from the 95 or so printable ASCII chars, you can expect a bit more of a wait (possibly a few years)... though of course if you don't restrict yourself to a single GPU you can speed things up.
Honestly, using an actually-random password that's more than 8 chars and not just alphanumeric offers decent security even when it's stored with a fast hash algo. Unfortunately, very few people do this in practice, and instead choose (for example) one of the 43 billion passwords in the md5 database here: http://www.md5decrypter.co.uk/
Use case: Say you pass the UK border, and they can willy nilly decide to check your laptop or mobile phone. But you have an account that is password protected and encrypted, and they see that, and ask you for your password. You say no - and you get arrested for it. If they couldn't see you have that password protected account, and all they could see is a "normal" (clean of sensitive stuff) account, then they'd just check that and move on. Or you could even password protect that, too, and give them the password to it, and they'd be none the wiser.
All you'd need is to be able to hide that account from the main screen when you turn on the laptop or mobile device, and you should only be able to re-enable it from a menu prior to booting into the OS. It shouldn't be easily accessible either, otherwise it defeats the point.
I don't see Microsoft doing something like this - ever. Apple might if enough people asked for it, but I'd incline to say they wouldn't for now. Google probably won't do it either for Android or Chrome OS, since they probably see no benefit to it. But it would be nice if that feature at least came to Linux and some custom Android ROMs like Cyanogen.
[1] http://en.wikipedia.org/wiki/Deniable_encryption
[2] http://www.truecrypt.org/docs/plausible-deniability
[3] https://www.schneier.com/blog/archives/2008/07/truecrypts_de...
Could that be mitigated by having TC occasionally randomly write random data to unused blocks?
You have to consider the adversary. Are you a non-targeted individual who want to keep some things private from a spurious search by law enforcement or border agents, then simply the ability to boot up and not have sensitive stuff and not have an obvious encrypted partition lying around will do the trick.
If, on the other hand, you're targeted by someone with a strong reason to believe that you are hiding stuff on your computer, maybe even someone who will break into your apartment every day to image your computer, you're gonna have a bad time (and a keylogger on your computer, but that's a different kettle of fish). Basically, evidence of the existence of your hidden partition can leak out into the real world, not because of bad cryptography, but because you're human.
Its worth pointing out that his concerns seem to apply only to using Truecrypt to encrypt a portion of a drive, as opposed to whole-disk encryption.
Another issue is that you never know if the border patrol is going to add some unwanted monitoring software or hardware to your computer. It seems unlikely but with the NSA revelations we had I wouldn't be surprised anymore.
If you want to hide the presence from a disk image (for example), then it will be much more difficult. Truecrypt's hidden partitions can make it difficult to prove that the hidden partition exists, though if you're not extremely careful then circumstantial evidence can point strongly towards it.
Many modern laptops have an mSATA port in addition to a regular 2.5" SATA hard drive. If you install a tiny SSD in the mSATA port and move your OS to the SSD, you can enjoy the speed of SSD without giving up the capacity of the hard drive.
But what if you installed a large (480GB or 960GB) SSD in the mSATA port and used it for all of your storage needs? Then the regular hard drive becomes completely redundant. But TSA agents are not known for their tech savvy, so most of them will not realize that you're not even using the regular hard drive.
So put a decoy OS on the regular hard drive, with no encryption whatsoever. All the encrypted stuff goes on the mSATA SSD instead. Prior to the trip, configure your BIOS to boot from the regular hard drive, and dislocate the mSATA SSD just a couple of millimeters in its slot so that it's not even recognized. When the agent boots the laptop, all he's going to see is a clean OS that takes up the entire hard drive, and even if he takes a disk image, there will be nothing suspicious on it.
Now you only need to make up some story along the lines of your computer crashed last week and you had Geeksquad reformat it but you didn't have time to copy all your family photos back from the external drive at home.
Well, now that I've spilled the beans on HN, they'll probably try to pull my mSATA SSD the next time I try to enter the US. Shit.
How would you be able to hide this from police once such feature is built into every OS?
Assuming that feature by default asks for a password regardless of whether such protection has been enabled by the user or not (first time setting up the device/computer) -- so that no information is leaked on whether the user IS actually using the feature -- I supposed the police can still arrest you or keep you longer there to investigate whether you are lying or not.
Follow TrueCrypts recommendations (FDE, long password) and you're mostly fine. The only things that can make it better require program changes.
No massive exploits; the worst problem was using too small a number of iterations of a keygen.
There were a bunch of other minor problems, but most of them were information disclosure only trigger-able by malicious software running in the encrypted environment (ex: finding out if a file you don't own exists) or things that could only be triggered by someone with raw access to the hard drive (at which point they could just overwrite your bootloader)
Although this explicitly doesn't cover a large chunk of TC.
Total High severity issues Zero (0)
Total Medium severity issues Four (4)
Total Low severity issues Four (4)
Total vulnerabilities identified Eleven (11) (incl. three (3) Informational)> Calls to memset() run the risk of being optimized out by the compiler.
I would be curious to know which compilers or which options actually still do these ill-fated optimizations?
char* plain_text = malloc(size);
///do stuff with plain_text
memset(plain_text, 0, size);
free(plain_text);
1- Try to use SecureZeroMemory() on Windows
2- Use memcpy_s() if available, which from its manpage is guaranteed not to be optimized away by compilers
3- Use a loop to manually zero-out the buffer after having casted to a volatile pointer, again to prevent compiler optimizations
It's typically done when you don't need the value anymore, of course. So, the compiler sees a write to memory that is never used. Which is exactly the type of thing compilers try to optimize out (if it can be proven that it is never used).
From the C99 standard:
In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).
Everyone always talks about Truecrypt which is clearly most popular but both of the above are fully open-source. The latter is even part of the kernel. I'm curious what the appeal of Truecrypt is besides maybe portability (which is a pretty strong selling point).
The questionable license, and obscure nature of the project should be significant reasons not to use Truecrypt. That doesn't even begin to consider the actual security of the program.
The security assessment is for the Windows version of TrueCrypt only. Which also answers your question, TrueCrypt is appealing because it works on *nix, BSD, and Windows. It is also free and open source. The Windows version is easy to use, has a nice GUI and actually works as stated.
https://en.wikipedia.org/wiki/TrueCrypt#Licensing_and_Open_S...
Wikipedia lists it as "source-available".
TrueCrypt for example uses fixed and low pbkfd2 iteration counts as specified in the report.LUKS on the other hand uses adaptive pbkdf2 iteration count number that goes up automatically when a LUKS volume is created on a faster computer.
The appeal of TrueCrypt other than portability atleast among linux users is an easier to use GUI.Fortunately, there is a project called zuluCrypt[1] than supports TrueCrypt volumes among others and has a GUI window that is comparable to TrueCrypt's GUI.
If you are a user of tombs,zuluCrypt can also open tombs through its "gpg" and "tomb" plugins[2]
[1] http://code.google.com/p/zulucrypt/
Die slideshare, die scribed.
Anyone know if something as small as a single microSD card positioned in the densest part of the suitcase will show up on an X-ray?
But, to answer your question, no, airport security screeners are not x-raying for objects of that size. If visible at all, it would be ignored.
That said, as a Truecrypt user, this is good. I don't have the technical expertise to understand truecrypt myself, but a second set of eyes (and all the eyes watching that second set) make me more comfortable. Follow standard security recommendations and you're pretty safe.
It's not that I want there to be bugs, but that in a large enough codebase, there's always a game-over bug -- major information leakage, arbitrary code exec, whatever. As a security consultant, I'm always more confident in a test when I find a horrendous bug than when I don't; I know that bug will be fixed, and it makes me feel like the test is more complete, even if I know full well that I did the test to the absolute best of my abilities regardless.
I've heard similar sentiments from most testers I know.
I can think of a particular discussion on the cryptography mailing list at randombit from ... two years ago ?
EDIT: Thought OP said Twofish
Whether this is of any significance depends on your adversary model. If the adversary controls your storage medium (imaging putting an encrypted container on Dropbox or Google Drive), they can mix-and-match (e.g. copy-paste) different versions of blocks from your history. Imagine your disk to be in a version control system; the adversary could pick the value of the block 1 from version 50, the value of the block 2 from the version 42, the value of the block 3 from the version 100 and so on. They could also potentially discover usage patterns (seeing e.g. that the value of block 3 remained constant between versions 20 and 200, while block 5 remained the same). Additionally, they could corrupt any of the blocks, by turning the corresponding plaintext into random bits.
Having a smaller block size means that they can perform any of these with finer granularity. Increasing the block size thus increases your security; ideally, your entire disk would be just one block (the only thing the adversary could do in that case is to completely restore an old version of the disk); but this is hugely impractical, since the performance would be abysmal (you'd have to re-encrypt the whole disk to change just one byte). So you have a spectrum of performance/security tradeoffs. Where on this spectrum the 1024-bit blocks lie, I'm not sure, but I suspect that they are better than 128-bit ones.
Note that we do have schemes which can do sector-level encryption (the EME mode), but they're not used since they're 2x slower than the schemes with smaller sizes.
Edit: in conclusion, for pretty much every scenario, other security concerns are much more significant than the block size :)
Given that the premise is that the adversary controls the storage medium, this point doesn't seem terribly interesting. I feel like I'm missing something.
Such an attack could not be detected, because the encryption modes commonly used do not provide integrity protection. This is due to the desire to have equal sizes for both the encrypted and plaintext sectors (as far as I understand, that's an efficiency/ease of implementation concern). Incidentally, you can easily see that such a scheme can never provide integrity, since the encryption operation has to be a permutation, and you have to be able to decrypt any ciphertext.
It's a bit disappointing that it hasn't seen more uptake since the SHA-3 competition. I think the tweakability and large block size makes it a more flexible primitive that AES, and even naive implementations should be constant-time. It's hard to compete with hardware-accelerated AES, though.
More likely iSECPartner's is the NSA's new RSA 2.0
> Page 8
"1.3 Findings Summary
During this engagement, the iSEC team identified eleven (11) issues in the assessed areas. Most issues were of severity Medium (four (4) found) or Low (four (4) found), with an additional three (3) issues having severity Informational (pertaining to Defense in Depth).
Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for secure code. This includes issues such as lack of comments, use of insecure or deprecated functions, inconsistent variable types, and so forth. A more in-depth discussion on the quality issues identified can be found in Appendix B....
The team also found a potential weakness in the Volume Header integrity checks. Currently, integrity is provided using a string (“TRUE”) and two (2) CRC32s. The current version of TrueCrypt utilizes XTS 2 as the block cipher mode of operation, which lacks protection against modification; however, it is insufficiently malleable to be reliably attacked. The integrity protection can be bypassed, but XTS prevents a reliable attack, so it does not currently appear to be an issue. Nonetheless, it is not clear why a cryptographic hash or HMAC was not used instead.
Finally, iSEC found no evidence of backdoors or otherwise intentionally malicious code in the assessed areas. The vulnerabilities described later in this document all appear to be uninte ntional, introduced as the result of bugs rather than malice."