Slashdot Mirror
TrueCrypt Cryptanalysis To Include Crowdsourcing Aspect
msm1267 (2804139) writes "A cryptanalysis of TrueCrypt will proceed as planned, said organizers of the Open Crypto Audit Project who announced the technical leads of the second phase of the audit and that there will be a crowdsourcing aspect to phase two. The next phase of the audit, which will include an examination of everything including the random number generators, cipher suites, crypto protocols and more, could be wrapped up by the end of the summer."
Why? It is already open sourced.
You just might want to look 'Diverse Double-Compiling' as a method of countering the attack described by Ken Thompson in 'Reflections on Trusting Trust'. A paper on DDC is at http://www.acsa-admin.org/2005...
Well,
Since Truecrypt has decided to drop their project, and the project has been opensourced from day one, I'm going to suggest this is a good time for a fork.
It would (will) be educational to see who goes to court to stop it.
Don't take life too seriously; it isn't permanent.
TrueCrypt's source code is based on the earlier tool, Encryption For The Masses (E4M) [1997] by Paul LeRoux, who abandoned it in 2000 when he joined SecurStar to make the closed-source DriveCrypt with Shaun Hollingworth (who wrote a predecessor, Scramdisk). That's why the licence looks the (horrible) way it looks; it's an update of the E4M licence.
When the TrueCrypt Team released the first version of their fork, the project lead David Tesarik got a whole bunch of nastygrams from a manager at SecurStar who alleged Paul LeRoux had stolen E4M from them and open-sourced it without their permission: https://groups.google.com/forum/#!topic/alt.security.scramdisk/HYa8Wb_4acs
Which was complete bullshit, of course, as E4M had been opened years before SecurStar existed and they themselves published it on their website under the E4M licence, so nothing actually came of it - except 9x support was removed because it used Shaun's 'Scramdisk' driver, and he hadn't given permission to distribute with E4M if the name was changed, hence 1.0a.
Wouldn't be surprised if there was a Slashdot article about it. Peter Gutmann suggested it'd be right up /.'s alley. :) /akr
This is what we are seeing in the field. A number of large financial institutions and government organizations who we deal with on a regular basis have already told us that they are no longer going to use TrueCrypt.
Most of them are moving towards SecureZip from PKware because it supports AES-256 and is FIPS 140 compliant. Others seem to be okay with 7Zip's "encrypted zip" feature (also AES-256). Others are looking at random packages that I have never heard of before last week, like BestCrypt. Of course there are others who want to go with Symantec's PGP.
This has proven to be a major pain the ass. For all of its warts, TrueCrypt was the de facto standard for secure data exchange. Now we are seeing a Balkanization of encryption software, and organizations are moving in different directions.
Personally I think that TrueCrypt is good enough for transferring data on an external USB drive and protecting it against accidental or intentional theft (by anyone other than the NSA). However it is going to be impossible to convince others of that, and I cannot state it with 100% certainty so I am not even trying to have that conversation within the business context.
As long as Client X is demanding encryption tool Z, that is fine. We will use that tool and let them shoulder the risk. After all, they are telling us what to use, not the other way around.
Why did you trust it in the first place? You trust unaudited code because the author says its fine but won't trust audited code that the author abandoned?
It open source but not FOSS.
You can't fork it. The license is actually highly restrictive. The only options are a total reimplementation using the GPL or BSD license or to keep using the last version in perpetuity.
The TrueCrypt source is also - by most accounts - a huge ungodly mess that hasn't seen a significant update in at least the past two years.
Not seen a significant update in at least two years, check. But huge, ungodly mess? Nah, 4.45 MB uncompressed, subtract 491 kB bitmaps and icons, 902 kB user guide, 117 kB license and readme texts in several versions, 250 kb string localization, 150 kB resource, project and solution files and you're talking approximated 2.5 MB code, divided into several logical directories. I skimmed the main files and they look decently formatted and commented, on the longish side but with plenty whitespace. I think probably under 100 kLOC total, a lot of it standard cryptographic primitives, installer, GUI and so on. Once you've made sure they don't contain any funny business the actual logical core seems to be more like 20-30 kLOC, quite manageable for one man to grasp.
Live today, because you never know what tomorrow brings
You can't fork it.
Are you sure.
The license is actually highly restrictive.
Insofar as lawyers don't like the wording as its a bit ambiguous on some fine details; but its not as restrictive you seem to think.
Moreover, for the license to actually be a problem someone would have to come forward, establish they actually have copyright standing, and then sue you over making a fork.
So what realistically what are the risks? That some anonymous devs who shutdown the project and have advocated everyone switch to alternative systems is going to come out of the woodwork to sue you for copyright infringment and 'damages' despite your best efforts to follow their license which DOES actually allow for forking, and for which you wouldn't be charging for copies. So there are no profits to sue for then there is the acute impossibility of you 'damaging' their interests given they discontinued the original project and burned it to the ground.
I honestly don't understand the fear. I mean sure there is a risk there, but if you incorporate a nonprofit, continue to give it away for free, and retain the terms of the license; the risk small.
Even if the authors did come out of the woodwork, and sue you, so what? So your non-profit shuts down - worst case. More likely by far to just walk away with little more than a cease and desist and/or a small fine, and that's assuming the court even finds against you (which given the ambiguity of the license, and your attempt to adhere to it as best as possible) isn't all that likely in the first place.
Yet, the lawyers say its 'highly restrictive' and 'dangerous' to anyone who goes near -- same lawyers who approved the non-compete clauses that now have silicon valley under a class action? Where was their sage advice about risk then?
Why would these organizations switch to unknowns? If they trusted truecrypt up to this point, why not continue to trust? These closed source applications could be backdoored and there's no way of really finding out. If you think source auditing is difficult, try auditing a binary.
It was never possible to trust truecrypt or anything else with 100% certainty.
Would you care to elaborate? The audit is by a third party, their trust could be verified; perhaps easier than trusting the unaudited TrueCrypt. Why is an audited 7.1 a security risk?
It's actually just a bit over 110 kLOC, but you were close. The crypto code is mostly very good. The GUI code must have been written by someone else, because it totally sucks, IMO. I was just porting it to wxgtk3.0 today from wxgtk2.8, and of course all the crypto compiled without even a warning, other than some AES code I need to look into. The GUI was a freaking nightmare. They implemented their own string class. How stupid is that? Well, they didn't just implement a string class, but they implemented a directory string class, a filename string class, a "volume" string class, a "volume info" string class, and about a dozen other string classes, most of which don't actually have any useful functionality, and just require all kinds of casting operators. Stupid stupid stupid...
I haven't looked at the firewall between the GUI and crypto code yet. Obviously there's a fuse driver in Linux and I would not expect it to link with the GUI code at all, but I need to check. Given that the crypto code rocks, and the GUI code sucks, it's critical that they be in separate processes. That would be needed in any case, since you can't trust all that GUI library code living in the same process as the crypto core.
Celebrate failure, and then learn from it - Nolan Bushnell
As of last weekend, it is in the process of being forked. New community site here
Best Crypt is made by Jetico, a finnish crypto software/hardware company that's been around since the early 90's. Their OTFE is top notch and the linux version is full featured with GUI. Both binary and source code packages for linux can be downloaded for free though they don't advertise it. In fact, Best Crypt was used in the Bill Clinton white house. Check them out: www.jetico.com
Who is going to stop you? The authors are anonymous so who could claim to be the copyright holder to come and stop you?
Write boring code, not shiny code!
From this security analysis there is a 64K-ish block in the header that is filled with random data in Windows, but encrypted 0's in Linux. There's no simple way to insure the Windows header is indistinguishable from true random data, but the Linux version should be OK. As for the rest of the unused portion of the volume, I haven't checked the code. If it's using a pseudo-random number generator that isn't cryptographically strong, then it may be distinguishable. However, the entropy argument seems wrong to me. If the unused portion has measurably lower entropy than true random data, then the random number generator in question must have been compromised.
Celebrate failure, and then learn from it - Nolan Bushnell