Slashdot Mirror
TrueCrypt Audit Back On Track After Silence and Uncertainty
itwbennett writes: In October 2013 Cryptography professor Matthew Green and security researcher Kenneth White launched a project to perform a professional security audit of TrueCrypt, partly prompted by the leaks from Edward Snowden that suggested the NSA was engaged in efforts to undermine encryption. Their report, published in April 2014, covered the first phase of the audit. Phase two was supposed to involve a formal review of the program's encryption functions, with the goal of uncovering any potential errors in the cryptographic implementations—but then the unexpected happened. In May 2014, the developers of TrueCrypt, who had remained anonymous over the years for privacy reasons, abruptly announced that they were discontinuing the project and advised users to switch to alternatives. Now, almost a year later, the project is back on track.
They are the most trustworthy auditors the NSA, CIA, FBI, and the PTA could find.
You sound like someone new to the concept of 'independent audit'.
The suddenness of the TC team's departure (having throughout TC's history promised never ever to have any backdoor) coupled with the U.S. gov (FBI)'s inability to crack a South American's business computer after a full year of trying, suggests that their departure was a consequence of U.S. government pressure.
Recent disclosures by Mr. Snowden (Feb, 2015) make it clear that more than mere analysis of the TC code is necessary: the NSA's newly discovered ability to implant code-compromising elements in devices' firmware suggest just how difficult it might be for any analysis to confirm that TC is secure. TC could be perfect, but .. but their analysis must address topics beyond the TC code itself.
if HD firmware is able to read and share passwords then clearly much more work has to be done. I'm proud to have helped the crowd-source effort and wish this new team well
... TC could be perfect, but if HD firmware is able to read and share passwords then clearly much more work has to be done ... their analysis must address topics beyond the TC code itself.
I disagree. Taking your point to its logical conclusion, the TC auditors should audit every computer on Earth, and all the software running on those computers.
.
That is very clearly beyond the scope of auditing TC.
I do think the TC auditors should publish a caution of some sort about ~the computer that runs TC~ but beyond that, it would be out of scope.
I really would like to see Truecrypt live and usable again. Just in terms of having a great and useful interface/featureset Truecrypt was and hopefully will again be the best crypto out there. Assuming it audits well of course.
Truecrypt inside BTsync would be amazingly powerful.
Pug
An Invisible Entity of Vast Power whose existence must be taken on faith alone: Liberal Media
So an audit performed by a closed group of corporates who have, no doubt, been thoroughly vetted and has never, ever, ever gotten a phone call from anyone in a suit offering them the choice of a bag of cash to play ball, or an increased probability of "accidents" and "unfortunate data leaks."
Given the farewell address we got from the TC devs, which I'm sure most of us remember, and the laughable suggestions of "alternatives," there are two strong possibilities for why the project was shuttered:
1. The developers all suffered a massive psychotic break at the same time.
2. A canary so big and obvious that it's more of a "warrant roc."
They may have ended the "silence", but the "uncertainty" is still alive and well, AFAIC.
What did the TrueCrypt developers have to do with the audit of TrueCrypt?
Is there a point to continue auditing a platform whose entire developer team has abandoned whilst urging all users to seek other encryption tools? At this point the audit is probably going to be interesting (related to the aforementioned dev abandonment), but not exactly useful... If you are still using Truecrypt, you have already been warned.
As such, a warrant would let people continue to use it, secure in the fact that it actually works as required.
It also lets people fork it.
Frankly, I have been severely disappointed with BestCrypt, which I had hoped would end up as the replacement for TrueCrypt. (multiple problems with getting the regular operating system to recognize the 'mounted' drives)
excitingthingstodo.blogspot.com
TrueCrypt isn't open source software, in spite of the author incorrectly claiming it is. More detail is here, which the author could have learned in 2 minutes of Googling: http://en.wikipedia.org/wiki/T... ... for your amusement, I have quoted it below:
TrueCrypt was released under the "TrueCrypt License" which is unique to the TrueCrypt software. It is not part of the pantheon of widely used open source licenses and is not a free software license according to the Free Software Foundation (FSF) license list, as it contains distribution and copyright-liability restrictions. As of version 7.1a (the last full version of the software, released Feb 2012), the TrueCrypt License was Version 3.0.
Discussion of the licensing terms on the Open Source Initiative (OSI)'s license-discuss mailing list in October 2013 suggests that the TrueCrypt License has made progress towards compliance with the Open Source Definition but would not yet pass if proposed for certification as Open Source software.
According to current OSI president Simon Phipps:
As a result of its questionable status with regard to copyright restrictions and other potential legal issues, the TrueCrypt License is not considered "free" by several major Linux distributions and is therefore not included in Debian, Ubuntu, Fedora, openSUSE, or Gentoo.
The wording of the license raises doubts whether those who use it have the right to modify it and use it within other projects. Cryptographer Matthew Green noted that "There are a lot of things [the developers] could have done to make it easier for people to take over this code, including fixing the licensing situation", and speculates that since they didn't do those things (including making the license more friendly), their intent was to prevent anyone from building on their code in the future.
End of life and license version 3.1
The 28 May 2014 announcement of discontinuation of TrueCrypt also came with a new version 7.2 of the software. Among the many changes to the source code from the previous release were changes to the TrueCrypt License — including removal of specific language that required attribution of TrueCrypt as well as a link to the official website to be included on any derivative products — forming a license version 3.1.
On 16 June 2014, the only alleged TrueCrypt developer still answering emails, replied to an email by Matthew Green about the licensing situation. He is not willing to change the license to an open source one, believes that Truecrypt should not be forked, and that if someone wants to create a new version they should start from scratch.
- David A. Wheeler (see my Secure Programming HOWTO)
[Backdoors are hard to find.] At this point with the exiting statement of the developers only a fool would trust Truecrypt with anything important.
Let's see: only a fool trusts things that actively lose data. (ie, bitrot, or email systems used by important people. If it's important, have 2+ independent copies)
So let's posit that TC is "sane", that it doesn't actively corrupt your data (Actual disk bitrot is another matter.)
Is it secure? (Ignoring keyloggers, CPU tampering, OS-file I/O interception, not to mention on-bus DMA controllers that have direct access to physical memory, and other out of band things? You could argue they need to detect this but they aren't an A/V vendor and you do halfway have to trust your hardware. Oh, visit CC PIN hacking via a IR camera to see your hardware "betray" you.)
Well, given a correct encryption key, things work correctly; given seemingly any incorrect key, things don't -- a very good start. So they need to protect the working in-memory key (because it's game-over if not.) They erase it if enough idle time has passed and try to keep it from being swapped out to disk. Process memory isolation is great, but in both cases the OS itself can do whatever it wants. So you have to trust the OS, at least a bit.
So, what everybody actually means: is the encryption secure? Can someone who doesn't know my password read my data due to stupid password handling, bad encryption routine choices (ROT-26), or leaky code of good routines? (Say perfect AES file encryption, but the unencrypted source file moved to the recycle bin, never mind about any corruptible buffer or stack overflows. [That's an example; TC doesn't encrypt single files.] ) Are there password collisions, ie password are actually case-insenstive? or silently truncated after 2 characters?
I suspect that you're (humans) the weakest link because of the XKCD wrench, an easily guessed password, or your likes/habits that could lead to your password. If you can't type your password it's not going to work, and you have to remember how to type it.
It seems to boil down to do you trust the vendor to act in good faith every step of the way? Let's see: -anonymous vendor, +access to source code that compiles to the released binary, +routine usage that makes sense, +updates over time, -weird final message. Personally, i trust them more than MS's native BitLocker, which is sane but has a (understandable) business-released AD key recovery function. (It's not your data but the companies, and they have keys to continue read it.) But is BL actually secure? Dunno, can't tell; we have to trust MS completely on that.
If it (TC v7.1) was good to use the day before sunset, it was good to the use day after too, until known problems arise or non-OS support kills it. But YMMV -- trust whom you see fit. So being curious: what are you using, if not TC?
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?