The binaries are properly GPG-signed with the same key as the previous binaries, check for yourself. [They] either compromised their private key too or the actual developer(s) did this. Be it voluntarily or by force of secret three-character agencies / a massive pay check.
Maybe something like the Lavabit scenario where they rather close the shop than sell their users out. On the other hand, proposing Bitlocker as an alternative would be rather suspect in that case.
IF THIS IS THE CASE and that's an IF then it seriously brings into suspect backdoors in larger proprietary software. Because really if they're going after trucrypt then they have to already have gone after the big players.
I'm not going to jump the gun just yet but after snowden it's not out of the question.
Well, the thing is though, it's not that they were hosting users' data. It's not like they would be forced to provide the contents of users' communication.
I suppose they could be approached by someone to plant backdoor into the software, but I wonder if that can be done without someone noticing it...
Yes, I can confirm that F0D6B1E0 was on the Truecrypt web site about a year or two ago, since it's been on my keyring for at least that long. I've installed Truecrypt multiple times over the past few years, and have always used this key to verify (or its signing subkey, I suppose).
Don't just trust my SHA1s, verify with the sigs and the TrueCrypt Foundation public key. Ensure the key has the fingerprint shown in the great-great-great grandparent of this comment, independently verified by others in this thread.
gpg: Signature made Tue 07 Feb 2012 12:45:26 PM PST 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
If this is a hack, then the truecrypt.org site (or dns) and sourceforge site are both compromised, suggesting a dev got hacked who would have had access to both, and perhaps the TC signing key as well (not everyone practices good signing key hygiene, like keeping it offline, even for important software projects).
Even if it's a legit announcement, I wouldn't run that 7.2 binary. Anyone running truecrypt already has truecrypt, right? I don't know why they'd release a new version at the same time as such a dire and panic-inducing announcement.
SourceForge recently forced their users to change their passwords [1] because of an attack on their infrastructure [2]. Pure speculation but I'm not sure if that had anything to do with this?
Those two SourceForge blog posts are from January 2011, a year before the release of TrueCrypt 7.1a. The recent forced change was due to infrastructure changes.
Anyone running truecrypt already has truecrypt, right?
I frequently reformat my boot volumes—but I've had a .tc file laying around on an external HD since forever, with my websites' X.509 private keys and such inside.
I'm probably going to do exactly as this announcement says: download the export-only binary, create a loop-mounted LUKS volume, and migrate everything over.
Just quickly scroll through the diff (better version here: https://gist.github.com/anonymous/e5791d5703325b9cf6d1) and you will immediately see that all that was done is disable/remove a majority of the functionality.
AbortProcess ("INSECURE_APP");
Print ("WARNING: Using TrueCrypt is not secure");
They added exceptions/rose errors/printed warnings everywhere where you could possibly encrypt and all of it reflects their intent at the Sourceforge page.
The whole point of the underhanded c contest is that the code looks extremely benign, and you wouldn't know that it's doing something evil by staring at it for a short time. Example: http://underhanded.xcott.com/?page_id=22
Anyway, it was a joke.
edit: But I'm not touching that binary with a 10 foot pole, thank you. There isn't even any guarantee yet that that source compiles into the given binary.
A much simpler explanation is someone defaced the site around the same time a new release was coming out. Is there anything in the signed release package to corroborate what the site says?
Yes. See the sibling poster's image link. I also installed 7.2 in a VM and received the same warning. It also looks like I can't encrypt anything, just decrypt.
Comments
Well - this comes as a pretty big surprise.
Is this real? Is there a known vulnerability that catalyzed this? Money from Microsoft? Threats?
I'm not buying into conspiracy theories, but it does seem pretty out of place.
The binaries are properly GPG-signed with the same key as the previous binaries, check for yourself. [They] either compromised their private key too or the actual developer(s) did this. Be it voluntarily or by force of secret three-character agencies / a massive pay check.
Maybe something like the Lavabit scenario where they rather close the shop than sell their users out. On the other hand, proposing Bitlocker as an alternative would be rather suspect in that case.
IF THIS IS THE CASE and that's an IF then it seriously brings into suspect backdoors in larger proprietary software. Because really if they're going after trucrypt then they have to already have gone after the big players.
I'm not going to jump the gun just yet but after snowden it's not out of the question.
Not "backdoors" but it seems Microsoft stores the BitLocker decryption key, based on this leaked slide (just found on twitter): https://twitter.com/TheBlogPirate/status/471759810644283392/...
edit: Confirmed Microsoft stores your recovery key on their servers if you're not connected to a domain: http://windows.microsoft.com/en-AU/windows-8/bitlocker-recov...
Microsoft storing your key is opt-in and optional.
Whether or not they superstitiously store it anyway is a different question.
Well, the thing is though, it's not that they were hosting users' data. It's not like they would be forced to provide the contents of users' communication.
I suppose they could be approached by someone to plant backdoor into the software, but I wonder if that can be done without someone noticing it...
If they put a backdor on the binaries, but not source, lots of people will be compromissed, and for a really long time nobody may notice.
EDIT: I normaly don't care. But this time I'd be glad if who downmoded this post explained why.
Yeah it could be a gag order from a secret court. maybe they folded because they were forced to compromise the code...
considering heartbleed... yes
Same key as the previous binaries? I doubt it, given that the keys were replaced mere 3 hours before the new binaries were published:
http://sourceforge.net/p/truecrypt/activity/?page=0&limit=10...
Anyone have key fingerprints for pub keys used for the 7.1a vs 7.2 signing? Preferably pub key from a while ago I guess.
This looks like the previous key: https://github.com/DrWhax/truecrypt-archive/blob/master/True...
Besides the different file name, the contents of the files match: http://www.diffchecker.com/szpb500v
Yes, I can confirm that F0D6B1E0 was on the Truecrypt web site about a year or two ago, since it's been on my keyring for at least that long. I've installed Truecrypt multiple times over the past few years, and have always used this key to verify (or its signing subkey, I suppose).
There's a "TrueCrypt Foundation" key on the keyservers from 2004, the ID is E3BA73CAF0D6B1E0.
The time stamp on key servers can not be trusted. Anyone can spoof keys in anyone elses name, with any timestamp they want.
The only way to verify is if you have the previous key stored somewhere, or can find a trustpath to it.
I have the key stored in my local keychain:
E3BA73CAF0D6B1E0 C5F4 BAC4 A7B2 2DB8 B8F8 5538 E3BA 73CA F0D6 B1E0
Checks out.
I have 7.1a binaries, source, sigs and pub key from September 2013.
My version from September is identical to the pub key at http://sourceforge.net/projects/truecrypt/files/TrueCrypt/Ot... .Could you post the SHA1s of those? I'm failing to use GPG properly.
Can you please make these available for download, the Linux ones at least?
All of the files available here: http://truecrypt.ch/ have the same hashes as provided by this person.
Don't just trust my SHA1s, verify with the sigs and the TrueCrypt Foundation public key. Ensure the key has the fingerprint shown in the great-great-great grandparent of this comment, independently verified by others in this thread.
You should see:Thanks!
If this is a hack, then the truecrypt.org site (or dns) and sourceforge site are both compromised, suggesting a dev got hacked who would have had access to both, and perhaps the TC signing key as well (not everyone practices good signing key hygiene, like keeping it offline, even for important software projects).
Even if it's a legit announcement, I wouldn't run that 7.2 binary. Anyone running truecrypt already has truecrypt, right? I don't know why they'd release a new version at the same time as such a dire and panic-inducing announcement.
SourceForge recently forced their users to change their passwords [1] because of an attack on their infrastructure [2]. Pure speculation but I'm not sure if that had anything to do with this?
[1] http://sourceforge.net/blog/sourceforge-net-global-password-...
[2] http://sourceforge.net/blog/sourceforge-net-attack/
Those two SourceForge blog posts are from January 2011, a year before the release of TrueCrypt 7.1a. The recent forced change was due to infrastructure changes.
https://sourceforge.net/blog/forced-password-change/
I frequently reformat my boot volumes—but I've had a .tc file laying around on an external HD since forever, with my websites' X.509 private keys and such inside.
I'm probably going to do exactly as this announcement says: download the export-only binary, create a loop-mounted LUKS volume, and migrate everything over.
Recent versions of cryptsetup support decrypting truecrypt volumes, just use cryptsetup for both.
Here's the source code diff https://www.alchemistowl.org/arrigo/truecrypt-7.1a-7.2.diff....
Time to call in the underhanded C contest (http://underhanded.xcott.com/) participants on a special bugfinding challenge :)
Not needed.
Just quickly scroll through the diff (better version here: https://gist.github.com/anonymous/e5791d5703325b9cf6d1) and you will immediately see that all that was done is disable/remove a majority of the functionality.
They added exceptions/rose errors/printed warnings everywhere where you could possibly encrypt and all of it reflects their intent at the Sourceforge page.The whole point of the underhanded c contest is that the code looks extremely benign, and you wouldn't know that it's doing something evil by staring at it for a short time. Example: http://underhanded.xcott.com/?page_id=22
Anyway, it was a joke.
edit: But I'm not touching that binary with a 10 foot pole, thank you. There isn't even any guarantee yet that that source compiles into the given binary.
A much simpler explanation is someone defaced the site around the same time a new release was coming out. Is there anything in the signed release package to corroborate what the site says?
Yes. See the sibling poster's image link. I also installed 7.2 in a VM and received the same warning. It also looks like I can't encrypt anything, just decrypt.
If their site/dns/whatever was compromised than there's no way you can trust the GPG signature at this point. I'll await a proper press release.
Matthew Green (@matthew_d_green) was involved in the audit. Follow him for what's what.
https://twitter.com/matthew_d_green/status/47175105467398963...