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.
> So finally, was the duress canary activated or not? If it is "still there" as according
> to that tweet, that should mean it was not activated.
If it was clear that it had been activated, then it would breach the NSL and the authors would be at risk of legal action. Therefore, you will not see a clear canary warrant.
There was no info in that tweet, and even Mathew Green doesn't know what they were talking about. It was just clickbait to take you to a site with old news.
The beauty of opensource is good projects never die.
http://truecrypt.ch/
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
The program (at 7.1a) is still completely useful for an individual or business to scramble personal/business records, in case the computer is lost or stolen, or the overnight cleaning lady is snoopy, etc.
It does address the issues you mentioned. As for the tool chain (compiler, linker, loader, etc), that is addressed by making them diverse. The term 'compile' means the entire chain from source to binary which includes the entire tool chain. As for the CPU issue, there's nothing in the source that mandates that you must create a binary for the same CPU as you're executing on. So do DDC on multiple CPU families (Intel, ARM, PPC, etc) and compare the final results. And the beauty of DDC is you can do it even if the tools you're using have been compromised. The only requirement is that the tools not be compromised in EXACTLY the same way. Any difference in the actual behavior of the tool chain will result in a difference in the output to be compared. If you're extremely paranoid, there's nothing preventing you from executing the tool chain inside an emulator to bypass any issues you might have with microcode.
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.
He is wrong and it was only ever a strong hypothesis on his part. Newer research shows that it is a lot easier to build in a way that excludes compiler backdoors: http://www.dwheeler.com/trusti...
The idea is fascinating. It basically says if you have a really crappy and simple compiler that can compile your code and that you can trust, you can propagate that trust on a really good and complicated compiler. Writing a crappy and simple C compiler can be done in a few weeks.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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?
A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
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.
Hand-compile, then hand-assemble, and finally poke opcodes into RAM with front-panel switches.
No, I'm not kidding.
Welcome to the Panopticon. Used to be a prison, now it's your home.
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
Where do you get this? When I read the license it reads largely to be less restrictive than GPL 3.0. Section III of the license discusses exactly what is required to create derivative products. Basically, you have to make sure that no one will confuse it with TrueCrypt, you have to make the source available, and you can't change the license.
The only problem I can see with it from the perspective of the people around here is that it wasn't spawned by Stallman.
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
Software doesn't 'wear out.' If it's not buggy, it will stay buggy. If it's working, it will stay working.
Only true if you never upgrade any part of the system it runs on. Any upgrade to the OS or its dependencies (the dependencies of those dependencies, ad infinitum) and you risk introducing bugs.
Then put YOUR ass on the line and do what you suggest. Suggesting other people put their asses on the line for your benefit just means you're a dick.
You seem to be taking this rather personally. Why? vux984 can't make you or me or anyone else do what they don't want to do, even if he does suggest it would be okay to do so. The "dick" accusation is a petty way to state your disagreement.
I am not a crackpot.
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!
A lot of GNU tools haven't been updated in around two decades yet no one feels like they need to be rewritten.
If it ain't broke don't try to "fix" it.
I was shocked to find out the other day that the cron most Linux distributions use was last updated in 1993.
How have the requirments of cron changed in lthe last 20, even 40, years?
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
Then put YOUR ass on the line and do what you suggest. Suggesting other people put their asses on the line for your benefit just means you're a dick.
Yeah, that's the only possible explanation for the fact that I haven't done everything in life that I think is possible, or could or should be done by someone.
No worst case is that because your infringement is willful they go after your personal assets.
Infringement is not willful. There is a clear good faith argument that the license was being followed.
But prove me wrong, get out there and spend your time and money to fork code you can't legally fork and put your ass on the line that none of the developers will decide they see a payday in your infringement.
What payday? Its a single title, not being sold for money. Actual damages to the original author are ZERO. Theoretical damages to the original author are ZERO. What does that leave?
Statutory damages.
That maxes out at 50k in the US that's if its proven willful.You really telling me that's a risk silicon valley tech companies can't afford?
And that's WORST case. And the odds of that happening are astronomically small. Far far far more probable its a cease and desist and a small fine; assuming you don't settle out of court before it even gets that far.