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: 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
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (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