10 ms·

TrueCrypt Security Assessment [pdf]

206 points by silenteh 12y ago

doe88 12y ago
> Issue 4: Windows kernel driver uses memset() to clear sensitive data > 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?
- cliffbean 12y ago
  Pretty much all of them do. Many of the big leaders in the C++ world, like Google, are pushing the idea that every last optimization technique is crucially vital. Google can bank on tenths-of-a-percent of performance, so why can't you? Google can devote armadas of armadas of test machines to run asan/tsan/space-alien-san and everything else continuously, and it works pretty well for them, so why can't you do this too?
- munin 12y ago
  they still do, but everyone (including the windows DDK) offers a "secure memset" that casts to volatile and preserves the call. in Windows, it's called RtlSecureZeroMemory and I would think that know about this would be one of the pre-requisites for writing security software on that platform...
- 30thElement 12y ago
  They should do it only in situations where it doesn't change the program behavior. I use memset frequently in C just to be safe, but if it's written to later on before it's ever read from, the compiler can optimize that away. I'm guessing their recommendation here is if you did something like char* plain_text = malloc(size); ///do stuff with plain_text memset(plain_text, 0, size); free(plain_text); For most programs that last memset is unnecessary (and may even be unnecessary according to the standard, but it's probably implementation defined, not undefined behavior) and it makes sense for the compiler to optimize it away. But for crypto purposes you have to be afraid of someone being able to read plain_text later, so the memset is important
  - Marat_Dukhan 12y ago
    I checked 3 compilers: icc 14, gcc 4.8, and clang 3.3. Clang is the only one which optimized the memset away.
    - timtadh 12y ago
      Not a windows user so I can't check but given that it is the kernel driver the compiler we would be concerned about is the MS visual c++ compiler.
      - Marat_Dukhan 12y ago
        Visual C++ 2013 doesn't remove memset either.
    - lawnchair_larry 12y ago
      Did you enable optimization? I know first hand that GCC will optimize something similar out in many cases. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
      - Marat_Dukhan 12y ago
        Yes, I compiled with -O3.
- shin_lao 12y ago
  It is not advised to use C library functions. The driver should use RtlZeroMemory() and in that case RtlSecureZeroMemory(), but otherwise this optimization makes a lot of sense in many cases when you have for example an useless constructor call before an initialization.
- doe88 12y ago
  After a little bit of digging seems to be the best way to currently wipe out sensitive data is to implement something like in libsodium https://github.com/jedisct1/libsodium/blob/master/src/libsodium/sodium/utils.c#L19 https://github.com/jedisct1/libsodium/blob/master/src/libsod... 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
- lawnchair_larry 12y ago
  All of them will under circumstances that tend to manifest when wiping secrets. This surprises a lot of developers, but it's a very common finding when auditing crypto code or other secret storage. 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).
higherpurpose 12y ago
Would Threefish be a better cipher than AES for TrueCrypt/disk encryption, considering it can have 1024-bit blocks?
- pogue 12y ago
  Any of the encryption algorithms used by TrueCrypt would be fine. The real security lies in the strength of your password. http://xkcd.com/538/ http://xkcd.com/538/ EDIT: Thought OP said Twofish
- oggy 12y ago
  For security, somewhat. The current de-facto standard mode of operation for disk encryption utilities is XTS, which effectively encrypts each block on the disk with a different key, where the blocks are of the same size as the cipher block. 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 :)
yvishyar 12y ago
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
- aroch 12y ago
  Why would you be disappointed that there's nothing wrong with it? Why would you be hoping that the program millions use to protect their sensitive information was broken?
  - stinkytaco 12y ago
    I'm not OP, but I suspect it's a bit like watching a hyped sporting event. There's a build up, lots of discussion, some naysayers and the tech equivalent of trash talking. In the end you sort of expect something more exciting than what we got. It's sort of like watching the favorites secure a clinical win in the Superbowl. It's ok, but no one's going to be talking about it for years to come. 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.
  - daeken 12y ago
    I'm not disappointed by a fairly uneventful report, but quite honestly, I'm always a little bit worried when nothing horrible is discovered in the course of testing. 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.
    - lawnchair_larry 12y ago
      Heh, a clean bill of health always has that elephant in the room attached.
sigil 12y ago
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. 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 http://www.tarsnap.com/scrypt/scrypt.pdf
- Osmium 12y ago
  Somebody more knowledgeable please correct me if I'm wrong, but as I understand it: 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_measure_of_password_strength http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_...
  - sp332 12y ago
    According to the chart in that article, case-sensitive alphanumerics give at most 5.17 bits of entropy per character. So that's 25 random characters. (edit: sorry, this bit is redundant because I misread your comment.) 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.
pogue 12y ago
Did anybody give this a thorough read and can give a cliff notes on the results? How did Truecrypt do - good/bad/indifferent?
- aroch 12y ago
  tl;dr Follow TrueCrypts recommendations (FDE, long password) and you're mostly fine. The only things that can make it better require program changes.
- TheLoneWolfling 12y ago
  All things considered, pretty good. 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.
- plainOldText 12y ago
  Vulnerability Summary 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)
dmix 12y ago
Does anyone know if Tomb [1] or ecryptfs [2] is a safe choice for encrypting a local directory? 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). [1] http://www.dyne.org/software/tomb/ http://www.dyne.org/software/tomb/ [2] http://ecryptfs.org/ http://ecryptfs.org/
- dublinben 12y ago
  The appeal of Truecrypt is that it works on Windows. As you've suggested, there are better encryption programs and schemes for users of GNU/Linux operating systems. 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.
  - doreo 12y ago
    The appeal of Truecrypt is the deniable encryption and the alternatives for that are sparse and bad on any operating system
  - yabatopia 12y ago
    Too bad Windows 8 isn't supported, so Truecrypt loses much of its appeal to Windows users.
    - lawnchair_larry 12y ago
      I replied to this comment using a TrueCrypted Windows 8 machine.
- ewams 12y ago
  TrueCrypt is also opensource: http://www.truecrypt.org/downloads2 http://www.truecrypt.org/downloads2 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.
higherpurpose 12y ago
A feature I'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. 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.
- coob 12y ago
  It's called deniable encryption[1]. TrueCrypt supports it[2]. Bruce S is not a fan of their implementation, however[3]. [1] http://en.wikipedia.org/wiki/Deniable_encryption http://en.wikipedia.org/wiki/Deniable_encryption [2] http://www.truecrypt.org/docs/plausible-deniability http://www.truecrypt.org/docs/plausible-deniability [3] https://www.schneier.com/blog/archives/2008/07/truecrypts_deni.html https://www.schneier.com/blog/archives/2008/07/truecrypts_de...
  - TheLoneWolfling 12y ago
    Huh. I hadn't thought about multiple-image attacks. Could that be mitigated by having TC occasionally randomly write random data to unused blocks?
    - mseebach 12y ago
dfc 12y ago
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?
rsync 12y ago
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.
- lucb1e 12y ago
  Hindsight bias? We should audit libnss and all the other cryptography libraries too then. And don't forget how much of the world relies on closed-source solutions like Microsoft's Bitlocker. Better shun those because they had no public audits and for all we know they're even more spaghetti code.
  - rsync 12y ago
    No, it's not hindsight bias. I have posted (and so have others) on many public forums for years about the need for an audit of OpenSSL and OpenSSH and there have been many discussions about the sad state of the codebase in OpenSSL. I can think of a particular discussion on the cryptography mailing list at randombit from ... two years ago ?
616c 12y ago
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. [1] https://github.com/bwalex/tc-play https://github.com/bwalex/tc-play
- watwut 12y ago
  License review is listed as #1 among goals on http://istruecryptauditedyet.com/ http://istruecryptauditedyet.com/ .
whoismua 12y ago
tl; dr "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."
floatboth 12y ago
"The assessment explicitly excluded the following areas... Cryptographic Analysis, including, RNG analysis, Algorithm implementation, Security tokens, Keyfile derivation"
Evolved 12y ago
Encrypted 32gb microSD card containing all sensitive information removed from phone prior to flight/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)? 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?
- tsaoutourpants 12y ago
  In America, you are better off putting it in your sock under your foot. No TSA search includes the bottom of the foot, and you'd have to really arouse CBP suspicion to get them checking out your feet. 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.
cordite 12y ago
Build tools from 1993? What kind of nonsense is this? > Page 8
- hobbes78 12y ago
  To offer full disk encryption, boot code for the MBR must be produced, and it has to be 16-bit. Current compilers just produce 32 and 64-bit binaries. So you have to use an old compiler...
  - cordite 12y ago
    Thanks for detailing that (I didn't know)
deleted 12y ago
[deleted]
samplonius 12y ago
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? More likely iSECPartner's is the NSA's new RSA 2.0
angry_octet 12y ago
Actual PDF https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_A... Die slideshare, die scribed.

206 points by silenteh 12y ago

doe88 12y ago

> Issue 4: Windows kernel driver uses memset() to clear sensitive data > 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?

cliffbean 12y ago
Pretty much all of them do. Many of the big leaders in the C++ world, like Google, are pushing the idea that every last optimization technique is crucially vital. Google can bank on tenths-of-a-percent of performance, so why can't you? Google can devote armadas of armadas of test machines to run asan/tsan/space-alien-san and everything else continuously, and it works pretty well for them, so why can't you do this too?
munin 12y ago
they still do, but everyone (including the windows DDK) offers a "secure memset" that casts to volatile and preserves the call. in Windows, it's called RtlSecureZeroMemory and I would think that know about this would be one of the pre-requisites for writing security software on that platform...
30thElement 12y ago
They should do it only in situations where it doesn't change the program behavior. I use memset frequently in C just to be safe, but if it's written to later on before it's ever read from, the compiler can optimize that away. I'm guessing their recommendation here is if you did something like char* plain_text = malloc(size); ///do stuff with plain_text memset(plain_text, 0, size); free(plain_text); For most programs that last memset is unnecessary (and may even be unnecessary according to the standard, but it's probably implementation defined, not undefined behavior) and it makes sense for the compiler to optimize it away. But for crypto purposes you have to be afraid of someone being able to read plain_text later, so the memset is important
- Marat_Dukhan 12y ago
  I checked 3 compilers: icc 14, gcc 4.8, and clang 3.3. Clang is the only one which optimized the memset away.
  - timtadh 12y ago
    Not a windows user so I can't check but given that it is the kernel driver the compiler we would be concerned about is the MS visual c++ compiler.
    - Marat_Dukhan 12y ago
      Visual C++ 2013 doesn't remove memset either.
  - lawnchair_larry 12y ago
    Did you enable optimization? I know first hand that GCC will optimize something similar out in many cases. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537
    - Marat_Dukhan 12y ago
      Yes, I compiled with -O3.
shin_lao 12y ago
It is not advised to use C library functions. The driver should use RtlZeroMemory() and in that case RtlSecureZeroMemory(), but otherwise this optimization makes a lot of sense in many cases when you have for example an useless constructor call before an initialization.
doe88 12y ago
After a little bit of digging seems to be the best way to currently wipe out sensitive data is to implement something like in libsodium https://github.com/jedisct1/libsodium/blob/master/src/libsodium/sodium/utils.c#L19 https://github.com/jedisct1/libsodium/blob/master/src/libsod... 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
lawnchair_larry 12y ago
All of them will under circumstances that tend to manifest when wiping secrets. This surprises a lot of developers, but it's a very common finding when auditing crypto code or other secret storage. 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).

higherpurpose 12y ago

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

pogue 12y ago
Any of the encryption algorithms used by TrueCrypt would be fine. The real security lies in the strength of your password. http://xkcd.com/538/ http://xkcd.com/538/ EDIT: Thought OP said Twofish
oggy 12y ago
For security, somewhat. The current de-facto standard mode of operation for disk encryption utilities is XTS, which effectively encrypts each block on the disk with a different key, where the blocks are of the same size as the cipher block. 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 :)

yvishyar 12y ago

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

aroch 12y ago
Why would you be disappointed that there's nothing wrong with it? Why would you be hoping that the program millions use to protect their sensitive information was broken?
- stinkytaco 12y ago
  I'm not OP, but I suspect it's a bit like watching a hyped sporting event. There's a build up, lots of discussion, some naysayers and the tech equivalent of trash talking. In the end you sort of expect something more exciting than what we got. It's sort of like watching the favorites secure a clinical win in the Superbowl. It's ok, but no one's going to be talking about it for years to come. 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.
- daeken 12y ago
  I'm not disappointed by a fairly uneventful report, but quite honestly, I'm always a little bit worried when nothing horrible is discovered in the course of testing. 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.
  - lawnchair_larry 12y ago
    Heh, a clean bill of health always has that elephant in the room attached.

sigil 12y ago

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. 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 http://www.tarsnap.com/scrypt/scrypt.pdf

Osmium 12y ago
Somebody more knowledgeable please correct me if I'm wrong, but as I understand it: 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_measure_of_password_strength http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_...
- sp332 12y ago
  According to the chart in that article, case-sensitive alphanumerics give at most 5.17 bits of entropy per character. So that's 25 random characters. (edit: sorry, this bit is redundant because I misread your comment.) 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.

pogue 12y ago

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

aroch 12y ago
tl;dr Follow TrueCrypts recommendations (FDE, long password) and you're mostly fine. The only things that can make it better require program changes.
TheLoneWolfling 12y ago
All things considered, pretty good. 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.
plainOldText 12y ago
Vulnerability Summary 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)

dmix 12y ago

Does anyone know if Tomb [1] or ecryptfs [2] is a safe choice for encrypting a local directory? 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). [1] http://www.dyne.org/software/tomb/ http://www.dyne.org/software/tomb/ [2] http://ecryptfs.org/ http://ecryptfs.org/

dublinben 12y ago
The appeal of Truecrypt is that it works on Windows. As you've suggested, there are better encryption programs and schemes for users of GNU/Linux operating systems. 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.
- doreo 12y ago
  The appeal of Truecrypt is the deniable encryption and the alternatives for that are sparse and bad on any operating system
- yabatopia 12y ago
  Too bad Windows 8 isn't supported, so Truecrypt loses much of its appeal to Windows users.
  - lawnchair_larry 12y ago
    I replied to this comment using a TrueCrypted Windows 8 machine.
ewams 12y ago
TrueCrypt is also opensource: http://www.truecrypt.org/downloads2 http://www.truecrypt.org/downloads2 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.

higherpurpose 12y ago

A feature I'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. 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.

coob 12y ago
It's called deniable encryption[1]. TrueCrypt supports it[2]. Bruce S is not a fan of their implementation, however[3]. [1] http://en.wikipedia.org/wiki/Deniable_encryption http://en.wikipedia.org/wiki/Deniable_encryption [2] http://www.truecrypt.org/docs/plausible-deniability http://www.truecrypt.org/docs/plausible-deniability [3] https://www.schneier.com/blog/archives/2008/07/truecrypts_deni.html https://www.schneier.com/blog/archives/2008/07/truecrypts_de...
- TheLoneWolfling 12y ago
  Huh. I hadn't thought about multiple-image attacks. Could that be mitigated by having TC occasionally randomly write random data to unused blocks?
  - mseebach 12y ago

dfc 12y ago

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?

rsync 12y ago

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.

lucb1e 12y ago
Hindsight bias? We should audit libnss and all the other cryptography libraries too then. And don't forget how much of the world relies on closed-source solutions like Microsoft's Bitlocker. Better shun those because they had no public audits and for all we know they're even more spaghetti code.
- rsync 12y ago
  No, it's not hindsight bias. I have posted (and so have others) on many public forums for years about the need for an audit of OpenSSL and OpenSSH and there have been many discussions about the sad state of the codebase in OpenSSL. I can think of a particular discussion on the cryptography mailing list at randombit from ... two years ago ?

616c 12y ago

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. [1] https://github.com/bwalex/tc-play https://github.com/bwalex/tc-play

watwut 12y ago
License review is listed as #1 among goals on http://istruecryptauditedyet.com/ http://istruecryptauditedyet.com/ .

whoismua 12y ago

tl; dr "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."

floatboth 12y ago

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

Evolved 12y ago

Encrypted 32gb microSD card containing all sensitive information removed from phone prior to flight/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)? 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?

tsaoutourpants 12y ago
In America, you are better off putting it in your sock under your foot. No TSA search includes the bottom of the foot, and you'd have to really arouse CBP suspicion to get them checking out your feet. 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.

cordite 12y ago

Build tools from 1993? What kind of nonsense is this? > Page 8

hobbes78 12y ago
To offer full disk encryption, boot code for the MBR must be produced, and it has to be 16-bit. Current compilers just produce 32 and 64-bit binaries. So you have to use an old compiler...
- cordite 12y ago
  Thanks for detailing that (I didn't know)

deleted 12y ago

[deleted]

samplonius 12y ago

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? More likely iSECPartner's is the NSA's new RSA 2.0

angry_octet 12y ago

Actual PDF https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_A... Die slideshare, die scribed.