1. 22

  2. 16

    Another discussion from the /r/sysadmin sub:


    And one over at the security StackExchange:


    There’s quite a bit of confusion still. It certainly smells like a website defacement at first, with a possibly compromised account/key.

    But according to a supposed SourceForge representative (HN user “rgaloppini”) in the HN thread about this (https://news.ycombinator.com/item?id=7813121), there’s no indication of a compromised account. Granted, this HN user is a whopping TWO hours old. Certainly smells like bullshit at first sniff. And I can’t tell if this new user is claiming to be an actual representative from SF, or if s/he’s merely relaying info from SF that they have somehow gotten a hold of. In either case, I’m unaware of anything official coming from SF and am inclined to disregard this comment in the HN thread.

    Sidenote: the “tc-foundation” SF account is over four years old:


    Doesn’t look like a spoof account that was recently created, at least.

    Adding to the confusion, nothing has jumped out yet as being an obvious attempt at malware. It’s certainly an interesting case.

    I’m most interested in the supposed “change” of signing keys for these new 7.2 binaries. In particular, the following link has three different uploads of keys:


    The oldest one, at 9 hours old, is no longer available. The other two, one uploaded 8 hours ago and later overwritten by another 5 hours ago, are:


    It doesn’t look like it’s possible to see the one uploaded 8 hours ago either. Regardless, I’ve uploaded the latest “new” key to my own domain in case anything dies in the coming hours:


    In particular, here are some various digests of the “new” key:

    $ md5sum new-tc-key.asc

    41612478ceeee8448b87a5e872f07302 new-tc-key.asc

    $ sha1sum new-tc-key.asc

    c871f833d6c115f4b4861eed859ff512e994b9fc new-tc-key.asc

    They seem to match the original key as documented here when someone was trying to get the self-compiled binaries to match the distributed binaries:


    Filename: TrueCrypt-Foundation-Public-Key.asc

    MD5: 41612478ceeee8448b87a5e872f07302

    SHA1: c871f833d6c115f4b4861eed859ff512e994b9fc

    Frustratingly, I don’t have access to the keys that were on the truecrypt.org website prior to the recent changes. But, assuming the data from the concordia.ca link is valid… the provided keys match. Do the binaries and their signatures correspond to this key?

    $ gpg2 –import new-tc-key.asc

    $ gpg2 –verify TrueCrypt-7.2.exe.sig TrueCrypt-7.2.exe

    gpg: Signature made Tue 27 May 2014 11:58:45 AM CDT using DSA key ID F0D6B1E0

    gpg: Good signature from “TrueCrypt Foundation contact@truecrypt.org

    gpg: WARNING: This key is not certified with a trusted signature!

    gpg: There is no indication that the signature belongs to the owner.

    Primary key fingerprint: C5F4 BAC4 A7B2 2DB8 B8F8 5538 E3BA 73CA F0D6 B1E0

    So… the binaries and their signatures correspond to this “new” key which appears to be the same as the “old” key. The key’s fingerprint also matches Google’s cached version of the truecrypt.org download page (third result):


    So… the key is good? The binaries are signed against it? The fingerprint (appears) to match? And yet… the announcement page isn’t signed by the devs… And it just smells so fishy…

    It’s all very confusing. I’m not a crypto expert, but it certainly looks like the “new” key is indeed the same as the old key, and the binary signatures correspond to it. Makes me think the TC developers have just thrown in the towel, or their key has been compromised –along with the truecrypt.org domain and the sourceforge account. Seeing as their identities are a complete mystery, I don’t exactly know how they could ever recover from a total compromise of keys, domains, and accounts. There’d be no way to assuage concerns that they are the “real” TC devs and not the imposters because every source of trust has been compromised. I’m not saying such an all-compromising attack of every account/key is impossible, but damn: it’d be a pretty impressive amount of work to compromise all of that.

    I look forward to reading an expert’s take on the matter in the coming hours. In fact, I think this whole situation would be an excellent basis for a more real-world-based training exercise involving various cryptographic tools and how to properly use them to navigate a foggy situation like this one.

    edit: Made slight edit for filename consistency when I crunched the digest of the files (I had renamed them on my machine at one point; editing so it’s all consistent)

    1. 6

      If you look through Matthew Green’s timeline, he brings up the possibility that the TrueCrypto maintainers don’t want to develop the software anymore.

      1. 3

        I’m leaning toward this as the more likely scenario than an NSL canary. My understanding is that the 7.1a release hasn’t been touched in over a year. The only active work on the codebase that I know of has been to audit it. As well, the license for the 7.2 release was changed to remove the advertising clause. I’m not a lawyer, but I believe this was the only major hang-up in getting truecrypt to actually be considered “open source” by FSF and OSI (IIRC, there was also some concern about trademark usage). But then again, they went and gutted the actual source code for this particular point release, leaving me to wonder whether the license change only applies to 7.2 code or retroactively to any commit or point release that has the meat of the encryption code.

        However… I suppose it’s just a sign of the times that the NSL canary possibility is more than “remote” and somewhere between “unlikely” and “well, maybe.” That… and the stated reasoning –Windows XP being EOL, ergo no more TrueCrypt– is just fantastically flimsy; surely the devs would just say “we’ve moved on.” Indeed, they’ve changed the license. Why not just come out and say that they’re leaving the project and feel free to do as you wish with the new open source licensing terms? Why the BitLocker suggestion? Why wipe the repositories? Why the big red letters and warning dialogs saying the program is insecure? Why go through all of the extra effort of gutting the codebase to generate a point release that only decrypts?

        In short: this isn’t typically how orphaned or abandoned projects behave.

        1. 3

          “Truecrypt does not adhere to those kind of norms.” (source)

      2. 4

        Hey, thanks for this! I’ve seen a bunch of assertions about the validity of the keys, but nowhere else such a detailed examination of it.

        I think the most likely possibility at this point is that it’s effectively an NSL canary; the devs were coerced and gagged and rather than go mutely along with it implied compromise and shuffled people away.

        Time will tell, I suppose.

        1. 2

          I agree. I fear it could be similar to the Lavabit case.

      3. 4

        This is extremely suspicious, at the very least.

        Other discussions on Reddit and Hacker News.

        1. 1

          Anyone have any good alternatives to TrueCrypt, ones that are multi-platform?