Audit of TrueCrypt disk encryption software reveals low source code quality

by
in security on (#3HZ)
Back in October 2013, Kenneth White and Matthew Green kicked off the idea to do a full and complete audit of TrueCrypt, the most popular disk encryption package out there. They raised over $60,000 dollars and 33BTC to this end, and got underway.
The first part of the audit - the in-depth source code review - was performed by a security firm and completed on April 14 of this year ( report ).
The results are interesting to read. No bogeys have been found so far, though 11 medium-to-minor items were identified. But the authors did note:
Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for secure code. This includes issues such as lack of comments, use of inse-cure or deprecated functions, inconsistent variable types, and so forth.

The next stage, cryptanalysis , has begun and is proceeding.
I'm sure plenty of people are thinking, "How about doing the same thing for OpenSSL?" I'd personally prefer to see this sort of effort going into improving the OpenSSL software.
Reply 7 comments

OpenBSD team is looking at OpenSSL (Score: 4, Interesting)

by zocalo@pipedot.org on 2014-04-16 13:27 (#13E)

It's long overdue for an independant audit, IMHO, but the OpenSSL code is now getting a review and code clean up by the OpenBSD team and they certainly know their stuff. Whether the results and reporting on their findings will be as in-depth as the TrueCrypt audit remains to be seen, but it's still infinitely better than nothing. Really this ought to be the kind of the thing that the various FL/OSS projects should be pushing for from their commercial users as well as contributions to the code base itself. No in-house devs to help with contributions to the code, fine, then how about contributing some funds for an independant code audit instead? Help us make your systems more secure!

Update Schedule (Score: 3, Insightful)

by tempest@pipedot.org on 2014-04-16 13:53 (#13F)

Perhaps Truecrypt can be considered mature software, but I highly doubt (with all that it does), that there aren't bugs requiring fixes. The last release was early 2012, and about one per year before that. With all that it does, I'd expect a far more frequent update releases. Truecrypt has always worked well for me, but I wonder how much the project is stagnating.

Re: Update Schedule (Score: 2, Insightful)

by nightsky30@pipedot.org on 2014-04-16 19:06 (#13K)

My coworker has stated a few times that he once encountered a corruption with an encrypted volume he created using TrueCrypt. I've never experienced this myself. From an outsider perspective, I thought the application was fairly stable myself. It has worked quite well. I welcome this analysis. Could they do the same for Keepass? http://www.keepass.info

this is where open source (Score: 1)

by rocks@pipedot.org on 2014-04-17 04:01 (#13M)

Probably ought not to mean free or volunteer only. I definitely feel that government agencies globally should be pushing for adoption of open source software with free licenses, but where public money is paid to drive forward the development and auditing and such.

Re: this is where open source (Score: 1, Interesting)

by Anonymous Coward on 2014-04-17 14:42 (#13S)

I think it goes a step further: it shows a need for extremely stringent code analysis to be done by *qualified* people. We need more Theo de Raadts looking at code that affects internet security. These people exist, but most of them are either looking at software that powers your car or airplane, or they are in the military, reviewing code that's used in weapons. These are places that don't have much leeway when it comes to errors. I don't understand why encryption protocols should be any different.

Re: this is where open source (Score: 0)

by Anonymous Coward on 2014-04-23 19:29 (#15G)

Whoa, Pipedot allows ACs now? That was the only reason I was avoiding the place in favor of Soylent.

Very nice change!

Comments? (Score: 2, Informative)

by fatphil@pipedot.org on 2014-04-17 16:50 (#13W)

"... expected standards for secure code. This includes issues such as lack of comments ..."

I've worked in some security-related areas, and I hate 99% of comments. Make the code intrinsically readable and obvious. If you have to explain your code, then it's not written clearly enough. And heaven forfend that the comment says something nice and reassuring, yet the code itself actually has a flaw - that comment would be worse than useless, it's downright dangerous.