Hacker News new | past | comments | ask | show | jobs | submit login

A person who the Truecrypt Audit Project has some evidence is the actual Truecrypt developer, in an email I've seen (because I'm working with the project), more or less confirmed this story.

In particular: many people on HN seem to think that Linux Truecrypt is the most important product of the Truecrypt project, but the developers don't see it that way; they started the project for Windows, and Windows has good FDE now.




> Windows has good FDE now.

Only for those running Ultimate or Enterprise edition. What's everyone else supposed to use?


Well if encryption is that important you either buy a version of Windows which has FDE or you buy some other proprietary software which can do FDE. You can just keep using TrueCrypt until you need to upgrade Windows and get BitLocker supported edition.


> What's everyone else supposed to use?

At the risk of sounding snarky, Linux?

If you're not using Ultimate or Enterprise, you're probably not a business, so you probably don't have any business-critical applications that need to be run in Windows, so you can probably just use Linux for anything that needs to be kept encrypted.


Switching to Linux is a conceptual and time-consuming burden that the average consumer will not deal with. Widespread adoption of encryption can only be achieved by making it as simple as possible.


Do you think anyone who is ready and willing to use encryption on Windows is incapable of switching to linux?

FWIW, a non-negligible percentage of my not-computer-savvy friends have switched to Linux over the last few years because they mostly just need an internet machine after all, and were tired of dealing with windows. Most of them seem to have no trouble after they figure out how to boot a liveUSB.


> Do you think anyone who is ready and willing to use encryption on Windows is incapable of switching to linux?

Yes, because I know people who fit that exact profile. Just Friday I was talking to a person who had found TrueCrypt a few years ago and used it ever since, who wanted my help with what the dramatic website shutdown meant for them. "Just switch to Linux" certainly would not have gone over well.

The set of all people who (a) cannot afford Windows Ultimate (b) rely on Windows-only software and (c) want encryption is non-negligible.


Windows 8 Pro comes with Bitlocker and is fairly cheap.


> Windows has good FDE now.

A BitLocker's "feature" is that you can recover your key! So can Microsoft, NSA, etc. See: https://twitter.com/TheBlogPirate/status/471759810644283392


You can recover it if you decided to store it on MS servers. You can just not do that.


That doesn't remove any reason not to trust their implementation.


Sad but true - Given Microsoft's all-too-eager cooperation with the TLA's, any encryption product they pack with the OS is immediately suspect.

That doesn't just apply to Microsoft. I wouldn't trust FileVault on Apple or Red Hat's implementation of LUKS either.


What's the closest thing to a fact you can supply about Red Hat, Apple, or Microsoft subverting FDE software on behalf of any world government?


It's not that they subvert FDE in a provable manner (indeed, the manner of such a subversion would make it almost impossible to prove anyways..), it's that they eagerly cooperate with certain agencies. Microsoft is documented to have given zero-days to government agencies before patching them.

They may or may not be subverted, but why take the risk when you can use something that has a greatly reduced chance of that risk and works cross-platform?


>[Apple & Red Hat] eagerly cooperate with certain agencies

Last I heard on Apple was that their system is perfect, as long as they don't add another key to your iMessages which you'd never know of. So not perfect, but only if you are chosen to be inspected. It can't be part of a dragnet collection unlike say https if the NSA have the private key.

For Red Hat the best I can find in your favour is that some of them have NDAs on their conversations with the NSA.


My SSBN used at least two separate subsystems running Red Hat-based servers as a part of their functionality. Yet another separate system used X11. Thanks, FOSS devs! :)


We won't be given any of those until 2035. Isn't it always 20 or so years later unless you get a Snowden?


When ever there have been a dispute regarding export control of crypto and microsoft, they have opted to exclude encryption or use something like DES with low keysize. Microsoft has also sold exploit tools for windows, which is serious regardless if FDE software was one of the exploits targets.

So, given their history, has they done anything to actually earn our trust?


What are you talking about? Microsoft doesn't source even an appreciable fraction of the exploits for exploitable bugs in Microsoft products. There is a 9-figure business in reversing WinAPI software, discovering vulnerabilities in it, and weaponizing them with exploit code. Microsoft is a bystander to that industry.


I would not call Computer Online Forensic Evidence Extractor (COFEE) to be a bystander. Might be small in the grand scheme of things, but password decryption, data and volatile memory extraction is commonly associated with exploit kits for a reason. It uses vulnerabilities in windows in order to bypass the need to ask for permission.

If a company develop a kit that exploits the internal design of their own product, you are not a bystander. Bystanders do not sell exploit kits.


Are you seriously comparing a crappy forensics tool to a modern exploit kit?

Do you think Wietse Venema and Dan Farmer are suspicious for having released The Coroner's Toolkit? Should we all stop running Postfix now?


In what way is The Coroner's Toolkit using postfix vulnerabilities?

The only relationship those two project has is that they share the same developer. COFEE however exploit microsoft own products.

It seems you are arguing that trust is not effected if companies first sells a product, then sells exploits for that product in secret. It may be small, or unimportant, or old product, but it doesn't really matter to me. Trust is not something that should be given out lightly.


You mean that Microsoft is a victim, who is actively fighting against this 9-figure business, not just a bystander.

Otherwise why bother with exploits, just build good, solid C# backdoors and get over with it already.


Apple has this 'feature' too.


It's a perfectly reasonable feature. For one, it's not just for Microsoft servers -- in an enterprise environment you can just have it stored on your companies AD servers, so if for any reason an employee forgets or loses their key the company can recover the data.

However, you're still missing a fundamental aspect of security, which is that it's targeted, not universal. Your system is not 'secure', it's 'secure against x', where x is your adversary. If your set of adversaries includes, say, someone losing their laptop at the airport, but not Microsoft, then storing your keys on MS servers loses you nothing and gains you ease of use.


This does not explain why they would do something as inexplicably naive as recommending that everyone use a closed-source solution for encrypting their data in 2014. (And conversely, if it were really a matter of them having had a change of heart and suddenly coming to perceive the world to be such a nice and simple place, why didn't they just sign the final declaration with their real names, given that the threat of them being forced to tamper with future versions is now moot?)

It seems like people are still somehow willing to believe that even if a spy agency had set its eyes on Truecrypt, they could not force them to make arbitrary statements to people sending them e-mails or members of the audit project.


Only on HN, Reddit, and Slashdot is a recommendation of Bitlocker "inexplicably naive" because it's "closed-source". Meanwhile: I trust my sources a lot more than I trust your totally unfounded, straight- out- of- the- first- thoughts- that- came- to- your- mind speculation. One substantive difference between my sources and your speculation: I actually have sources.

The fact that the "warrant canary" scenario with Truecrypt is also silly also weighs heavily against your argument. Try to game out the scenario where Truecrypt is actually compromised. Especially funny: it's compromised at exactly the moment when a third party crowdsources an expert review of Truecrypt. That's when they choose to backdoor it. Seems legit.


> Only on HN, Reddit, and Slashdot is a recommendation of Bitlocker "inexplicably naive" because it's "closed-source".

I would be interested in seeing the argument of someone who is not part of "HN, Reddit, and Slashdot" against the proposition that cryptographic software that only few people have access to the source of is not trustworthy. I do not claim being involved particularly deeply in either the academic or the industrial security community, but my impression from the occasional academic discussion group I have managed to find the time to drop in on always was that this and/or some related proposition was part of what is commonly held to be true beyond the need for argument.

Regardless, there are two separate questions here - firstly, whether some sort of foul play actually was involved with the Truecrypt project closing up shop, and secondly, whether the recommendation to switch to Bitlocker should be considered sound or not. I believe that the recommendation is dangerous regardless of what happened with Truecrypt - at the very least, making no recommendation at all or telling people to stay with Truecrypt (7.1) for the time being and giving the OSS community some time to try and fill the vacuum is not worse than making said recommendation under any circumstances. In that light, even if your scenario is more compelling, I would argue that simply to err on the side of caution, one ought to refrain from pushing a narrative to the effect of "nothing fishy here; these perfectly trustworthy people just told you to use Bitlocker, make of that what you will" at this point in time.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: