TrueCrypt suggesting migration to BitLocker?
truecrypt.sourceforge.net
truecrypt.sourceforge.net
* Defaced site, timed to screw up a big announcement
* Rogue content maintainer
* Phase II of audit turned up something rather bad
(edit: NO - see tptacek below)
edit: Variations on "developer forced to do this" (cf simmerian's comment): * Developer was big brother all along and they are shutting it down
* Security vuln about to be disclosed, dev scrambles to inform (albeit poorly)
* Legally or otherwise compelled to compromise source code,
dev complies and/or nukes project from orbit
The last alternative would be suggested in part by the strange content of the page, assuming it is legit from the developer: Normally I'd expect at least something like "there's a major vuln that is unfixable and we'll disclose formally in a week/two, migrate now.".It doesn't appear related to the audit
Edit: with a new, compromised key.
I'm chalking this up to, after all that work, having come so far, kind of wanting to say you did it, and providing a few (IMO) hand-wavy arguments why those last impossible chunks of bits probably don't matter, instead of having to admit defeat after being able to account for 99.9% of all bytes.
I can understand that, I've been wanting to type "but it's probably not backdoored" three times already typing this post, and catching myself because really I have nothing to go on to make or back that statement.
edit: Apparently not, according to the link @Alupis posted.
http://sourceforge.net/projects/truecrypt/files/TrueCrypt/
http://sourceforge.net/projects/truecrypt/?source=navbar
http://sourceforge.net/p/truecrypt/activity/?page=0&limit=10...
Odd, 6 hours ago someone updated the TruCrypt-key.asc files, then 3 hours later posted all the new binaries.
Also odd is whoever posted the new binaries completely yanked all the previous ones, leaving only the new and questionable binary available for download.
hmm...
And the new key can be found on the SF site.
I concur -- likely an elaborate website deface.
I don't think any legit organization would do that, but what if it's maintained by a small team or even individual -- I don't think I've ever seen a single face of TrueCrypt developers out there...
If true, I'd much rather have them post a countdown clock and say "If we don't reach X funding goal in donations by date Y, then we will be forced to close the project". Funds would come in then... a lot of people depend on truecrypt.
> WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues
That is a perfectly reasonable thing to say if you are abandoning security software. Any issues discovered will not be fixed, so you should stop relying on this software for security.
1) Obviously I was joking in my comment above.
2) That post is dated well before common knowledge of how "in-bed" Microsoft is with the USA spy agencies (at least management is).
This is a topic for another discussion, but I just want to point out that, of course someone being coerced under gag order to install less-than above-water "features" and/or purposefully weaken the product would say exactly what is in the blog post.
In fact, BitLocker would be the first thing I'd weaken. Because
1) It's closed source, hard to externally audit.
2) It's one of the most used encryption packages in the world.
3) Microsoft's poor security track record provides excellent cover if the weakness is ever found.
Closed-source security software is a recipe for disaster.
> Well, maybe not literally---I’m not ready to be a martyr quite yet
So, in short he's written 8 years ago that in principle he was totally against backdoors. Times have changed so much that a statement of that tone is almost entirely useless IMHO.
https://gist.github.com/anonymous/e5791d5703325b9cf6d1
The entire source has been modified to reflect the Sourceforge page its contents. Encryption process is disabled. The current binaries can only be used to "migrate". You can deface a webpage but the effort it takes to rewrite the entire source code, compromise the GPG, compromise domain, compromise mail servers et cetera is not minimal.
It is happening. Whether they are being forced to do so is a whole different story.
I dunno. We saw the legend version happening with a lot of people recently. Yep, we still mostly don't belive it, but...
What's the oposite to The Boy that Cried Wolf?
* Possible, but once again I see no motive that would produce this brand of outburst.
* And it's unfixable? That would be a world first.
I think it's much more plausible this is some powerful entity forcing a hand. We know by now there's plenty of motive and candidates to fit that shoe.
Because while specific orders can't be disclosed if they'd give away information to the actual target, the general nature of such orders is well known - information can be demanded if held. You can't be compelled to engage in subterfuge though, and since such an order would be illegal, you could freely disclose it and let the civilian courts strike it down.
As one might note from the Lavabit fiasco, things only got weird because Lavabit decided to screw around being non-compliant, while also always having the technical capacity to decrypt everyone's email (and thus opening up the legal doorway to just seize the keys and all the data, rather then the tiny chunk that was wanted).
While this might be reading a tad much into it, the language of the announcement, specifically the "...as it may contain unfixed security issues" bit, sounds like what somebody who just came out on the losing end of a heated debate about whether some bug-feature should or should not be considered the former would say. Knowing the vitriol and determination with which software developer arguments are often carried out, this would explain the observed combination of remarkable dedication and haphazard execution.
I realize we are firmly in conspiracy theory territory here, but perhaps the suggestion that users switch to Bitlocker is intended to be so patently absurd as to be a signal that the developers are under duress?
My very first thought upon hearing this news was that just maybe the trucrypt devs are secretly cheering for others to come and replace the hole they fill in this world. Maybe this is the best possible thing they could do to inspire the next generation of truecrypt. They've laid a good foundation but they know they can't win the war for free information security on their own. So what better good could they do than to inspire the mother of invention; necessity.
The Bitlocker thing seems strange until you realize that it probably really IS the best alternative for most users. The users who are paranoid enough to not trust Bitlocker can probably look out for their own security, so it makes sense to give instructions for the rest.
None of the explanations people have came up with regarding intelligence agencies and conspiracies really hold water. If the devs were compromised, I doubt they would be given the freedom to post something like they did today. If they were under some kind of NSL or gag order, this would almost certainly violate it.
It seems odd to me that security specialists would recommend a flawed tool to 'the masses'. It just doesn't fit with what I usually read from people in this line of work.
[1] - Whether it's flawed or not depends on your needs. Not everyone cares about defending their data against an attacker with the resources of a nation-state - many just want their laptop's hard drives to be effectively inaccessible if the device is stolen or lost.
If this is true, then perhaps such listlessness was also catalysed by the ongoing audit. Maybe seeing such a mass of crowdfunding income towards a project to pick Truecrypt apart, in contrast to the scant donations to its development, disheartened the authors towards further work?
Abandoning it in this rather dramatic way ensures that Truecrypt's users are warned against using unsupported software where any bugs will remain unfixed. This is especially important when such bugs revealed in the future (and maybe ones already known) have the possibility of being deleterious for security.
Perhaps ownership does run deep, even if you've never really released a product for money and it's always been free. Still, it's something I don't understand: If I had a tool that I released for free and finally gave up on it, I'd like to think I'd open it up under an exceptionally liberal license or just dump it in the public domain. That'd be especially true if it had a lot of users.
That's what makes me think that if this isn't some elaborate scheme it's likely the result of some sort of legal requirement or action (e.g. Lavabit) which would preclude the author(s) from doing anything else with the software. It's a shame they couldn't take a scorched earth-esque approach of dumping everything in the public domain, including notes on why this was happening, everyone else be damned, but I'd imagine their entire career might be in jeopardy at that point (and possibly their freedom).
Given that border searches of electronic hardware are becoming more commonplace in the US, I should think that something like this is important. I know when I was driving back and forth to university, the thought crossed my mind when I had my laptop with me as I went through the border patrol checkpoint that there wasn't anything much I could do (outside lawyering up) if they took it upon themselves to grab it and search. Sure, the worst they could have done was read my email (and maybe clear out the junk folder for me while they're at it), but it was the principle of feeling so violated by the act itself that drove me to stuff all my school work into a TrueCrypt volume.
(This was years ago, and TC was the best option for XP. Though I later switched the laptop over to Linux.)
However it's unclear if this change is only for Truecrypt 7.2 or can be applied retrospectively to previous versions. As the authors have deleted sizeable portions of the encryption code in this final version, such ambiguity could be problematic.
no one is going to come after anyone for licensing fees
Edit: The following clause was deleted in the 7.2 release.
- c. Phrase "Based on TrueCrypt, freely available at - http://www.truecrypt.org/" must be displayed by Your Product - (if technically feasible) and contained in its - documentation. Alternatively, if This Product or its portion - You included in Your Product constitutes only a minor - portion of Your Product, phrase "Portions of this product - are based in part on TrueCrypt, freely available at - http://www.truecrypt.org/" may be displayed instead. In each - of the cases mentioned above in this paragraph, - "http://www.truecrypt.org/" must be a hyperlink (if - technically feasible) pointing to http://www.truecrypt.org/ - and You may freely choose the location within the user - interface (if there is any) of Your Product (e.g., an - "About" window, etc.) and the way in which Your Product will - display the respective phrase.
As was its ability to encrypt, apparently. I don't exactly count those as one in the same.
https://code.google.com/p/cryptsetup/wiki/Cryptsetup160
So at least Linux users should be covered.
It was developed in almost total secrecy, with binaries and code being tossed over the wall once in a while, provided under a non-OSI license.
I built it from source a few times, but Truecrypt was used by a lot of people, far beyond the developer community, people who totally lacked the technical skill needed to compile it. SO it's a safe bet the majority just used those binaries. And those binaries actually changed without warning more than once, independent of the version changing. That alone bred suspicion and fueled the demand for an audit.
The behavior of the developers (and their total lack of a public presence, regardless of the reason) may have also discouraged donations. Same with the behavior of the forum moderators, whoever they were.
While this move seems odd, the new binaries are properly signed and the domains have been updated accordingly. If this was another project, like Rails, the maintainer could come out and say they were hacked and the last good version was X. Otherwise, the project would likely die off.
But since we know so little about the TrueCrypt maintainers, there's little way for us to hear that this isn't legitimate. In order to keep the project from dying (if this is a hoax), they would have to prove that they are the maintainers, because any plausible deniability would undermine their claim that the change was not legitimate.
If two groups with opposing messages control the key, it's pretty clear that the key is compromised in some manner.
* PGP matches
* Authenticode matches
* SourceForge data was modified
* DNS records were modified
And to top it off, let's put ourselves in the theoretical attacker's shoes, the binaries when run make no unexpected connection attempts or write to any unexpected places and don't appear to contain any unexpected imports, so if this was a hack, it's a very stealthy and very boring one. The most they achieved would be uninteresting to most attackers. It would only really be an effective attack against people who had TrueCrypt volumes but not a current copy of TrueCrypt as there's no compelling reason for anyone to upgrade to 7.2 and certainly they'd be skeptical after this. Any attacker with the intelligence and patience for such an attack would surely realize how poor an execution this would be. A better attack would be "here, it's TrueCrypt 8, it has loads of EFI support and mad security, everyone should install it, it's the best!". There's simply no reason to shut it down like this, unless the attack is just an elaborate practical joke.It's quite possible this came from 1 big developer hack, but considering how the release was done, with full source and everything for every supported platform... if it was a hack, it's a very, very good one. They've also decided to modify the license terms, perhaps bringing it into compatibility with more common FOSS licenses.
I think it's far more likely at this point that the devs, who had not updated their software in years, finally decided to call the project over and have marked it insecure because the codebase is now unmaintained and should be assumed insecure.
Though I suppose that's not the best legal rationale, now is it?
So they decided to end things with such an extremely juvenile behavior devaluating the years they have invested in this project even if not recently?
Unless the responsible one fell into clinical depression it's a pretty strange reason.
I'd hardly call the behavior "juvenile" nor would i call it "devaluating". They've simply abandoned it and are offering alternatives.
(Devaluating? sic? Or is that actually a word?)
As I said even if not recently they still invested many years into that project.
Of course it is juvenile to senselessly ruin the code and suddenly advertising a very different commercial product, especially without proper scientific reason.
Not to mention that precisely because they haven't done much work lately I don't see any reason why the developers would disfigure their project like that.
They're not "advertising a very different commercial product". They're recommending you actually use a maintained alternative. Bitlocker is probably the most viable alternative on Windows.
It's also possible that Bitlocker solved the problem well enough for them so they saw no gain in maintain TC any further.
How would a software with closed source from a company that has been gladly working with the US government in the past be a "viable alternative" to TrueCrypt? Really, please try to read the comments above before you enter the discussion.
BitLocker lacks another one of TrueCrypt's most important features: open-source code, readable, verifiable, and compilable by any interested user. BitLocker is almost definitely already backdoored, so encouraging people to switch to that makes all of that data accessible by the powers that be.
I think it's silly to pretend like no authorities would have an interest in promoting the use of closed-source encryption techs. Apple and Microsoft were both willful participants in the PRISM program. TrueCrypt was the only open-source FDE software that had widespread adoption on non-Linux systems. After this, no major corporation or group is going to use TrueCrypt to encrypt anything anymore and will rely entirely on the backdoored encryption solutions provided by the NSA's known and confirmed compatriots.
If it's the actual TC crew, the explanations toward an NSL or a new vuln that an NSL or similar applies to seem to be about the only rationale - though even then, it seems to me it'd be possible to steer the code audit in the right direction.
Given the churn of new keys today, I'm more inclined to think that the comms of TC have been broken and the breach is being used to drive people away from the releases of the tool for which source is available.
It would be so easy for the person(s) in question to just say that, though.
I don't know what to think.
This does not explicitly suggest vulnerabilities exist in older versions, but rather the latest version with these changes is very explicitly insecure and should not be used. This does leave room for issues to have been discovered in old versions - maybe rather than fix, they are throwing in the towel.
1. We have had no contact with the TrueCrypt project team (and thus no complaints).
2. We see no indicator of account compromise; current usage is consistent with past usage.
3. Our recent SourceForge forced password change was triggered by infrastructure improvements not a compromise. FMI see http://sourceforge.net/blog/forced-password-change/
Thank you,
The SourceForge Team communityteam@sourceforge.net
I'm calling BS. This site was disabled repeatedly for exceeding bandwidth today. I find it hard to believe traffic is as usual.
- The version there works and does not seem to have a trojan, so probably not a regular hacker. ( https://news.ycombinator.com/item?id=7813373 )
- Instructs to migrate to dubious alternatives, so it's not a legit security effort.
- License change, precise instructions and decrypt-only version indicate it's not a completely rushed press release. (license change: https://github.com/warewolf/truecrypt/compare/master...7.2#d... )
- On the other hand the Linux instruction is a joke, so it's not completely well thought either. ( http://truecrypt.sourceforge.net/OtherPlatforms.html )
- The security audit was so far ok, so it's not a sudden vulnerability discovered there. ( https://twitter.com/matthew_d_green/status/47174183672207360... )
- No details whatsoever other than a "may contain unfixed security issues", so it might be an automated release (doesn't know what happened) or gagged reaction (can't say what happened).
- Source code includes unrelated changes, so it probably comes from a developer. ( https://news.ycombinator.com/item?id=7812674 )
If I had to wager a crazy bet, I would go with newly developed Dead-Man's-Switch gone wrong.
Edit: someone on Reddit has an interesting view that it may be a halfhearted attempt at complying with an NSA request ( http://www.reddit.com/r/sysadmin/comments/26pxol/truecrypt_i... ).
That's an interesting thought, although I don't think there's any way to verify that it's actually gone 'wrong', is there?
And if this is a Dead-Man's-Switch gone right, why are they advocating the use of BitLocker and searching for random Linux packages?
Edit: is "coming out in public" the correct term here? I have a feeling it only applies to closet-like scenarios.
The reason why is quite simple: if a malicious third party were to raid or steal the private key, this kind of deterrent message should act as ample warning not to trust any further releases than what has already been released. If a government agent were to capture a developer and hold him or her hostage to attain the key (and thus release a backdoor), this type of DMS would immediately draw scrutiny to any actor attempting to release a new version that claims differently. If anything, the implicit statement is "continue using 7.1a and do not update beyond that in the event that something newer is offered." In light of the recent audit, it appears that 7.1a is secure -- and as a result, it can still be used for cryptography purposes (however subsequent releases may not).
Let's assume that this is a faulty DMS that was slapped together due to imminent threat by state actors. If these state actors were sufficiently powerful, couldn't they instead press ahead anyway with obtaining the developer's private keys, account data, etc., while publicly parading either the real developer (or an actor) in front of the spotlight briefly enough to claim that this was all a mistake? Next, release another series of new versions (with backdoors) that are fully controlled by the state actor under the guise that they're perfectly okay.
Of course, this would itself be easily defeated by either examining the history of the individual who claims to be the developer (if applicable) and through some scrutiny of the new binaries, although I'd imagine the latter would be anticipated by the actors behind the charade.
The closest thing in my mind that this resembles is a warrant canary as someone else pointed out earlier today. I suppose that in effect the DMS and canary achieve roughly the same goal so perhaps I'm just splitting hairs at this point. I also don't see either of these scenarios working perfectly except to warn people who are themselves already somewhat paranoid.
The important point is that the developers (?) are advocating that users stop using their product.
Forest through the trees, if you will.
One possibility is that they did it this way specifically because it's legally compliant with some order they got, but suspicious enough to raise alarm in the tech community and telegraph that something has gone deeply, deeply wrong.
This could be a warrant canary.
Incorrect, all the guy did was compare diffs of the source. He did not compile the source to make sure the binaries matched.
And matching binaries is not a trivial task because of OS, compiler and SDK versions. The last time someone did this for Truecrypt it made the news: https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...
[...] you have to consider the fact that Truecrypt project
was started before FDE was popular, maybe their goal all
this time was to popularize such encryption. With XPs
demise that goal would have been achieved as every
current Windows version comes with Bitlocker.
Your comment is dead but makes a lot of sense, especially in light of the message on the website: The development of TrueCrypt was ended in 5/2014 after
Microsoft terminated support of Windows XP.
I don't agree Bitlocker is a sensible alternative, but this piece does fit the puzzle.It's only available in Ultimate and Enterprise Vista/Win7 and Pro/Enterprise versions of Win8. Lots of machines ship(ped) with only Win7 Home Premium or vanilla Win8.
At some point the reward metric for that shifts away from your interests. It's never going to be picked up by like, major companies for enterprise-y use since Bitlocker has that market sewn up and it's never been really practical to use with Linux (from what I recall of looking into FDE for my notebook a few times in the past).
> Signature is valid, so it's not a defacement.
Under normal circumstances, I would assume the same, but given the exceptional situation and chaos ensued, I think it's not entirely silly to think that this could be a case of http://xkcd.com/538/
That could explain the inconsistency of a hypothetical scenario where the key is compromised by a third-party but the owner doesn't come out. If they are under physical threat, I suspect a lot of the "normal" measures like revocation certificates would be hard/impossible to achieve.
And it is apparent the project was shut down by the original developer in a way that at best satisfies a gag order but doesn't actually hold up to scrutiny, so I see only two possible explanations for what happened:
1. An NSL with a gag order;
2. A nice lump sum of money in exchange for silence.
Or of course a combination of the two which is the most likely.
I don't blame the dev - he obviously spent years developing software which provided nothing in return.
I can only say one thing - if you want to hide stuff from the big brother, don't use BitLocker! ;-)
-TrueCrypt License Version 3.0
+TrueCrypt License Version 3.1
This lead me to think about the legal implications of changing a software license using stolen signing keys, when signing keys are all that you have to verify that the software is official (such is the case with TrueCrypt and its anonymous authors). If the license is changed, and the package is signed with the same signing keys, can I legally use the new license in derivative software?The new license removes the following restrictions regarding attribution:
- c. Phrase "Based on TrueCrypt, freely available at
- http://www.truecrypt.org/" must be displayed by Your Product
- (if technically feasible) and contained in its
- documentation. Alternatively, if This Product or its portion
- You included in Your Product constitutes only a minor
- portion of Your Product, phrase "Portions of this product
- are based in part on TrueCrypt, freely available at
- http://www.truecrypt.org/" may be displayed instead. In each
- of the cases mentioned above in this paragraph,
- "http://www.truecrypt.org/" must be a hyperlink (if
- technically feasible) pointing to http://www.truecrypt.org/
- and You may freely choose the location within the user
- interface (if there is any) of Your Product (e.g., an
- "About" window, etc.) and the way in which Your Product will
- display the respective phrase.The only authenticity test that I can think of is to actively distribute a fork of TrueCrypt using the new license and wait to get sued. If you get sued by the copyright holder (who would have to come out of anonymity to sue), then you can be sure that the new license was unauthorized. Not the safest way to test authenticity, but it should work.
I can see a couple of scenarios where this would be wise:
A) The developer passes away, leaving nobody else to maintain TrueCrypt. Zero-day 1234 is discovered which compromises TrueCrypt. The DMS activates, depreciating the software and advising users to migrate to another alternative (why BitLocker, I have no idea).
B) The developer(s) is(are) coerced into compromising TrueCrypt in some way. As a part of the coercion, the developer(s) is(are) unable to demonstrate proof of life to the DMS, so the system nukes itself.
The reason I make this distinction is because continuing from a cautious/paranoid perspective, the DMS might not say "WARNING! Dead Man's Switch Activated! If you are reading this, I may have been compromised, and am no longer available to maintain TrueCrypt." It's possible that the landing page simply references a relatively innocuous event in the cyber security world to plausibly discontinue the software. The best evidence I have for this is the fact that TrueCrypt didn't shut down precisely when XP support was dropped. (In fact, according to http://www.microsoft.com/en-us/windows/enterprise/end-of-sup... official support ended in April, not May like the landing page states.)
a) knows how to change the code to make such a version
b) is updated often to keep up with the main branch
c) was developed recently
From that, "a" is wildly unlikely because coding is hard. "b" indicates a lot of work to maintain the DMS tool, which goes against the bare bones HTML page we are seeing and poor Linux instructions.
It could be something newly developed because they knew they were in danger. Or it accidentally triggered during development, which would explain why is it updated and why the warning page is lacking.
This is very strange. I have another theory since I don't believe in coincidences. We don't know the real author of TrueCrypt. I think someone found his identity (cough NSA) and made him an offer like lavabit.com received. This time probably with security classification so he can't talk about that. HOWEVER, if we take a look on diff of his code, we can see two interesting things:
messages about TrueCrypt not being secure
and the second thing he changed everywhere U.S. text to United States
Do you think that somoene who is closing a project would pay attention to doing such thing? I don't think so. I think that he tried to point a real reason of closing his project by that. I won't be surprised when truecrypt fork appears in TOR network soon...http://www.reddit.com/r/netsec/comments/26pz9b/truecrypt_dev... says:
> I asked around and apparently Visual Studio switched from generating "U.S." to "United States" in VS2010. Hence it is probably just the author having upgraded their VS at some point recently.
This is supposedly the commit for the 7.2 release. Just looks like a bunch of code replaced with the app aborting as insecure.
I'm not sure how legit this is, the repository was just created a few minutes ago. Apparently there is a new binary release that goes along with this, though.
[I've created a fork here just in case the original goes down: https://github.com/timothyarmstrong/truecrypt/compare/master...]
Greetings,
To make sure we're following current best practices for security, we've
made some changes to how we're storing user passwords. As a result, the
next time you go to login to your SourceForge.net account, you will be
prompted to change your password. Once this is done, your password will be
stored more securely. We recommend that you do this at your earliest
convenience by visiting the SourceForge website and logging in.
And, as always, be vigilant about password security. Use a secure password,
never include your password in an email, and don't click on links for
unsolicited password resets.
If you have any concerns about this, please contact SourceForge support at
sfnet_ops@slashdotmedia.com
Best regards,
SourceForge Team
----------------------------------------------------------------------
SourceForge.net has made this mailing to you as a registered user of
the SourceForge.net site to convey important information regarding
your SourceForge.net account or your use of SourceForge.net services.
We make a small number of directed mailings to registered users each
year regarding their account or data, to help preserve the security of
their account or prevent loss of data or service access.
If you have concerns about this mailing please contact our Support
team per: http://sourceforge.net/supportNo mention of why it's supposed to be not secure - it's an open source project so it would be easy to point to a specific vulnerability. All of this shortly after passing audit. There are detailed steps towards switching to supposedly secure closed-source solutions by companies known to be working closely with the NSA.
Also, since when do open source projects suddenly decide they are not as good enough as a closed-source alternative and then stop the project? Are we in danger of seeing a similar message on the homepage of LibreOffice and OpenOffice, declaring that you should switch to Microsoft Office?
I can't even begin to imagine a valid scenario in which something like this would be put up by the developers, with no pressure other than some fatal security flaw about which they just really don't want to talk.
At the same time, the developer clearly doesn't want people to be encrypting new archives with it, so have removed that functionality.
Removing the software in total would have lead to many mirror sites springing up, most with unproved providence (and a great opportunity for exploits). This method allows an official version to still exist (unmaintained, but still compatible with the current archives), whilst severely restricting new usages (by strongly warning against it and requiring using the dubious mirrors to obtain the software).
That still doesn't seem to answer the point. The differences between 7.1* and the questionable 7.2 are exclusively limited to what was ripped out. In 5 years, 7.1 and 7.2 will likely work precisely the same in terms of decryption. If a glibc update or similar breaks 7.1, it'll likely break 7.2.
Perhaps I wasn't clear enough in my first comment, but fundamentally it seems like a silly argument to make to suggest that distributing a new release for some measure of future proofing readability is necessary. Outside "don't use this, it's broken," I can't really see "this will still work in 5 years' time" as a valid reason.
550 5.1.1 <contact@truecrypt.org>: Recipient address rejected: User unknown in local
If they got hacked, it's not just their sourceforge account.
Since a lot of domestic users will be using Home or Home Premium versions of Windows, and as one of those users who uses Truecrypt for full disk encryption, this does not leave us with as easy a migration path as this site now suggests.
[1] https://en.wikipedia.org/wiki/BitLocker_Drive_Encryption
So... just any of them, then? Sure, ok.
This might help.
By "Truecrypt-end" user: https://en.wikipedia.org/wiki/Special:Contributions/Truecryp...
> p.s. We hope to have some big announcements this week, so stay tuned.
[1] https://www.indiegogo.com/projects/the-truecrypt-audit#activ...
> .@FiloSottile @matthew_d_green no idea. It's doing a 301 perm to a static pg @ SF, now blocked. Possibly compromised. pic.twitter.com/g5tSFUuXzu
.@Costly no idea. The announcement was about a
new Open Crypto Audit Project initiative, not TC.
https://twitter.com/kennwhite/status/471741290552782849[kinda disappointed that, despite arriving so late to this thread, no-one seems to have said this.]
Align this with what the TC website says now: "development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP."
Could it be that the original developer is somehow unable to update the build process to work on newer OSes, or unwilling to do so? Maybe they don't trust any VC++ released after 1993, and that version is probably not going to work on Windows 7 or 8.
[1] http://www.infoworld.com/t/encryption/sloppy-secure-open-sou...
Microsoft has many faults, but backwards compatibility is not one of them.
I doubt this would be the reason. (Also, TrueCrypt runs on OSX and Linux too, so a build environment dependent on Windows-only seems odd).
There are several things MS has released that don't install on newer systems very well. There are some where the installer depends on an old version of Internet Explorer being installed and which fail miserably on newer versions.
So if you have a Windows-based build server, it's probably running Windows Server 2008 or later. Which is 64-bit only.
You can run it on a recent 32-bit version of Windows, but client editions only.
And in the next year or two I imagine Windows 9 or 10 going exclusively x64/ARM.
I will try to reinstall it today, and have VS 2008 running inside.
I see many readers here and on Twitter who interpret that as "TrueCrypt has security issues". That's not what it says. It says that it might be insecure. That does not make too much sense right now, but considering this webpage would be meant to stay up, unchanged, for years, that makes a lot more sense: security problems may be found, and will not have been fixed in the version on the page.
So, it's a deprecation warning, not a security issue warning.
Looks like they've taken out the ambiguity.
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.
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...
EDIT: I normaly don't care. But this time I'd be glad if who downmoded this post explained why.
I'm not going to jump the gun just yet but after snowden it's not out of the question.
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...
Whether or not they superstitiously store it anyway is a different question.
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.
[1] http://sourceforge.net/blog/sourceforge-net-global-password-...
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.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.
http://sourceforge.net/p/truecrypt/activity/?page=0&limit=10...
Besides the different file name, the contents of the files match: http://www.diffchecker.com/szpb500v
The only way to verify is if you have the previous key stored somewhere, or can find a trustpath to it.
E3BA73CAF0D6B1E0 C5F4 BAC4 A7B2 2DB8 B8F8 5538 E3BA 73CA F0D6 B1E0
Checks out.
pub 1024D/F0D6B1E0 2004-06-06
Key fingerprint = C5F4 BAC4 A7B2 2DB8 B8F8 5538 E3BA 73CA F0D6 B1E0
uid TrueCrypt Foundation <contact@truecrypt.org>
sub 4077g/6B136ECF 2004-06-06
My version from September is identical to the pub key at http://sourceforge.net/projects/truecrypt/files/TrueCrypt/Ot... . tc/linux$ sha1sum *
c2a8c78a23f97ffb17bf47448c9f2daa3c8f80cd truecrypt-7.1a-linux-console-x64.tar.gz
078cdd4a58f0342cb872d7456c0ba49e310fcad9 truecrypt-7.1a-linux-console-x64.tar.gz.sig
a53a7a609a25d9a1e33f720ce5c0265ddd4e8b25 truecrypt-7.1a-linux-console-x86.tar.gz
66060f9444d5df70b4fcdeb655dc60131fce5ad1 truecrypt-7.1a-linux-console-x86.tar.gz.sig
086cf24fad36c2c99a6ac32774833c74091acc4d truecrypt-7.1a-linux-x64.tar.gz
45f65bf755d9481d8afa0d17de6a034062b7a7bd truecrypt-7.1a-linux-x64.tar.gz.sig
0e77b220dbbc6f14101f3f913966f2c818b0f588 truecrypt-7.1a-linux-x86.tar.gz
9efcd79e963126d6d8ef242857b4fafb06eb8ff0 truecrypt-7.1a-linux-x86.tar.gz.sig
d43e0dbe05c04e316447d87413c4f74c68f5de24 TrueCrypt 7.1a Source.tar.gz
caeb2bb1d5605d1fc960e936a06e52611033788c TrueCrypt 7.1a Source.tar.gz.sig
c871f833d6c115f4b4861eed859ff512e994b9fc TrueCrypt-Foundation-Public-Key.asc
tc/windows$ sha1sum *
06961d83e39c7248df09c132cb6e9b9f528ce69a Configuration.xml
88b323b416290924621901a10da3f4f7482e3f77 License.txt
4c4891f5eafcf9b96be01e31031992d9e98d39c3 TrueCrypt.exe
34442e400e6cb2534f33a0b1599defe36eefef2a TrueCrypt Format.exe
7689d038c76bd1df695d295c026961e50e4a62ea TrueCrypt Setup 7.1a.exe
e1e3efaeac2fbcdbff0c2c62ac33233bd356edfa TrueCrypt Setup 7.1a.exe.sig
62fc4f76540740e63c7f0a33e3a1b66411f0a303 truecrypt.sys
17249d979b3bc52d0a33821cc7f810337ddea2b6 TrueCrypt User Guide.pdf
17c46ebc6f4977afbcf4aa11eccee524fd95b1c8 truecrypt-x64.sys gpg --import TrueCrypt-Foundation-Public-Key.asc
gpg --fingerprint F0D6B1E0
gpg --verify truecrypt-7.1a-linux-x64.tar.gz.sig
You should see: 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 B1E0https://twitter.com/matthew_d_green/status/47175105467398963...
http://en.wikipedia.org/wiki/BitLocker_Drive_Encryption#Secu...
Anyone know who the main committers/project leads are so we could reach out for comment/clarification?
It might be more likely that a dev got hacked, compromising the signing key, sourceforge project, and truecrypt.org site.
"Wed, Oct 24, 2013: We have made contact with the TrueCrypt development team. They have stated a commitment to a thorough, independent security audit and cryptanalysis of the code."
On the other hand, as pointed out in other subthreads, if the devs are tired of maintaining it, this could be a legit, unappreciated-developer version of a temper tantrum. Nobody seems to know (yet).
Every version of Windows after XP has a native disk encryption utility. TrueCrypt was built to bring full disk encryption to Windows, which didn't exist at the time - this is the developers way of saying "you don't need us anymore, Windows now does what we did"
I mean, a normal use case is a corporate laptop used when traveling or similar. Normal home users certainly have no need of it, for them it's just something else that can go wrong and destroy all their data.
They didn't seem that severe to me, they seemed pretty minor actually. Especially if your attack vector is solely a read attack rather than a read-write attack.
Which one got you worried?
Which, seeing as my current major use case is to lock down Dropbox, kind of renders it useless for me.
However you should not use XTS with Dropbox http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
I suppose the developers could have just found a massive vulnerability (perhaps they're doing their own audit in advance of the public one?).
>The development of TrueCrypt was ended in 5/2014 after Microsoft terminated support of Windows XP.
Since it's block-level, you can use any filesystem you like. Since it's BSD, you might as well use ZFS (but don't use data integrity verification if you do, since ZFS has that built in.)
Downside is that you have to use FreeBSD to get it. Upside is that you get to use FreeBSD =)
Thus, there is no cross-platform alternative.
And how do I handle sensitive stuff wrt backups? I could burn a Truecrypt volume to a DVD or Blu-ray. I cannot do this in any way with Bitlocker, can I?
Yes. There's BitLocker to Go for encrypting removable drives, and with Windows Professional editions you can create and mount a VHD virtual hard disk file as if it was any other drive, and Bitlocker encrypt it, e.g.
http://www.concurrency.com/blog/encrypted-container-using-bi...
Using this method you can easily burn or transfer your VHDs, you can also store VHDs inside of VHDs.
[1] http://www.infoworld.com/t/encryption/sloppy-secure-open-sou...
[2] https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_A...
Now seems like a good time to: git clone https://github.com/DrWhax/truecrypt-archive.git
http://volatility-labs.blogspot.de/2014/05/volatility-update...
I really hope it's "just" a defacement/DNS issue.
[0] https://twitter.com/maclemon/status/471727027356434432
Edit: Just saw the comment that they are properly signed. I'll just sit tight and wait for an announcement then.
>WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues That's worded awkwardly. >Not Secure As Emphasis on the NSA in "not secure as" >WARNING: Using TrueCrypt is NSA it may contain unfixed security issues.
I use Apple's FileVault on my laptop, but for particularly sensitive data (work code, financial info, etc) I always used truecrypt. We have no idea if apple is actually doing what they claim to be doing. The same applies to MS and bitlocker.
I find it very odd that this person also mentions BitLocker... Anyone know who this Peter Kleissner is?
[0]: http://istruecryptauditedyet.com(I'm just bringing up some new machines, myself -- I'll have to hunt a bit for local copies from the last time I downloaded (legitimate copies of) the 7.1a version.)
--
P.S. For two recognizable names/sites (to me, at least) near the top of a Google search, FileHippo and CNET are hosting Windows .exe intallers for 7.1a . No signature files, though. And with CNET (download.com), as I seem to recall and last I heard, they practice wrapping the actual product installers inside their own crapware installer.
In a few days there will be some information and possibly a fork.
I don't remember TC ever being hosted on SF, so I think this is a bad redirect...
All of the files are freshly uploaded.
--
Check this out too:
https://webcache.googleusercontent.com/search?q=cache%3Ahttp...
http://sourceforge.net/u/tc-foundation/profile/
====
https://webcache.googleusercontent.com/search?q=cache%3Ahttp...
Plausible deniability is the key here.
It think the FBI and/or the NSA bullied the developers and forced them to this.
Also: Places where plausible deniability is of use are reducing over time (in GB they can put you to jail until /you/ proove your drive is /not/ encrypted, other countries will follow). PD does not help here bc 'they' know about PD and (see above). If your disk is not empty (zeroed) but wiped with RND you may have already bad luck. I doubt they do cryptanalysis to see if your RND is true RND or an encrypted disk (I used to use a raw disk editor and to overwrite the boot loader with random data, using the boot loader from CD or UDB stick).
Dear mod, as you seem to moderate posts (of new user accounts??) I post here despite mailing: Please update http://ycombinator.com/newswelcome.html to reflect that posts are moderated before being published (and in which cases) and the actual meaning of "You're submitting too fast. Please slow down. Thanks." (i.e. which frequency is 'OK' etc.). It made your site easier to handle and so more attractive to users willing to abide the rules.
Thank you.
Please don't post comments like this one, though. As the HN guidelines say, you should email hn@ycombinator.com instead. We can't always answer right away, but we do answer.
It is not full disk encryption, so not a direct alternative for a product like TrueCrypt. I believe it uses a RAM disk for the files so you're limited in size, too - something like that.
Personally I'm not a big fan of using WebDAV to expose the encrypted file system - it seems like a large liability. But I'm not a real security expert at all, just saying it sounds complicated to get right (caching could keep a unencrypted copy) and exposes an even larger attack surface.
1. Truecrypt.org redirects to TrueCrypt's sourceforge account.
2. The sourceforge page is defaced.
3. There is a signed(?) binary which can only be used to migrate.
Sounds remarkably bad ( and remarkably much effort for the lu1z.) So is there a defined version for the audit? ( Such that there is a known good version to roll back to?)
Wild guess here but you might want to recreate any containers using tcplay and copy files over, rather than continuing to use possibly compromised truecrypt containers.
For full-disk encryption Linux has LUKS/dm-crypt/cryptsetup.
I honestly think that the government is behind this fiasco, nobody just ups and leaves a massive project used by millions without leaving a valid note.
Dropbox + Truecrypt take full advantage of block sync & block encryption i.e. if a tiny piece of data is modified inside an encrypted container, only the relevant blocks are synced on update. Dropbox does not need to sync the entire container each time. This is a very useful feature. I know Google Drive & OneDrive aren't that smart.
Will bitlocker + Dropbox work the same way?
Not that it makes it right, but the limitations of licensing are more ethical than practical.
http://www.etcwiki.org/wiki/What_happened_to_Truecrypt_-_May...
https://twitter.com/matthew_d_green/status/47199831543788339...
Of course, by 'they', I mean the fake development team that the hijacker of the site wanted to portray... no way this is real
I'm having trouble taking any of that page seriously however -- to be recommending closed-source solutions like Bitlocker as 'more secure'.
So they've put up a new version and telling us it's for migration only?
So it's not defacing, but dedefacing -or so ..
Am I the only one who things that is odd?
Does anyone have a cached version?
Edit: Found it. http://i.imgur.com/rmuogzH.jpg
I'd think it's to organised for a defacement (re-written code, signed binaries, two sites compromised). I can't see money being made, so can't see criminal.
That kinda leaves a state sponsor with the organisation skills and commitment. It gets to create doubt about the product and slow it's uptake down.
Or it's real :/
It hasn't even been a month since phase 1 of the first truecrypt audit ended. Which means up until now this piece of software was as shady as it could be.
The constant open source mantra of "code speaks for itself" strikes again.. except that none of the competent eyeballs have looked at truecrypt up until very recently (phase 1 audit ended in April 2014 which is ten years after the first truecrypt release). A lot of good did it do with OpenSSL too.
But surely, code written by anonymous, untrustworthy developers that hasn't been looked at much for ten years is worth more than code written by a corporation that has a public image to uphold.
As for "being targeted by government" that's called conspiracy theories. Unless you live in a place like Russia or Saudi Arabia you don't have anything to fear just because you wrote encryption software.
This is already happening and not a conspiracy theory any more:
[0] http://nakedsecurity.sophos.com/2012/06/08/interest-in-crypt...
[1] http://www.cnet.com/news/researcher-detained-at-u-s-border-q...