7.2 was stripped of encryption functions. Even if it was without bugs, what good is it? Not to mention the weird way they walked away from their software.

It really was weird. Here's my new theory:

These guys released their best version ever, 7.1a, in Febuary 2012. They had a party, said goodbye, and moved on with their lives. Everyone assumed that since it's open source, some new guys would come along to take over the project. Instead, for two years, there were no security updates, and no credible fork. TrueCrypt was languishing. One of the developers decided to force the world to take action. He pulled that amazing stunt, complete with recommending everyone use Microsoft BitLocker. Now he's kicking back with a beer and watching the world go nuts. It's like kicking an ant hill.

Did it work? You bet! A bunch of geeks like me said, "I want to help!" A couple of Swiss Pirate Party dudes said, "We'll lead the effort", and before the weekend was over, they had thousands of offers for help. True to the Pirate Party spirit, they even pirated the TrueCrypt name: truecrypt.ch. Also true to the Pirate Party spirit, they don't really know how to organize a team of geeks to work together in a common direction. So, I said "Follow me!" on the forum, and signed up geeks as fast as I could at the site that became CipherShed.org. Now they're self-organizing like some sort of slime mold, creating order out of chaos. It's really fascinating to watch! I hope the original authors are enjoying the drama :-) At this point, I think the new team is going to do amazing things.

I believe I read about this guy on slashdot a year-ish ago. He verified the Windows binary comes from the official source. I replicated most of his steps, until I became a believer. It is the actual source used to compile the 7.1a binary.

Now, if you're afraid of back-doors, be afraid of what is already in the official source, all 110K+ lines of it.

DIST truecrypt-7.1a.tar.gz 1949303 SHA256 e6214e911d0bbededba274a2f8f8d7b3f6f6951e20f1c3a598fc7a23af81c8dc

Excellent. That's what I just got for the source we're using to build the CipherShed fork of TrueCrypt.

Source package (not Linux) sha256sum: e6214e911d0bbededba274a2f8f8d7b3f6f6951e20f1c3a598fc7a23af81c8dc

That's what I just signed in the first ever signed git commit of the CipherShed fork of TrueCrypt. It's been a crazy week over there!

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.

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.

You're right. I guess it is just about impossible to build a truly secure OS. OpenWall tries, though I haven't checked it out properly and don't really know how secure it is, though it's designer is a genius. It seems that isolation from the Internet is the safest way to maintain privacy. Also, close your window blinds and never leave the house :-)

I agree that users who are highly concerned about their privacy should avoid Windows, as well as Mac OS X, and likely use some version of GNU/Linux, and air gap their system. However, even Snowden felt he needed to use Windows, and TrueCrypt was likely good enough for his purposes. I haven't read about how he used TrueCrypt, but I imagine that the hidden volume might have been handy.

Places this laptop I'm using may have back doors: Windows, Lenovo software, Lenovo motherboard, Intel CPU, Intel FDE SSD, BIOS, Intel WiFi driver and hardware, Cygwin, TrueCrypt, and any of about 100 binary-only programs I've installed from the Internet. It may have been infected by my Android phone when I connected it, or by the stupid binary-only VPN client our company pays for since it felt the free open-source OpenVPN solution was insecure. GNU/Linux would help, but mostly because I would only install a dozen or so binary-only programs (Skype, NVDA driver, DVD player, Steam...). I have some concerns that my Arch mirrors have been overridden, as some package updates seem to be fishy (security configuration in Apache had syntax errors, yet the package was properly signed...). This stupid method of distributing binary packages from a central repository also smells like something governments would like.

My laptop is a radioactive pile of shit for security, whether or not I use Linux. TrueCrypt also has shit-for-brains password hashing, and wouldn't do anything about it, so I already suspected that the TrueCrypt devs were being pressured somehow.

True, and they are far superior in terms of making the best use of the bamboo fibers. For example, they can steam flatten the crown so that the fibers on the outermost part of the crown (which are far denser than in the interior) are not over-stressed, and the load can be shared by more of the outer fibers. I didn't do that, and the efficiency of my bow is far less than is possible with such technology. However, even the yumi bows fail to make use of beneficial lamination stresses. I got higher energy density per unit limb mass than even yumi bows, though mine still isn't nearly as good of a bow, not by a mile. I just like the physics :-)

I used it for some awesomely light bow limbs for their energy storage.

Thanks for the link. I read: The jury found that Google infringed Oracle’s copyrights in the 37 Java packages and a specific computer routine called “rangeCheck,”

Fuck rangeCheck. I don't care if Oracle gets $1B for that stupid 10-line function that any moron could write in 5 minutes. Oracle succeeding in copyrighting an API, which last a freaking 100 years, is death to our industry.

It's not just the dumb 2-year contract scam. We're also being fleeced for voice contracts, on both our land-line and mobile, because the phone companies prefer to continue charging a 1970's service charge for something that modern networks deliver practically for free. T-Mobile doesn't need 850MHz spectrum. They need free VoIP over WiFi whenever you're indoors at work, home, or a friend's house.

Fortunately, there's a new kid on the block, Republic Wireless, who is doing contract-free ultra-cheap service. By offloading traffic to your own home wifi, RW can in theory make money $25/mo for Sprint 3G "unlimited" service. That's the plan I have, and I have the $10 plan for my kids. Verizon 4G LTE was great (my previous phone was a Verizon/Google Galaxy Nexus), but for the $60/month savings on just one phone, I'll live with Sprint. Also, they've got the Moto-X for $300, contract free, and it's hands down the best phone I've had. Time will tell if sane service providers have a chance in this country.

Very cool! Thanks for the abstract and the tip for how to track down research. The abstract sounds about right to me. It's kids with reading difficulty that may benefit the most from combining listening and reading, with adjustable speed. I find that kids seem to have a different difficulties in early reading, and if it is too difficult, they wont start reading chapter books, and it is difficult for them to naturally ramp up their reading speed. Some audio help at that stage might help a lot.

Just for fun, if you want, go listen to the first chapter of the audio book I just read This is a 3.5X speedup of a voice that already reads above 150 wpm normally. It's probably around 600 wpm.

Another interesting, yet annoying case is my daughter, who I used as a subject for speed listening so often that she not only listens fast (she was already a pretty faster reader), but she's decided to talk fast, too. I don't know if this is a potential pitfall in your scheme :-)