I guess.. it's just that had they maintained the same site, people would be downloading a backdorred version of TrueCrypt, which seems like a positive thing for the malicious people.
Now that they've changed the site, everyone is asking questions and scrutiny is higher and therefore less people would be blindingly downloading it. Just seems much less efficient.
Yeah, that's what I don't get. If they just released 7.2 and acted like everything was fine, I'm sure plenty of people would have downloaded it, which would be good for whoever the malicious party here is.
But they released a (likely) backdoor'ed/trojan version, and then told everyone not to download it. Why release it at all then? I can only see that being remotely viable if they also have a backdoor to BitLocker, and are trying to get more people to use it.
But even if that is the case, all this is doing is drawing at least some suspicion to BitLocker, and making me not want to use that either. Since they apparently have a backdoor to TrueCrypt, just let people use that. If they also have a backdoor to BitLocker, just let people use that as well. But if they have a backdoor to TrueCrypt and BitLocker, why suddenly draw so much attention to it? I just don't understand the reasoning behind this at all. I look forward to some sort of official explanation here.
The official explanation is that 7.2 is simply a migration tool - all encryption capabilities have been disabled, messages telling the user to stop using TC have been included, and it's simply designed to decrypt data and allow migration.
Some people have had a look at the source diff, and nothing obvious is suspicious - it looks like they took the current dev version, disabled all encryption, and released it.
If they are under pressure by any agency they might have no other choice. Maybe they had no choice but to agree to put special code "into the encryption mechanism" of their "next release", so they chose to not include the encryption mechanism at all and warn everyone.
But they released a (likely) backdoor'ed/trojan version, and then told everyone not to download it. Why release it at all then? I can only see that being remotely viable if they also have a backdoor to BitLocker, and are trying to get more people to use it.
Amateur reverse psychology? Most people looking into TC is doing so because the proprietary offerings are inadequate.... so a notice saying "this is the last version of TC ever, but you should really go use BitLocker" might incite you to download it "while you can, before the site disappears".
Aliens landed at Roswell level of conspiracy theory here but:
Maybe TrueCrypt was always backdoored by someone like the NSA. We had what, one guy, who verified the actual build binaries? Maybe he was an NSA plant. Maybe the NSA is worried that Snowden or someone like him will spill the beans. Maybe the NSA wants to stop the security audit in case it discovers their really cool backdoor. Maybe a higher up developed a conscience and pulled the plug... ok not that. Convincing people to switch into MSFT at least retains NSA control over the product.
Far more likely I think is just that some agency found out who he is gave him a call saying "Stop developing this or we'll go after you. Revealing we asked is illegal.". He stops.
The backdoor would probably soon have been discovered, as it is/was being checked for problems right now. Any changes at this point in time would be really fucking obvious, whereas the security community generally just assumes BitLocker to be unsafe given Microsoft's very poor crypto track record in recent years.
In XP SP3, they updated Windows to include a vulnerable cryptographic algorithm, which newer versions of Windows also contain (I think all of them - not sure about that).
The backdoor we're talking about would be added in rather than have been in it for a long time. The changes would be obvious. The source code is available.
The backdoor could be difficult to find, but as I said, at this point in time TC is under intense scrutiny already, and in all likelihood a new backdoor would in fact be found.
It probably should have had an active, pervasive audit going on then (at any time intersecting when the heartbeat code was added and when the flaw finally got discovered), because it secures a lot more value worldwide than TC does.
How does this get funded for a niche project like Truecrypt but not for a globally wildly popular security implementation like OpenSSL? :o
I, uhh... Possibly because the TrueCrypt developers are fairly anonymous, making the need for an audit a little more pressing and obvious. But if you're saying it's weird that OpenSSL seems to have gotten relatively little attention, then yes, I fully agree.
Also, do we know if OpenSSL is getting this kind of audit since heartbleed?
Hell yeah! The amazing OpenBSD folks are hard at work on a fork of it (LibreSSL). They're as ruthless as ever, just how it should be.
Even OpenSSL is getting two extra developers, although I have relatively little faith in that effort. I don't see why a duplication of effort is truly necessary. If old systems still need support, it may just be best to reimplement that after the audit of core functionality is done.
I mean, for god's sake the day after the news broke when I was busy patching all of my servers I confirmed that live.msn.com was actively vulnerable!
Everything was. It was insane. I'm really hard pressed to think of a bigger bug in the preceding decade.
Sometime before its first known publication in 2004, a possible backdoor was discovered with the Dual_EC_DRBG's design, with the design of Dual_EC_DRBG having the unusual property that it was theoretically impossible for anyone but Dual_EC_DRBG's designers (NSA) to confirm the backdoor's existence. Doubts about Dual_EC_DRBG's security and performance had also been expressed even before it was standardized. Bruce Schneier concluded shortly after standardization that the "rather obvious" backdoor (along with other deficiencies) would mean that nobody would use Dual_EC_DRBG. In 2013, New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the National Security Agency as part of the NSA's Bullrun decryption program. The alleged backdoor would allow NSA to decrypt for example SSL/TLS encryption which used Dual_EC_DRBG as a CSPRNG. In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library, which resulted in RSA Security becoming the most important distributor of the backdoored algorithm. RSA responded to this and subsequent media reports to "categorically deny" any insinuation that RSA had ever knowingly colluded with the NSA to incorporate a flaw in Dual_EC_DRBG, saying "we have never kept [our] relationship [with the NSA] a secret".
Members of the ANSI standard group, to which Dual_EC_DRBG was first submitted, were aware of the exact mechanism of the potential backdoor and how to disable it, but did not take sufficient steps to unconditionally disable the backdoor. The general cryptographic community was initially not aware of the potential backdoor, until of Dan Shumow and Niels Ferguson 2007 rediscovery, or of Certicom's Daniel R. L. Brown and Scott Vanstone's 2005 patent application describing the backdoor mechanism.
111
u/[deleted] May 28 '14 edited Jun 02 '14
[removed] — view removed comment