TrueCrypt Security Assessment [pdf]

<i>The iteration count used by TrueCrypt [in its PBKDF2 key derivation] is either 1000 or 2000, depending on the hash function and use case. In both cases, this iteration count is too small to prevent password guessing attacks for even moderately complex passwords.</i><p>Until TrueCrypt gets patched to use scrypt for key derivation, roughly how long should a volume password be to put it out of reach?<p>Edit: There&#x27;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&#x27;s choice of 1000-2000 iterations look staggeringly low in comparison. And that&#x27;s not even accounting for hardware advances in the last 12 years.<p>[1] page 14, <a href="http://www.tarsnap.com/scrypt/scrypt.pdf" rel="nofollow">http:&#x2F;&#x2F;www.tarsnap.com&#x2F;scrypt&#x2F;scrypt.pdf</a>

I wish someone would also audit tcplay [1], the BSD-license system with full TrueCrypt compatibility. I would much rather use that, if at least for the license concerns repeated many times in the comments here.<p>[1] <a href="https://github.com/bwalex/tc-play" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bwalex&#x2F;tc-play</a>

&quot;The assessment explicitly excluded the following areas... Cryptographic Analysis, including, RNG analysis, Algorithm implementation, Security tokens, Keyfile derivation&quot;

A feature I&#x27;d like to see on both our laptops and mobile devices to protect their privacy from random and abusive border searches: being able to hide the fact that you have an encrypted account.<p>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&#x27;t see you have that password protected account, and all they could see is a &quot;normal&quot; (clean of sensitive stuff) account, then they&#x27;d just check that and move on. Or you could even password protect that, too, and give them the password to it, and they&#x27;d be none the wiser.<p>All you&#x27;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&#x27;t be easily accessible either, otherwise it defeats the point.<p>I don&#x27;t see Microsoft doing something like this - ever. Apple might if enough people asked for it, but I&#x27;d incline to say they wouldn&#x27;t for now. Google probably won&#x27;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.

Did anybody give this a thorough read and can give a cliff notes on the results? How did Truecrypt do - good&#x2F;bad&#x2F;indifferent?

&gt; Issue 4: Windows kernel driver uses memset() to clear sensitive data<p>&gt; Calls to memset() run the risk of being optimized out by the compiler.<p>I would be curious to know which compilers or which options actually still do these ill-fated <i>optimizations</i>?

Does anyone know if Tomb [1] or ecryptfs [2] is a safe choice for encrypting a local directory?<p>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&#x27;m curious what the appeal of Truecrypt is besides maybe portability (which is a pretty strong selling point).<p>[1] <a href="http://www.dyne.org/software/tomb/" rel="nofollow">http:&#x2F;&#x2F;www.dyne.org&#x2F;software&#x2F;tomb&#x2F;</a><p>[2] <a href="http://ecryptfs.org/" rel="nofollow">http:&#x2F;&#x2F;ecryptfs.org&#x2F;</a>

Actual PDF <a href="https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf" rel="nofollow">https:&#x2F;&#x2F;opencryptoaudit.org&#x2F;reports&#x2F;iSec_Final_Open_Crypto_A...</a><p>Die slideshare, die scribed.

Encrypted 32gb microSD card containing all sensitive information removed from phone prior to flight&#x2F;border checkpoint thus rendering what is on the phone itself to be unimportant and maybe even substitute another password-protected microSD card with interesting but non-sensitive info (maybe a risqué photo or two of the wife and some saucy conversations)?<p>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?

I have been waiting for the security audit report since the first time it was mentioned. Now that it is out i feel a little disappointed that there are no real intentional risks

I recall seeing something about reviewing the TC license. Does anyone know if this is something that will be part of Phase II or am I misremembering the details?

I would really, really like to see an effort like this for OpenSSL ... or better yet, for one of the OpenSSL alternatives that are not a spaghetti mess.

Would Threefish be a better cipher than AES for TrueCrypt&#x2F;disk encryption, considering it can have 1024-bit blocks?

I read this whole thing, but they left out a description of the NSA planted back doors. As everyone knows, the NSA has compromised all crypto systems. Since the audit did not reveal the NSA back door or doors, what else is missing?<p>More likely iSECPartner&#x27;s is the NSA&#x27;s new RSA 2.0

Build tools from 1993? What kind of nonsense is this?<p>&gt; Page 8

tl; dr<p>&quot;1.3 Findings Summary<p>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).<p>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....<p>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.<p>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.&quot;