TrueCrypt turmoil latest: Bruce Schneier reveals what he'll use instead The TrueCrypt project abruptly imploded on Wednesday – leaving folks in the infosec world scratching heads and scrambling to recommend alternatives. In the past hour, crypto-guru Bruce Schneier has told us he's switched back to Symantec's PGPDisk to encrypt his data. "I have no idea what's going on with TrueCrypt," he added …
"TrueCrypt was created in order to provide disk encryption for operating systems that do not have built-in support for it. Currently the only one is Windows XP and since it is 'no longer safe' to use it, there’s no point in maintaining an encryption solution for it." ®
Err Lots of XP around. And Win 7 builds that don't have bitlocker.
Erm.
Noone's arguing that XP is still around in lots of places. But since it is not being officially supported anymore, XP cannot be considered safe to use. There may be (read: probably are) already exploits against it in the wild.
And if your OS is pwned, it doesn't matter what encryption software you use.
Fair point about the lack of Bitlocker in some editions (read: almost every pre-installed consumer edition) of Windows 7 (and 8), though.
>operating systems that do not have built-in support ... WinXP
WinXP has EFS, the Encrypting File System, except in the Home version.
Furthermore, Bitlocker requires TPM hardware, so even if you have the Enterprise Win7, you probably won't have Bitlocker on your home machine.
In terms of functionality, TrueCrypt fell somewhere between EFS and Bitlocker. It allowed you to have a single BLOB containing many things, but that BLOB could not contain your host operating system.
Philosophically, the argument for TrueCrypt was that, as a single blob, it concealed the existance of objects as well as encrypting them.
People who want to conceal their activities may want to look for a new method. People who just want to encrypt may continue to use the native features of WinXP.
Actually, BitLocker does >not< require TPM since Windows 7. Since Windows 7 it allows a passphrase in pretty much the same way as TrueCrypt. I use it, since TrueCrypt does not (and, probably, never will after the announcement) support UEFI partitions.
Also, BitLocker does not, by default, leave a "backdoor" for domain admins. If this is configured, then it is done so by a corporate group policy, but it is not ON by default.
BitLocker does not allow plausible deniability on the other hand, and there people will need to find some other option now that TrueCrypt development seems to be ending.
The problem of trust is there for both TrueCrypt and its closed-source alternatives such as BitLocker. There are ways to insert vulnerabilities that would look like ordinary bugs and be very hard to catch even when somebody is really looking in the source code (see how long it took people to figure out that Debian pseudorandom number generator was defunct). At the end of the day, unless one writes OS and compilers and "bootstrap" them from its own assembler, it is always involving some degree of implicit trust of 3rd parties.
What we need is a truly open-source disk encryption tool which is:
a) Not based in the USA, so that it cannot be subverted by "Patriot" act
b) Which undergoes regular peer-reviews by multiple crypto experts
c) With strictly controlled development policies requiring oversight and expert approval of commits
The problem is: b and c cost money, so there needs to be a workable business model. And that needs to be creative due to a), which would preclude standard revenue stream from software licensing.
And even then, you still need to trust these guys and those crypto experts as well as compilers that were used to build the damn thing...
>> Furthermore, Bitlocker requires TPM hardware
> No it doesn't. It will use it if available, but it runs fine without it.
Indeed, it's not Bitlocker that requires NSA"TCG" "TPM" - it's the author of that page. He's even taken the trouble of designing a helpful little sub-page, complete with step-by-step screenshots to MAKE SURE YOU ENABLE IT.
How thoughtful.
Well no average person can use Windows securely, no matter what version. One big problem is, as we see here, the software distribution method. How can an average person be sure they install the software they want and not some malware? Some people see "AppStores" as a solution, however the mechanisms can only guarantee that they get what was signed by the store owner... and in most cases it only cares about money, not security.
So that argument is rather moot. No matter if you use XP or 8.1 you have no idea if the software you're downloading is OK or malware.
> You'd have to wonder if the code-quality inspection didn't force something unseen out of the woodwork.
Absolutely!
Nail on the head!... 'though not in the manner you're attempting to imply.
It's ***SO*** obviously CIA/NSA wot done it it's not even funny. For YEARS said TLAs have been waging an open war of FUD against Truecrypt. Pretending it's over-complicated and botched, a toy mistrusted by real cryptographers, etc... etc... Then lately that's all gone horribly wrong for them... Renowned and respected experts like BS have publicly endorsed it, implosions within their own house have made it BLINDINGLY OBVIOUS to Joe Public that he needs to at least think about it, and to cap it all the source of those "revelations" has recommended it! Talk about great publicity. Then, as if all that wasn't enough, right in the midst of all this free advertising, a publicly sponsored code audit is due to publish its findings that TC is sound as a pound*. As we all knew* already. Poof go the last vestiges of that FUD campaign.
All this must raise a rather pressing problem. What can a cryptography suppressing/subverting government agency do now? Skulk back into the shadows and observe a surge in ciphertext which they cannot break? Hell no! Turn the FUD up to eleven!!!!!!one! Hack the website! Discredit the project NOW! Emergency! Emergency! ...an to that end the supposed endorsement of, of all things, Bitlocker! How could you possibly better discredit a security team than have them appear to recommend NSA™ Windows® as a security suite? Awesome stuff boys!
So YES, it would appear that "the code-quality inspection [certainly has] force[d] something unseen out of the woodwork" as you put it.
*Yes, we do KNOW that the FUD is just FUD. The Truecrypt implementation has already been subjected to what's about as perfect scrutiny as you could hope for: Multiple, independent, concurrent reimplementations. Several such projects have successfully used independent code to recreate Truecrypt's cryptographic functions and their success has already proven that TC does what it says on the tin. A notable example of such projects which immediately springs to mind is, of course, TC-Play which uses Linux's internal DMCrypt code to deliver a compatible reimplementation. The project's author has even been kind enough to thoroughly document all the descrepencies he discovered between Truecrypt's documented functioning and its actual functioning. So we already ***KNOW*** the Truecrypt format is pukka... but that still leaves the possibility of covert-channel "backdoors" in the application. Stashing keys in some obscure PCI EEPROM or secretly signaling them out via the network or somesuch... Of course code to achieve such mischief would be well outside Truecrypt's advertised functioning and therefore correspondingly conspicuous if any kind of code audit was to be performed. So that'll be a fear/uncertainty/doubt that's about to be thoroughly lain to rest. Hence the panic-stricken last minute attack.
;-)
Of course, it might simply be the Ukrainian equivalent of April fools' day or something. Or a bit of a publicity drive before the announcement of Truecrypt 8? Whatever it is 'though, it certainly isn'tsome (conspicuously undisclosed) failure, so grave that we'd all be better off switching to Windows!
It all seems like far too much effort to be anything like publicity/joke though. Malicious binaries, cryptographic signatures, etc... Nope, it's CIA/NSA wot done it. Surpress and subvert. CIA/NSA I tell you. Perhaps one day Snowden II will prove it...
Yup, it's still every bit as fine as it always was. Don't panic Mr Mainwaring!
This looks like an attempt to queer the audit.
If anything, this fiasco IMPROVES my confidence in the code!
The FUD-storm has been flying against TC since the day it began but there's never been the faintest hint of any actual failure. Ever! It's all been crap!
Finally, a full, independent audit has been commissioned. Effectively in response to the FUD operation - without the incessant free-floating fear/uncertainty/doubt I'm certain no-one would have bothered. The counter-intelligence operation has backfired! The most secure public encryption software, offering by-far the best security margin available, will soon be both FOSS and the only free, open, security software to have been formally certified by a full independent audit!
Whoops!
Perhaps the auditors have already been leant on and resisted... you can't just INVENT failures in OPEN code!.. now what? The report is due. The end is neigh.
The last gasp for Operation Suppress TrueCrypt: The developers appear to renounce their own code.
How could any serious academic or security consultancy grant a clean bill of health to code which its developers have publicly conceded is seriously flawed? They have reputations to consider! If the developers say it's fucked, then it must be fucked. Right? That audit must have been bogus - they just took the money and did nothing.
This is the last gasp of Operation Suppress TrueCrypt.
That may not be as easy as you imagine. The source license contains language that many distro folks considered pretty noxious to the end-user; it's quite possible that the same terms might prove unworkable for the distributor of a fork. (Note: it's been a while since that issue arose, so I forget what the problem was exactly. )
> The most recent version also changes the license terms.
Good point, I'd forgotten that. The licence had been getting progressively more liberal. Wasn't it at v3 which said, effectively: "Muck about with it all you like. Alter it, compile it, distribute it, poke babies in the eye with it, whatever you like. Just remove all references to the name "TrueCrypt" and all occurrences of our logo, before you do."
It was under those terms that Redhat(?) re-packaged it and incorporated it as "RealCrypt"
"TrueCrypt was created in order to provide disk encryption for operating systems that do not have built-in support for it. Currently the only one is Windows XP and since it is 'no longer safe' to use it, there’s no point in maintaining an encryption solution for it."
Erm... yeah there is. I use TrueCrypt for my cloud storage. I have no kowledge of, or indeed any interest, regarding what OS that storage resides upon. I just have a nice big encrypted vob that I can mount on any OS, make changes, and have synced down to all of my machines and accessible to me globally via the web.
Are you sure? We have never been able to get truecript to work on any of our industrial computers OSs. Maybe you mean any WINDOWS OS.
Truecrypt works for Linux, OSX and Windows; the source code might even compile for other platforms though I've never checked that out. What industrial OS are you using?
Any thought that this project was an NSA special and was closed up before a more detailed review could be done of the code? The timing of the code review and the subsequent shutdown is interesting, to say the least.
Also, as noted elsewhere, not all versions of Windows 7/8 have access to BitLocker. To quote the Wiki: "BitLocker is available in the Enterprise and Ultimate editions of Windows Vista and Windows 7. It is also available in the Pro and Enterprise editions of Windows 8."
It won't as such, but the next stage of the audit is the crypto-analysis phase which requires incredibly skilled people to actually perform. It seems incredibly unlikely that those people are going to actually perform the second stage of the audit at this point and even if they do, knowing human nature, I can't imagine they'll be doing their work with the same level of effort they would have originally.
Whatever the cause of this particular piece. TrueCrypt is dead.
the crypto-analysis phase which requires incredibly skilled people to actually perform
I don't understand. The code review is not there to ascertain that the cryptographic algorithms are any good. The cryptographic algorithms should follow the specifications...
"The code review is not there to ascertain that the cryptographic algorithms are any good." True, but it is there to ascertain whether the implementations are good. That would require skilled programmers who also know a good bit about cryptography and its implementation. TrueCrypt's algorithms are standard ones that have been analyzed in depth in other connections.
Well, (as I would have said at the time had I spotted your reply earlier) they had already raised the money for the audit, so it's not like they could just say "OK, we're just going to keep all your donations and go down the pub with them, kthxbye"; the audit project is obliged to go ahead. I don't think you have any grounds for making assumptions about the professionalism of the crypto experts who the audit project will hire either, and in fact since so many security/crypto experts use TC themselves, whoever they end up hiring is highly likely to have a personal interest in finding out just how secure TC actually is.
So I think it would have been hopelessly wishful thinking on the part of any hypothetical NSAboteur to hope that the audit would just go away, and indeed, as we have found out since, the audit is going ahead full steam and even possibly going to pick up a fork of TC based on the 7.1 code they're auditing. Your hypothesis just does not hold water, and didn't even before the OCAP announcement, and TC is far from dead.
My prediction is that the audit won't find anything suspect or broken, and TC will continue to be one of the best and safest disk encryption packages available.
Love it or not, there is no objective reason why you would trust Microsoft less than some bunch of anonymous developers.
Microsoft has a vested interest in selling their product worldwide, and backdoor discovered in their crypto would severely impair their ability to sell Windows to any non-USA goverment entity and probably big industry players, too.
I am not saying that BitLocker has no backdoors - but there is no objective reason to trust BitLocker less than TrueCrypt.
Sad thing is, when it comes to crypto there is, simply, no way to have 100% trust >unless< you designed your own hardware, assembler for building your own OS and its system libraries and, finally, crypto.
Since nobody does that, there is always some degree of implicit trust and, frankly, I see no special reason why one would trust some anonymous developers more than a corporation. Same goverment pressure that can be applied to a corporation can be applied to an individual and we do not even know if TrueCrypt developers are in USA (or within USA government's reach) or not. Actually, it is easier for a goverment to apply pressure to an individual, which has far less resources to fight compared to cash-full corporation that can afford a million $ a day legal team if need be.
The fact that TrueCrypt is open source means nothing as far as trust is concerned. Debian had a gaping hole in its pseudorandom number generator for everybody to see for 1.5 years. Let's not even start about OpenSSL and its vulnerabilities.
There is, simply, no way to guarantee that somebody else's code is free of backdoors, You can only have >some< level of trust between 0% and less than 100%.
I agree - and the level of trust that people require depends on the situation. If you want something to prevent a thief getting at your data, I'd say Bitlocker is good enough - sure, maybe the possibility of NSA backdoors is greater in Bitlocker than Truecrypt, and maybe you're willing to trust the shared source of Truecrypt even though that isn't a guarantee and the audit hasn't completed yet, but does that stop it doing the job? Similarly if you just want to keep information private from friends/family/anyone who might find a USB key you dropped.
If you absolutely need something to be secure, then I wouldn't trust Bitlocker _or_ Truecrypt on its own. Since there's no guarantee of being free of malware or backdoors on or in the OS, relying on Truecrypt isn't sufficient - a keylogger can trivially grab your passkey, and once a volume is decrypted, it's fair game for anything on the system to grab it. The answer here is to use totally secure methods - for example, for Bitcoin I use cold storage, such that my password has only ever been entered on a freshly installed OS where the machine was never connected to the Internet.
Admittedly, Linux and Truecrypt have an advantage, but more that it's easier to stick them on a Live CD to boot them as a fresh install - with Windows you'd presumably have licensing issues, and I'm not sure it's possible to run without installing to disk. But it's not because "Oh noes MS is evil and insecure and have backdoors". (And I do use Truecrypt as it happens, but I don't think that that alone is sufficient for total security.)
The divide is not between known vs unknown developer, the divide is between closed-source and open-source. Any popular encryption software that makes its source code openly available (as TrueCrypt did) *cannot* have backdoors, because someone, somewhere would either discover them or discover that the source code won't build the binary and blow the whistle PDQ. I am confident that any official TrueCrypt version prior to 7.2 is and remains perfectly secure. Closed-source software from *any* source will always be of unknown security. Many of us remember very well the origins (and original author) of the software that became TrueCrypt. He posted regularly on newsgroup encryption & security forums.
Like someone discovered Heartbleed or the Debian DRBG flaw in only a couple of years or so each. I used (and use) both, and strongly prefer FSF-type free software, but do not delude myself that it is perfect. There is no reason to think free (or open source) software, by virtue of being open source, is inherently more or less subject to implementation errors than proprietary software. Code reviews get skipped and testing left undone for both, and vulnerable programs are released. Open source code may be available for public review, but it is clear that the review is not always done successfully or timely.
I am sorry, but this is simply not true (that open source software >cannot< have backdoors because someone, somewhere might spot it).
Very good backdoors are made so that they look like plausible bugs (and all general purpose software is full of them). Something like missed parameter validation or a specific sequence of things which triggers a behavior desired on the most popular architectures/compilers allowing adversary to read the contents of a buffer, etc..
It takes awful lot of time to spot issues in complex code - it took Debian more than a year and a half to figure out that their pseudorandom generator is fatally flawed due to stupid attempt of optimization. And >that< was not so hidden, it was there in plain sight. Not to mention that crypto code >should not< be "fixed" by general-purpose developers (actually, this is what caused the Debian PRNG problem in the first place), so your pool of experts that would review the code drastically shrinks. So you gotta hope that some of these experts will invest their time to review some 3rd party component. This costs hell lot of time and, unless somebody has a personal interest, I doubt very much that you would assemble a team of worldwide crypto experts to review your github-hosted project without paying for this.
Then, complex code is extremely hard to completely review. This is why in aerospace and vehicle telematics, critical software is written from the scratch so that it can be proven that it works by following very strict guidelines on how the software should be written and tested (and, guess what, even then - bugs do occur). General-purpose software with millions of lines of code? Good luck. The best you can do is to schedule expert code reviews and, in addition, go through the code with some fuzzing kit and spot pointer overruns etc. but even after all that, more sinister vulnerabilities might still pass.
So, sorry, no - being open source does not guarantee you lack of backdoors. Because in this day and age, smart adversary is not going to implement a backdoor in plain sight. Instead, it will be an obscure vulnerability that can easily be attributed to simple programmer error.
Faith that open source code is backdoor free because it is open is pretty much similar to the idea that infinite amount of monkeys with infinite amount of typewriters will write all Shakespeare work. Please do not get me wrong, I am not attempting to compare developers to monkeys, but the principle that just because there is some chance of something to happen - it will happen. No, this is not guaranteed.
Maybe the developer(s) were hacked off that quite a large sum of money was raised quite quickly to pay security professionals to audit TrueCrypt, and only small amounts trickled in to support the developers of TrueCrypt?
Why do most stories keep persisting the myth that the new binaries are signed with the same keys as were used for older releases? The signing keys were switched well before the new 7.2 release was made, and combined with the rather amateurish website this lends more credence to a hack job rather than an "official" end-of-line for TrueCrypt.
I'll wait and see; for now 7.1(a) is still as (in)secure as always. Almost certainly more secure than BitLocker anyway!
Could not agree with you more that moving from an open source security program that so far had pass every inspection to a non-open source program such as Bitlocker would be an insane move.
I sure hope the current audit of truecrypt will go forward to a conclusion.
The keys were indeed reuploaded, but from everything I've read they're the same keys they've been using for the past decade.
TrueCrypt is dead and over. No possible explanation exists which leaves the code trustworthy at this point. Maybe a fork of the existing code base could be considered trustworthy some day, but TrueCrypt is over. You don't have to replace it with bitlocker, but you need to find a replacement.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
