Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Encryption Security

TrueCrypt Audit: No NSA Backdoors 142

Mark Wilson writes: A security audit of TrueCrypt has determined that the disk encryption software does not contain any backdoors that could be used by the NSA or other surveillance agencies. A report prepared by the NCC Group (PDF) for the Open Crypto Audit Project found that the encryption tool is not vulnerable to being compromised. However, the software was found to contain a few other security vulnerabilities, including one relating to the use of the Windows API to generate random numbers for master encryption key material. Despite this, TrueCrypt was given a relatively clean bill of health with none of the detected vulnerabilities considered severe enough to lead "to a complete bypass of confidentiality in common usage scenarios."
This discussion has been archived. No new comments can be posted.

TrueCrypt Audit: No NSA Backdoors

Comments Filter:
  • Where's the fun in there not being any nefarious evil backdoors??!?!?

    How am I supposed to feed my narcissistic persecution complex that the NSA is focusing billions and billions of dollars of resources just to spy on me and me alone when they can't even put a backdoor in TrueCrypt??!?!?

    • by Anonymous Coward on Friday April 03, 2015 @08:24AM (#49397149)

      Look everyone, a NSA shill.

    • by MrL0G1C ( 867445 )

      Of course there are back doors, the NSA got to them. 'There are no back doors' - that is what they want you to believe ;-)

      • by KGIII ( 973947 )

        You do realize that TrueCrypt is out of development and the shop's been shuttered, yes?

        • Re: (Score:2, Informative)

          by Anonymous Coward

          You do realize that TrueCrypt is out of development and the shop's been shuttered, yes?

          Wrong. It's been forked:
          https://truecrypt.ch/
          https://ciphershed.org/

          And well before that it was reverse engineered:
          https://github.com/bwalex/tc-play

          • by Anonymous Coward

            Ciphershed.org is based on a rebranding of the original TC 7.1a which was the 2nd to last version. I have a copy of the installer of the 7.1a of TC.

            I wonder what the actual difference would be in terms of security between the two?

          • by KGIII ( 973947 )

            Sweet! Much appreciated, I didn't dig any deeper than the TrueCrypt site (I guess I should have). The question is, then, do THEY have any NSA backdoors? There was a time when I'd have simple trusted open source but these days there is so much and so few eyeballs. Either way, I appreciate your reply a great deal. I will play with both later this afternoon when I have a bit more free time.

      • ....these are not the back doors you are looking for......
    • by Anonymous Coward

      You're trying to belittle the legitimate concerns people have had towards the security of their software. It's not working.

      We already know of routers compromised en massé, mass collection of *everyone's* even seemingly irrelevant data (yours included), false flag hacking and whatnot. So yes, go ahead and crack a joke about the cornerstone of democracy and freedom of speech being slowly corroded away. Don't expect anyone to laugh, though.

  • by Anonymous Coward

    Now we just need an audit of the auditors to make sure they weren't compromised and we can safely use TrueCrypt again.

  • Tin foil hat time (Score:3, Insightful)

    by OzPeter ( 195038 ) on Friday April 03, 2015 @08:00AM (#49397031)

    Wasn't the NSA accused of suggesting/modifying various encryption standards in order to weaken them? In which case they don't need back doors into the software as they can already unlock the data.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Why don't you go inform yourself as to which encryption standards those were and then come back and actually contribute to the discussion, instead of mindlessly speculate?

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Why don't you go inform yourself as to which encryption standards those were and then come back and actually contribute to the discussion, instead of mindlessly speculate?

        You don't want mindless speculation, yet you're reading Slashdot comments?

      • 'scuse me, but this here is mindless speculation. If you want serious discussion, take your time machine and set it for 1999.

    • Re: (Score:2, Interesting)

      Wasn't the NSA accused of suggesting/modifying various encryption standards in order to weaken them? In which case they don't need back doors into the software as they can already unlock the data.

      Yes, and the authors of said algorithms (CS researchers) agree that that was ok (a security - speed/implementation tradeoff).

      • Which algorithms are we talking about?
        • Re:Tin foil hat time (Score:5, Interesting)

          by Andy Dodd ( 701 ) <atd7@cor[ ]l.edu ['nel' in gap]> on Friday April 03, 2015 @08:42AM (#49397257) Homepage

          The only case I know of where an algorithm was actually backdoored was one of the random number generation schemes... The algorithm in question happens to be (IIRC) quite fast.

          In other cases (DES I think??? I could be wrong.) the NSA recommended some oddball changes. No one could find a negative consequence of them so they went in - a decade or so later, it turns out that the original implementation of DES DID have a cryptographic flaw and the NSA recommendations fixed that.

          Keep in mind there are two parts of the NSA, ones which have in many ways highly conflicting goals:
          1) One part is tasked with compromising the information infrastructure of our enemies - these are the ones who keep on making the news these days
          2) Another part is tasked with protecting our critical information infrastructure, especially with protecting data sensitive to national security. These are the people who do Type I crypto certification, worked on creating SELinux, etc. These rarely make the news but in general, from our perspective these are the good guys. You can tell that AES-256 is NOT backdoored by the NSA since they allow it to be used to protect classified information (NSA Suite B - you can assume anything in Suite B is solid since the NSA is using it themselves.)

          • Re:Tin foil hat time (Score:4, Informative)

            by chihowa ( 366380 ) on Friday April 03, 2015 @10:08AM (#49397841)

            The only case I know of where an algorithm was actually backdoored was one of the random number generation schemes... The algorithm in question happens to be (IIRC) quite fast.

            The random number generator, Dual_EC_DRBG [wikipedia.org] is actually very very slow. If it wasn't pushed so hard, nobody would willingly use it.

            In other cases (DES I think??? I could be wrong.) the NSA recommended some oddball changes. No one could find a negative consequence of them so they went in - a decade or so later, it turns out that the original implementation of DES DID have a cryptographic flaw and the NSA recommendations fixed that.

            In addition to fixing the S-boxes as you described, they also recommended reducing the key size, which made the algorithm weaker and shorter lived.

            Dual_EC_DRBG was required for FIPS 140-2 certification, which is required for software that is used to protect sensitive-but-unclassfied information by the US government. So there is some conflict between the two goals above.

          • Re:Tin foil hat time (Score:4, Informative)

            by swillden ( 191260 ) <shawn-ds@willden.org> on Friday April 03, 2015 @10:21AM (#49397941) Homepage Journal

            In other cases (DES I think??? I could be wrong.) the NSA recommended some oddball changes. No one could find a negative consequence of them so they went in - a decade or so later, it turns out that the original implementation of DES DID have a cryptographic flaw and the NSA recommendations fixed that.

            Specifically, the S boxes (essentially some translation tables used in the algorithm) in the original design were vulnerable to linear cryptanalysis, which is a cryptanalytic technique that involves constructing systems of linear equations representing the transformations in key portions of the algorithm, then applying mathematical analysis to deduce key and/or plaintext bits. Linear cryptanalysis was unknown in the academic world at the time, but it was apparently known to the NSA. The NSA's changes made DES resistant to linear cryptanalysis.

            However, the NSA also reduced the key size and block size from 128 bits to 56 and 64 bits, respectively. This likely made DES vulnerable to brute force attacks by particularly well-funded attackers (e.g., the NSA). Use of multiple DES operations in sequence overcomes this issue and Triple DES today is still considered to be quite strong. So, all in all, the NSA improved DES security. This isn't surprising because it was a core part of their mission; a mission that appears to have been deprecated in the post 9/11 world, but was still very important to the NSA in the 70s.

          • IIRC, recently, there were some constants the NSA suggested for elliptical-curve cryptography, and some informed speculation that the NSA might have a method of cracking that specific case. They fixed some problems with DES, but I think they were the ones who suggested the key length, which eventually turned out to be much too short. (Key lengths nowadays are typically 128 bits or more, and cannot be brute-forced with only the resources available in our Solar System.) Overall, I'd tend to trust NSA reco

        • Re:Tin foil hat time (Score:5, Informative)

          by Lord Crc ( 151920 ) on Friday April 03, 2015 @09:18AM (#49397447)

          There's talk that they influenced the decision of some recommended constants for Elliptic Curve Cryptography.

          You'll want to use constants that ensures the cryptographic strength of the algorithm, so picking them are non-trivial and hence a recommended set was published. This is the same for most algorithms. AES has constants and they are part of what makes the algorithm AES and not some other variant.

          Anyway, here's what Bruce Schneier said about ECC:

          I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.

          https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 [schneier.com]

          And here's a nice background on ECC:
          https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ [cloudflare.com]

    • Re:Tin foil hat time (Score:4, Informative)

      by mrchaotica ( 681592 ) * on Friday April 03, 2015 @08:19AM (#49397115)

      Truecrypt lets you pick which encryption algorithm (and key generation mechanism, IIRC) that you want to use. So just pick one that the NSA didn't compromise!

    • It's good to remember that the ones the NSA purposely weakened were flag by private experts as being suspect before they were even in place (so people avoided them) and then confirmed as being purposely weakened by the Snowden docs - so the bad ones were flagged - DuckDuckGo is your friend on that. You definitely wouldn't want to be doing the NSA's work though in spreading generalized FUD (fear, uncertainty, doubt) about this encryption application (so people don't use it) that was also pointed out as "sec
    • by plover ( 150551 ) on Friday April 03, 2015 @08:32AM (#49397193) Homepage Journal

      Yes, the NSA has been accused of colluding with RSA to promote the Dual_EC_DRBG random number generator as a standard, despite claims that it contained a backdoor. https://en.wikipedia.org/wiki/... [wikipedia.org] . The NSA has also been accused of interfering with standards that would enable ubiquitous effective encryption for popular communications tools, such as phones and email, resulting in the current hodgepodge of patchwork. Sure, you may use TLS to send and retrieve your email to and from your ISP, but the data is unencrypted in their servers, and is vulnerable to interception there. Your cell calls may be encrypted, but Chris Paget demonstrated at DEFCON how easy that is to defeat, using his almost legal homemade version of a Harris Stingray. And the encryption algorithms used by cell phones only protect the data flying over the airwaves, not on the cellular wired infrastructure which is already required to be vulnerable by CALEA.

      However, the existence of one backdoor in one algorithm does not prove or disprove the existence of backdoors in other algorithms. Most exploitable weaknesses we do know about come from either protocol flaws or implementation errors, and these auditors found evidence of neither.

    • by AmiMoJo ( 196126 ) *

      Snowden uses Truecrypt so if they have cracked it they are keeping it very quiet... Look at it this way, of you are less if a target than Snowden you are probably safe using it even if they do have a way in.

  • by OzPeter ( 195038 ) on Friday April 03, 2015 @08:01AM (#49397039)

    Is this a deliberate choice of quote,or just randomly apropos?

    You can fool all the people all of the time if the advertising is right and the budget is big enough. -- Joseph E. Levine

  • by sasparillascott ( 1267058 ) on Friday April 03, 2015 @08:14AM (#49397101)
    This was very reassuring to see and I'm very glad the audit was finished finally. The 2nd to the last version (v7.1a) is the gold standard for multi-platform encryption where you can be reasonably sure the NSA/FBI doesn't have a back door (or access to the keys) like they would with Bitlocker etc..
  • by Anonymous Coward

    "time-boxed nature of the engagement prevented auditors from reviewing the source code in
    its entirety"

    "...as it is difficult to fully test code on multiple operating systems and configurations."

    So in other words, they can't properly test the software and won't be able to.

    So in other words, this story is misleading and seems more like propaganda to help bolster TrueCrypt's reputation.

    • by lgw ( 121541 )

      "time-boxed nature of the engagement prevented auditors from reviewing the source code in
      its entirety, the most relevant areas were investigated thoroughly."

      Was the actual quote. Those spring FUD are NSA shills. There were two specific areas they highlighted for more auditing: checking that memory was always securely wiped, and checking oddball disk sector sizes. I'd be surprised if the former were an issue, but they have a point. The latter is exactly the sort of place where bugs lurk, in my experience.

      The most important thing they didn't audit, IMO, is the "hidden volumes" feature of TrueCrypt. I'm a bit skeptical of that myself, as steganography is in general a harder problem that cryptography. Hopefully another trusted group will continue the auditing effort via crowd funding.

  • Whoever you are, you are fantastic people. You've helped millions of people worldwide protect their privacy. And you even had to bear some mentally diseased cretins accusing you of being NSA guys.

    Thank you for the fantastic piece of software you have designed.

  • The NSA is monitoring this thread to identify all of you naysayers...

    • Hey, some of us fully support their warrantless search capacity. The TrueCrypt developers' farewell message suggesting that Mac users create a disk image with a null cipher was especially good advice and not at all a warrant canary that they'd been pressured! There is no man behind the curtain, people!

  • by buck-yar ( 164658 ) on Friday April 03, 2015 @08:35AM (#49397213)

    The shellshock bug went on for a long time with many eyes on the code. How do we know the auditors weren't outmatched and just missed the backdoor?

    • ^ This.

    • by squiggleslash ( 241428 ) on Friday April 03, 2015 @09:22AM (#49397487) Homepage Journal

      Who knows? On the other hand, the many eyes argument with ShellShock is dubious: most people who would have recognized it didn't realize the implications as they weren't looking at it from a security standpoint, and few people actually likely touched or had reason to view that part of the code.

      This story, on the other hand, is about an actual security audit. In theory, it is more comprehensive, the researchers were looking for bugs, had a security background and agenda, and so would likely have picked up on ShellShock had it been Bash they were auditing rather than TrueCrypt.

      I'm not suggesting there's no chance they've missed anything, but I am saying the process is considerably more thorough and less likely to make a mistake. Bear in mind TrueCrypt has had "many eyes" for a decade or so too. And "many eyes" did, eventually, pick up on ShellShock, it just took longer than anyone would hope.

      • So to you this couldn't have been anything but a perfect audit and if there was something, there was a 100% chance it would have been caught.

        Naive, or NSA op

        • So to you this couldn't have been anything but a perfect audit and if there was something, there was a 100% chance it would have been caught.

          Naive, or NSA op

          Reading comprehension fail. Please re-read this sentence from the GP:

          I'm not suggesting there's no chance they've missed anything, but I am saying the process is considerably more thorough and less likely to make a mistake.

          Absolute certainty is impossible, but audits like this do provide a basis for a reasonable belief that the security of TrueCrypt is good.

      • At the next Black Hat competition, they should really mix it up and have teams trying to embed spy-ware and decryption in lengthy and complex encryption code. Some code would be tainted, other code would be not, and some would just be shoddy so as to obscure the obscure.

        It would be interesting to see how easy or hard it is to really catch nefarious code.

        Because, unless you or someone working with you can understand EVERY line of code in a program -- and its dependancies, you can't really be sure.

        The other t

    • by Anonymous Coward

      You are never going to "know". Ever. So you have to decide for yourself what is "good enough".

    • by Zappy ( 7013 )

      you don't

    • I suppose then you look at the compiler and the chips on the computer itself.

      There are a number of cases where the Government has forced component manufacturers to embed designs on their silicone. Laser printers for instance; for "some reason" all PostScript rasterizing chips at one time could be turned into passive antennas to indicate their location -- and in the Desert Storm war, this allowed the US to find locations that MIGHT be military command centers (assuming a computer next to a printer). Maybe th

  • by frank_adrian314159 ( 469671 ) on Friday April 03, 2015 @08:47AM (#49397287) Homepage

    If this [bell-labs.com] hadn't been done ten years before he talked about, it's been done by now. They have everything they want. Live accordingly.

    • If this [bell-labs.com] hadn't been done ten years before he talked about, it's been done by now. They have everything they want. Live accordingly.

      Fortunately, we know how to counter [dwheeler.com] that threat.

      It also seems pretty unlikely that the NSA had enough foresight to get VC++ instrumented to subvert TrueCrypt. It's not impossible, but there have been a lot of similar tools over the years, and I don't think the compilers could have been modified to subvert all of them.

      • Fortunately, we know how to counter [dwheeler.com] that threat.

        Only Microsoft has the ability to counter that threat because only Microsoft owns a lawfully made copy of the source code to Visual C++. Microsoft also has an interest to promote BitLocker over TrueCrypt.

        • Another option is to build TrueCrypt with a different compiler. There is ongoing work to do that.
    • That trick only works if you've got only one compiler. You can detect it and nullify it if you have two independent compilers for the same language. Neither of the two have to be fully trusted, but you do have to assume they're not in cahoots with each other.

  • obvious logic (Score:3, Insightful)

    by slashmydots ( 2189826 ) on Friday April 03, 2015 @08:49AM (#49397301)
    Everyone kept saying they would find a backdoor. Don't you think that logically the NSA shut down the project because they couldn't find a backdoor in it? They would have left it alone if it had an NSA backdoor in it.
  • Last year when TrueCrypt developers suddenly threw in the towel [wikipedia.org], everyone assumed it was because TrueCrypt had been forced been subverted by the NSA, similar to Lavabit. If that's not the case though, as the audit suggests, then why did the developers suddenly quit?

    • by Anonymous Coward

      It's a reasonable assumption that the TrueCrypt developers were pressured to subvert the project, but shut it down instead. As you said, similar to Lavabit; recall that Ladar didn't give the Feds what they wanted, he shut down the service rather than compromise his users. I think the same thing happened with Truecrypt.

      The audit suggests that no NSA backdoor actually made it into the product. It's still very likely that the gov't tried to force a backdoor, and the developers' response was to abandon ship.

  • Don't forget that about 20 years ago NSA was introducing flaws by exploiting bugs in the compilers.

    I doubt a code-review would find any of these.

"Consider a spherical bear, in simple harmonic motion..." -- Professor in the UCB physics department

Working...