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.

8 of 112 comments (clear)

  1. Re:Hmm? by Anonymous Coward · · Score: 5, Interesting

    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
    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 .. but their analysis must address topics beyond the TC code itself.

  2. Re:Hmm? by QuietLagoon · · Score: 4, Interesting

    ... 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.

  3. Really Glad to see this by pugugly · · Score: 5, Interesting

    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
  4. Re:Um, by jeffmeden · · Score: 4, Interesting

    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.

  5. TrueCrypt is not open source software. by dwheeler · · Score: 5, Interesting

    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:

    ...it is not at all appropriate for [TrueCrypt] to describe itself as "open source." This use of the term "open source" to describe something under a license that's not only unapproved by OSI but known to be subject to issues is unacceptable.

    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)
  6. Re:Um, by grep+-v+'.*'+* · · Score: 5, Interesting

    [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?
  7. Pissed off developers needed money by Anonymous Coward · · Score: 2, Interesting

    I suspect Truecrypts real fate was the fundraising for it. Truecrypt promoted donation for it on their website to continue development. I was tempted to donate a big wad of cash, but only after audit.

    The fundraiser for the AUDIT of Truecrypt got a lot more money than the fundraising for Truecrypt, I suspect, and so the developers said f*** it and pulled the plug in disgust.

    Fair enough, their work deserved money and they weren't getting it.

  8. Re:Um, by grep+-v+'.*'+* · · Score: 2, Interesting

    we DON'T know if 7.1 was safe to use or not.

    Isn't that kinda the point of a security audit?

    Really, my personal tin-foil take (and I know actually know, I'm just guessing from the reported results and my internal biases) is that the TC authors were "given an offer they couldn't refuse" and forced to hand over the control of the website and code signing keys to someone else.

    THAT they did -- but they were not told NOT trash the brand beforehand. So in my happy little fantasy world they put that weird final notice and gleefully handed over the control keys to the code, knowing that no one would ever use any new code originating from it again. Thus complying with the letter of the law, if not quite the imposed spirit of it. (And then survived to tell the tale, or at least managed to survive the encounter. I hope.)

    On a completely different topic, antagonizing people with guns is never a smart thing to do. But sometimes it is the right thing to do. Maybe we should ask Paul Revere or another American patriots from years past -- I hear they bothered men with guns a long time ago, too.

    (I don't suppose we could give DC -- it's not a state -- back to the British and fund a new capital somewhere? I'd suggest somewhere in Washington State; that way we wouldn't have to change the stationary THAT much.)

    --
    If the universe is someone's simulation -- does that mean the stars are just stuck pixels?