Slashdot Mirror
First Phase of TrueCrypt Audit Turns Up No Backdoors
msm1267 (2804139) writes "A initial audit of the popular open source encryption software TrueCrypt turned up fewer than a dozen vulnerabilities, none of which so far point toward a backdoor surreptitiously inserted into the codebase. A report on the first phase of the audit was released today (PDF) by iSEC Partners, which was contracted by the Open Crypto Audit Project (OCAP), a grassroots effort that not only conducted a successful fundraising effort to initiate the audit, but raised important questions about the integrity of the software.
The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."
The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."
Wow, a code audit. What a great idea for a FOSS project.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
just important this audit is...
Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.
So, what we can say is that it's clean, insofar as they are permitted to report.
Verify, then trust.
-- Tigger warning: This post may contain tiggers! --
Since Snowden's revelation about the NSA's clandestine $10 million contract with RSA,
I hope that as well as checking that the code implements some known encryption algorithm properly, that they also confirm that the algorithm itself is mathematically unadulterated (by the NSA or whoever).
This is why open source is so important.
ITT: People who (a) don't know how US law actually works and (b) assume that everyone in the world is bound by US law.
The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver. Not really surprising that they didn't find any critical security issues in those parts. The high value bugs should be in the crypto parts and how they are implemented.
isn't it possible to just have your backdoor be inserted by the compiler ?
I've been coding in C a long time and one of the medium security faults makes no sense to me:
"Windows kernel driver uses memset() to clear sensitive data"
The reasoning they give is:
"...However, in a handful of places, memset() is used to clear potentially sensitive data. Calls to memset() run the risk of being optimized out by the compiler."
WTF?!?
I suppose a smart compiler can optimize out a memset() if it's directly preceeded by a calloc() or something, but I have never had any compiler ever just ignore my request to memset().
What am I missing here?
what the fuck did I just read?
I use TrueCrypt. Not that it likely matters given all the other back-doors on my Lenovo Wintel laptop, but I use a passphrase from Hell, and I suspect even the NSA's biggest cracker would have trouble with it.
Other than the backdoors in various places on this toxic waste dump of security, the biggest security threat to my passphrase from Hell is TrueCrypt itself. TrueCrypt by default does 100% useless password strengthening (key stretching or whatever it's called). It's strongest mode, which you have to select manually, is 2000 rounds of SHA-256. I can buy SHA256 boxes that do 1 Giga-hash/second per $10. Figure a government has a few million at least for such boxes, and go compute how strong your password needs to be, and it isn't pretty.
I use my password and TrueCrypt to protect my data. Why didn't it occur to the TrueCrypt authors to protect my password? I mean, Bcrypt at least, come on...
Celebrate failure, and then learn from it - Nolan Bushnell
The backdoor is not in the source it is in the MVC++ compiler. NSA is not stupid, putting the backdoor in the source itself would be risky, it would be much wiser to put the backdoor in the MVC++ compiler itself.
at least the sores are open, so that one may take a puss sample and analyse it for disease. When the sores are closed, who knows what you'll wake up with in the morning.
Why would you trust the liberals? I wouldn't trust either.
WTF. A troll with a cause.
One way to detect a backdoored compiler to a fairly high certainty is diverse double-compiling, a method described by David A. Wheeler that bootstraps a compiler's source code through several other compilers. For example, GCC compiled with (GCC compiled with Visual Studio) should be bit for bit identical to GCC compiled with (GCC compiled with Clang) and to GCC compiled with (GCC compiled with Intel's compiler). But this works only if the compiler's source code is available. So to thwart allegations of a backdoor in Visual Studio, perhaps a better choice is to improve MinGW (GCC for Windows) or Clang for Windows to where it can compile a working copy of TrueCrypt.
A good strong PBKDF2 is probably sufficient, but yeah, 2k rounds is pathetic. iPhones were doing better (admittedly, their passphrases tend to be very short) several years ago, and that's on a mobile CPU. Having a limit of 2k rounds doesn't even make sense, it's not like it's harder to code it for more rounds or something. The only real limit should probably be 0xFFFFFFFF rounds (assuming 32-bit ints) because why have a limit at all?
There's no place I could be, since I've found Serenity...
Due, Bush has been out of office for 6 years now. I know things are moving fast but please do try to keep up.
WTF?!?
WTF indeed.
There seems to be a major trend towards making compilers create code that is as different as possible from what the programmer wrote without being so different that the programmer actually notices. One might assume it's a secret NSA plot to defeat security measures in all software everywhere. You know, if one was incredibly paranoid, that is.
It's hard to say whether this is justified behavior. As an example, consider this code from a link an AC posted:
int ....
crypto_pk_private_sign_digest(....)
{
char digest[DIGEST_LEN];
memset(digest, 0, sizeof(digest));
return r;
}
Exploit mitigation code like this is a case of writing code which we expect to never have any effect, just in case we're wrong and it does have an effect. Then the compiler comes along and decides for itself that the code we wrote will never have any effect and removes it. It's kind of hard to blame it for noticing the uselessness of the operation when we ourselves expected the code to likely have no effect when we wrote it, but then, the whole reason we wrote it is because we thought we might be wrong. Should the compiler then assume that we might be wrong as well, and that we might access that memory using a different pointer?
Does it make sense to compile with optimization enabled when, by including things like the memset() call to clear memory we're finished using, we clearly have goals other than optimization?
The article mentions the fix being the use of a different function which won't be optimized away, but I wonder if even that is a legitimate fix. Our "digest" array is just another variable that the compiler is free to do whatever it wants with in the name of optimization. If it will make the program run faster, it's free to make two copies of it. Then our new never-optimized-away function will end up erasing only one copy of the variable.
So problem here isn't the use of memset() rather than some other function. The problem is that we're asking the compiler to create code that doesn't match what we've written. It should be no surprise then when it goes ahead and does that. Thus, I don't think it's correct to claim that the error here is the failure to use the correct function to clear the memory. I think the error is in asking the compiler to generate code that isn't identical to the source code.
The core of the problem is that C isn't a language that allows us to clearly tell the compiler exactly what we want to happen. Without bounds checking on pointer use, every pointer is effectively a pointer to all memory. Thus, when a pointer falls out of scope, it doesn't mean anything. That memory can still be accessed via any other pointer anywhere in the program. If C enforced bounds checking, such that accessing the data in "digest" via any other pointer was impossible, then the compiler could safely work under the assumption that once "digest" falls out of scope, the data it points to will never be accessed again, and thus removing the memset() call would be a safe thing to do since it truly would have no effect.
It really seems ridiculous when you think about it. Compilers assume that bounds on pointers will be respected, yet make no attempt whatsoever to enforce those bounds, essentially guaranteeing that they will not be respected since programmers are imperfect.
Consider what the compiler will do when it encounters code like this:
int a[4];
int b[4];
int c[4];
b[-1] = 0;
Despite the obvious error in the above code, GCC will compile it without error. It will then perform optimizations that assume that neither a[] nor c[] have been affected by the assignment to b[]. It seems rather ridiculous that anyone is expected to create secure software in such an environment. Either the compiler should enforce bounds checking, or it should assume that any pointer operation ca
was expecting something esoteric but turned out to be really straightforward
I think you failed to notice that the page talks about two separate bugs. In the first one, the memset() really is completely removed by optimization.
the type of error you make at 2am, taking the size of the pointer instead of the actual size of the buffer
I'd argue that's an error one might make any time of the day. The sizeof() operator is ambiguous. Consider the following example:
#include <stdio.h>
void main() {
char a[100];
char *b = a;
printf("address of a is %p\n", a);
printf("address of b is %p\n", b);
printf("size of a is %lu\n", sizeof(a));
printf("size of b is %lu\n", sizeof(b));
};
One might assume that, since both "a" and "b" function identically (e.g., both "a[7] = 0" and "b[7] = 0" are valid, as are both "strlen(a)" and "strlen(b)"), then using the sizeof() operator on each of them should return similar results. However, that isn't the case, as sizeof(a) gives us the size of an array while sizeof(b) gives us the size of a pointer.
It would make more sense if sizeof(a[]) returned the size of the array while sizeof(a) and sizeof(b) both returned the size of a pointer. As it presently works, sizeof() is a somewhat scary operator to use. I usually end up using a printf() to verify that it is giving me the size of what I want the size of rather than assume I know what it is doing.
I am unfamiliar with the drama surrounding apk
Nah, that's mostly just the iDevice users badmouthing Android.
Ezekiel 23:20
You should use a passfile as well as a password. Makes it much harder for an attacker because something like a hardware keylogger or audio analysis to recover keystrokes can't see which file you selected. When it comes to breaking your key there is no way to know after the fact that a keyfile was used, so they will probably waste a large amount of time trying a dictionary attack on the password before even realizing that they need to also try any of the 100,000+ files on your computer as well. That is assuming you used a file on your computer, if it was on an external drive they didn't collect when they grabbed it they are screwed. Keep a few corrupt USB flash drives around just to make the wonder if they had it but broke it.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I don't think you understand whats going on. PBKDF has absolutely nothing to do with 'protecting' your password. Its done because passwords suck ass for encryption keys.
TrueCrypt is taking your password and turning it into something USEFUL as a key for encryption, not 'protecting it'.
Standard passwords are pathetically low on entropy, a full twitter or SMS post is still not 256 bits of useful entropy, and its unlikely your passwords are anywhere near that. I admit I don't know your password, but if you're only using the standard character set, I can safely say its pathetically low on entropy. You need full binary keys generated from good random sources, but you'll never remember that, will you? Imaging trying to type it somewhere.
What the hashing does is takes your password and contorts it into a larger key that is more useful than whatever pathetic string of text you throw at it. It does so in such a way that, like all hashing processes are supposed to, you can't go backwards because bits are discarded along the way.
2000 rounds is pretty low, but thats only a tiny small part of the encryption/decryption process. And your password (as I understand true crypt) really just projects are larger private key, which is what is actually used for encryption. Its been a while since I've looked at or used TrueCrypt, so I may be wrong about that last particular bit.
For a full description: http://en.wikipedia.org/wiki/P...
I do write encryption software for a living. And again, its not about protecting your password or making it harder to guess, its about turning your crappy password into a useful encryption key, nothing more.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Keyfiles don't work for system encryption with TrueCrypt: you can only use passwords (or passphrases, of course).
I don't do this for a living, but I'm not totally ignorant about this topic. TrueCrypt does a poor job strengthening passwords. TC's users would be far better protected if TC ran something even as lame as PBKDF2 for a full second, with rounds somewhere in the 100's of thousands or millions. Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it. This is why I say that the user's password is at risk due to TC, not just the data TC encrypts.
To give TC some credit, OpenSSL has the same lame password strengthening as TC, putting id_rsa passphrases at risk, in addition to the user's private key. So, there seems to be plenty of lameness to go around. I hear that a Bcrypt option is in the bleeding edge version of OpenSSL. I which they'd push out that patch along with the Heartbleed fix.
Celebrate failure, and then learn from it - Nolan Bushnell
APKs rape children ?
Sorry Apple shill, but you are going too far.
True, but if you are that paranoid you can use a VM with the hardfile in an encrypted container on the host OS that is protected by a keyfile.
It's actually a nice way to do it because you can have the host OS as something like a read-only bootable Linux DVD, and use it as an outer layer that somewhat mitigates attacks on the host OS. For example if the host OS was running a VPN/Tor and sending all traffic from the inner host OS over that there would be no way, short of the user making a mistake, for the host to get the IP address of your internet connection. It also prevents apps in the host OS from leaking data outside of the VPN/Tor, and allows you to spoof the network card's MAC address at a (virtual) hardware level, and limits hardware fingerprinting of the machine the host is really running on.
You can also Wireshark the host OS if you are really paranoid, see if it sends any packets to nsa.gov.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I just added a keyfile as you suggested. I put it on a couple of USB keys, so I have a backup, and now in theory my encrypted volume can't be mounted without having the physical key. That should greatly increase my passphrase protection, as well as the volume contents (basically a list of all my various user/password credentials at various sites). I'm still running TC in Windows, and several times I've answered "yes" to let various programs make changes to my hard disk, and my machine probably comes with back-doors from both Lenovo and Microsoft and maybe even Intel. I don't trust our company's closed-source VPN provider, either. So, I still don't feel secure, but at least it's an improvement. Thanks for the tip.
Celebrate failure, and then learn from it - Nolan Bushnell
Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it
That's not at all unique to TrueCrypt. If someone guesses a user's password, it's the user's fault they used the same password elsewhere.
Password-strengthening before encryption is not the same as salting & hashing passwords for later authentication, where rainbow tables and "guessing" a password makes sense -- we're not talking about storing the resulting strengthened password where it could directly attacked ... unless, maybe, perhaps you're trying to say this is stored in-memory while the system is running, and that's the kind of attack you're trying to describe? I don't see why the strengthened password would even need to be kept in memory once it's used to unlock the real keys, which TC will need at runtime for crypto. Having to re-fetch the real keys based on the password at every i/o would be prohibitively expensive.
I'm always amazed at how hard something as simple as password hashing can be. Yes, it's the user's fault for reusing passwords, but we should try and protect him anyway, because it's very common. Part of the job of the computer security industry is protecting stupid people. Improving this is situation one reason for the Password Hashing Competition.
You are right that password strengthening before encryption is a different problem from user authentication, but the solutions tend to be the same. You can use Bcrypt or Scrypt for strengthening a password hash on an authentication server just like you can while deriving a volume decryption key. The main difference seems to be that a common server may not have a significant fraction of a second to spend on authenticating a user/password combo. TC has some additional constraints, like the volume needs to appear as random data, making it harder to embed various encryption parameters, such as which key stretching algorithm is in use. To an attacker, he doesn't care whether the password/salt is protecting a login account or an encrypted volume. To him, it's just so many rounds of PBKDF2 (or whatever), and then a quick check to see if he got the right answer, and do as many in parallel as possible. Salt is used either way to defeat rainbow tables, so instead attackers use GPU farms to do massively parallel brute force guessing, where each guess is user/salt specific.
However, the two cases I've mentioned are both encryption: TC encrypted volumes, and OpenSSh id_rsa private keys. We could argue about how much effort a server should put into protecting it's user's passwords, but both TC and OpenSSh do *nothing* more than a typical server, devoting only a millisecond to key stretching. That's just lame.
Celebrate failure, and then learn from it - Nolan Bushnell
A passphrase from hell doesn't protect you from a keylogger. It does, however, put the burden on whatever organization hacks your computer to justify why they installed a keylogger since you can demonstrate that the long password couldn't possibly be brute forced. If they try to hide their tracks it is difficult to use a parallel reconstruction to explain away how they got the long password. Just don't ever fall for the trap of thinking you are invulnerable.
I am becoming gerund, destroyer of verbs.
Yeah, it's the users fault for not being able to remember 37 different strong passwords which change from time to time. (I haven't counted the passwords I use from time to time, but three dozen feels in the ballpark.) Heck, I can't remember that many, and I use a system, as well as having many low-security accounts on the same password.
If you try a system that approximately nobody seems able to use, after extensive efforts at user education, and the system sounds impractical to everybody who knows something about human factors, just maybe that system sucks in the real world. Similarly, if you build a site that is much like four hundred thousand other sites, and expect your users to do something for you they won't be able to do for another fifty, you may be disappointed.
Remember, all these systems would be much easier to build and maintain if it wasn't for all those blasted users.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Does TrueCrypt use SSL?
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Crede quod habes, et habes.
--
I do not speak for the truth of foreigners.