Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Friday April 03 2015, @01:07PM   Printer-friendly
from the and-the-people-rejoice! dept.
takyon, zorax, and an Anonymous Coward all write:

Open Crypto Audit Project has completed "Phase II" (PDF) of its audit of the TrueCrypt source code. The security audit of TrueCrypt, a freeware disk encryption utility, was crowdfunded in October 2013, before the TrueCrypt Foundation's mysterious shutdown on May 28, 2014. In his blog post describing the findings, Matthew Green says:

The TL;DR is that based on this audit, Truecrypt appears to be a relatively well-designed piece of crypto software. The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.

That doesn't mean Truecrypt is perfect. The auditors did find a few glitches and some incautious programming -- leading to a couple of issues that could, in the right circumstances, cause Truecrypt to give less assurance than we'd like it to.

The most significant issue found involved TrueCrypt continuing to generate keys in a rare instance where the Windows Crypto API fails to initialize. This is not necessarily insecure because TrueCrypt "still collects entropy from sources such as system pointers and mouse movements."

In addition to the RNG issues, the NCC auditors also noted some concerns about the resilience of Truecrypt's AES code to cache timing attacks. This is probably not a concern unless you're [performing] encryption and decryption on a shared machine, or in an environment where the attacker can run code on your system (e.g., in a sandbox, or potentially in the browser). Still, this points the way to future hardening of any projects that use Truecrypt as a base.

One project that could benefit from the audit's findings is VeraCrypt, a freeware fork of TrueCrypt licensed under the Microsoft Public License and also subject to the TrueCrypt License, which uses a substantial amount of TrueCrypt code. Matthew Green has speculated that the intent of the TrueCrypt developers' licensing and shutdown decisions was to stir uncertainty over the project and force new disk encryption projects to start from scratch.

For additional analysis of the audit, see the articles by ArsTechnica's Dan Goodin, the Register and Threatpost.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Informative) by Anonymous Coward on Friday April 03 2015, @02:32PM

    by Anonymous Coward on Friday April 03 2015, @02:32PM (#166116)

    I've got original binaries from before the big stink with Truecrypt. The 7.1a's.

    This site:
    https://www.truecrypt71a.com/downloads [truecrypt71a.com]

    Still has the originals too. I've verified the Windows and Linux 64 bit one's sha256 sums. They match what I have.

    Source: Some random anon coward...I know. But there you go.

    • (Score: 5, Informative) by wantkitteh on Friday April 03 2015, @02:43PM

      by wantkitteh (3362) on Friday April 03 2015, @02:43PM (#166119) Homepage Journal

      Gibson Research Corporation (aka: Steve) also has a mirror [grc.com]. Defuse have Hashes [defuse.ca] as well. Verification with other parties is, of course, recommended.

  • (Score: 4, Informative) by DrMag on Friday April 03 2015, @02:47PM

    by DrMag (1860) on Friday April 03 2015, @02:47PM (#166120)

    Any reason for not also acknowledging CipherShed [ciphershed.org] as well?

    • (Score: 4, Funny) by takyon on Friday April 03 2015, @03:37PM

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Friday April 03 2015, @03:37PM (#166128) Journal

      I was going to let you do it.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 0) by Anonymous Coward on Saturday April 04 2015, @02:40AM

      by Anonymous Coward on Saturday April 04 2015, @02:40AM (#166282)

      Pick a saner license scheme, and I may reconsider my support.

      Until then, don't let the door hit you...

  • (Score: 5, Informative) by fadrian on Friday April 03 2015, @02:48PM

    by fadrian (3194) on Friday April 03 2015, @02:48PM (#166122) Homepage

    If this [bell-labs.com] hadn't been done ten years before he talked about it, it was done the next week before anyone could think of an actual check. Have you disassembled your code lately?

    --
    That is all.
  • (Score: 2) by Balderdash on Friday April 03 2015, @03:52PM

    by Balderdash (693) on Friday April 03 2015, @03:52PM (#166132)

    ROT13 everything twice just to be safe.

    --
    I browse at -1. Free and open discourse requires consideration and review of all attempts at participation.
    • (Score: 2) by takyon on Friday April 03 2015, @04:47PM

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Friday April 03 2015, @04:47PM (#166142) Journal

      You need to use ROT-13 a minimum of 8192 times to be secure.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 4, Funny) by Anonymous Coward on Friday April 03 2015, @05:48PM

        by Anonymous Coward on Friday April 03 2015, @05:48PM (#166153)

        But with each successive generation the bits slowly rot. You need to use oxygen free wires to get anywhere near 8192 and not be able to hear the clarity of the data still. The warmth of the bits is just as important here.

    • (Score: 3, Funny) by doublerot13 on Friday April 03 2015, @11:21PM

      by doublerot13 (4497) on Friday April 03 2015, @11:21PM (#166246)

      This...

  • (Score: 3, Interesting) by FatPhil on Friday April 03 2015, @10:45PM

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Friday April 03 2015, @10:45PM (#166236) Homepage
    "The most significant issue found involved TrueCrypt continuing to generate keys in a rare instance where the Windows Crypto API fails to initialize."

    I wonder what could cause the Crypto API to fail to initialise?
    If it's something untoward, something malicious, could it also not subvert the Windows Crypto API after it's been initialised?
    Which leads me to the question - how well does TrueCrypt behave if the Windows Crypto API *has* been subverted?

    It's paranoia all the way down...
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 0) by Anonymous Coward on Saturday April 04 2015, @12:57AM

      by Anonymous Coward on Saturday April 04 2015, @12:57AM (#166259)

      I wonder what could cause the Crypto API to fail to initialise?

      Space background radiation hitting your RAM at an inopportune time. No, I'm not kidding, it's astronomically unlikely but RAM bits can rarely get flipped like that.

      More likely potential points of failure include messed up system libraries (usually by user incompetence or filesystem corruption), bugs in a future release of the library and broken third-party software.

    • (Score: 2) by takyon on Saturday April 04 2015, @01:04AM

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Saturday April 04 2015, @01:04AM (#166261) Journal

      The Truecrypt developers implemented their RNG based on a 1998 design by Peter Guttman that uses an entropy pool to collect 'unpredictable' values from various sources in the system, including the Windows Crypto API itself. A problem in Truecrypt is that in some extremely rare circumstances, the Crypto API can fail to properly initialize. When this happens, Truecrypt should barf and catch fire. Instead it silently accepts this failure and continues to generate keys.

      This is not the end of the world, since the likelihood of such a failure is extremely low. Moreover, even if the Windows Crypto API does fail on your system, Truecrypt still collects entropy from sources such as system pointers and mouse movements. These alternatives are probably good enough to protect you. But it's a bad design and should certainly be fixed in any Truecrypt forks.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 2) by FatPhil on Sunday April 05 2015, @09:43AM

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Sunday April 05 2015, @09:43AM (#166604) Homepage
        It's a similar argument to the linux kernel / intel RNG fuss. Except in some corner cases, there's never any harm in adding any quantity of untrusted source data to the generator, so you may as well do it even if you don't trust the source. Of course, if you don't trust the OS you've got bigger problems, as the OS can sniff your plaintext anyway.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
  • (Score: 2) by kaszz on Saturday April 04 2015, @02:09AM

    by kaszz (4211) on Saturday April 04 2015, @02:09AM (#166274) Journal

    Now we just need an audit of the crypto algorithms them selves. And of course implementation specific kernel bugs.

  • (Score: 2) by edIII on Sunday April 05 2015, @04:53AM

    by edIII (791) on Sunday April 05 2015, @04:53AM (#166565)

    While the time-boxed nature of the engagement prevented auditors from reviewing the source code in
    its entirety
    , the most relevant areas were investigated thoroughly. The assorted AES implementations
    in both parallel and nonparallel XTS configurations were a particular point of focus.

    -- Open Crypto Audit Project TrueCrypt

    No Backdoors Found in TrueCrypt

    It's a great start, but a full audit hasn't been performed yet. Something I think we need before we can clear TrueCrypt completely and be able to trust it again.

    --
    Technically, lunchtime is at any moment. It's just a wave function.
    • (Score: 1) by Fauxlosopher on Sunday April 05 2015, @06:09PM

      by Fauxlosopher (4804) on Sunday April 05 2015, @06:09PM (#166714) Journal

      before we can clear TrueCrypt completely and be able to trust it again.

      "Again"? What causes you to believe that anything has changed with TrueCrypt 7.1a to render it untrustworthy? The hashes and checksums from copies obtained years ago match those of the latest copies hosted by Gibson Research, et al. If someone trusted TrueCrypt before, there has been no new compelling evidence to suggest existing copies are somehow less trustworthy now.