Live data from Hacker News

TrueCrypt suggesting migration to BitLocker?

truecrypt.sourceforge.net

281–290 of 414 posts

Re: TrueCrypt suggesting migration to BitLocker?

#281
post #243

Suppose that the author received a secret order from a secret court that required the author keep secret the secrecy of the secret order from the secret court. Furthermore, the author was secretly required to turn over his secret signing key to a secret third party. If you were the author, what would you do? Consider your options. One is that you could issue an update with a warning that the program is no longer secu…

That strategy would be consistent w/ Peter Watts' The Scorched Earth Society: A Suicide Bomber's Guide to Online Privacy: http://boingboing.net/2014/05/27/peter-wattss-the-scorched-e...

Re: TrueCrypt suggesting migration to BitLocker?

#282

Earlier quoted context omitted.

>>After examining all the facts, I think it's most likely they just didn't want to develop it anymore: 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.

They haven't updated it for years. I'd hardly call the behavior "juvenile" nor would i call it "devaluating". They've simply abandoned it and are offering alternatives.

I think suggesting BitLocker as a viable alternative to their work is "devaluing" their work. Who would trust BitLocker not to be vastly more compromised that TrueCrypt?

(Devaluating? sic? Or is that actually a word?)

Re: TrueCrypt suggesting migration to BitLocker?

#283

Providing some details from SourceForge: 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…

2. We see no indicator of account compromise; current usage is consistent with past usage. I'm calling BS. This site was disabled repeatedly for exceeding bandwidth today. I find it hard to believe traffic is as usual.

Actually, this is standard behavior for the SourceForge project web service. Bandwidth usage is capped to prevent folks from serving files from project web instead of the mirror network-backed download service. Staff saw the surge in traffic to the project web site, confirmed it wasn't file serving activity, and re-enabled the site.

Re: TrueCrypt suggesting migration to BitLocker?

#284
post #276

Earlier quoted context omitted.

True. Security announcements have been botched in the past, for all sorts of reasons, not that you have any experience with that, of course. But what does XP being EOL'd have to do with anything ? That and the blithe recommendation to use other solutions, even though they don't have hidden volume functionality which is a main selling point of TC, is what changed my mind, from thinking this is probably a legit mishand…

> But what does XP being EOL'd have to do with anything? 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"

Not every version... In case of Vista and 7 only Enterprise and Ultimate editions have it and in case of 8/8.1 you need to have Pro or Enterprise edition.

Re: TrueCrypt suggesting migration to BitLocker?

#285
post #177
post #170

Earlier quoted context omitted.

The element that does not square with any theories that suggest benevolent intent behind the change is the recommendation that users switch to Bitlocker. Surely, a Truecrypt developer who got served a gagging order to build in a backdoor would realise that a big and compliant target such as Microsoft would have been subject to the same measure long ago, and likewise that if a pre-existing vulnerability on a sufficien…

> The element that does not square with any theories that suggest benevolent intent behind the change is the recommendation that users switch to Bitlocker. 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?

That's my take on it as well, even though it fails the Occam's razor test. This all sounds like a very understated way of saying "we can no longer develop truecrypt with impunity, and the only other options are closed source, and highly likely to be compromised out of the gate".

Re: TrueCrypt suggesting migration to BitLocker?

#286

Providing some details from SourceForge: 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…

2. We see no indicator of account compromise; current usage is consistent with past usage. I'm calling BS. This site was disabled repeatedly for exceeding bandwidth today. I find it hard to believe traffic is as usual.

I think it's fairly safe to say that rgaloppini meant account usage. i.e login and other authenticated activity.

Re: TrueCrypt suggesting migration to BitLocker?

#287
post #273

Earlier quoted context omitted.

But, being a 16-bit program, it won't run on 64-bit windows. I'm not even sure it would install properly on anything newer than XP. I haven't tried installing it since the 9x days. 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.

Its a boot loader, It runs while the system is in real mode (16bit), before windows itself has booted.

The compiler is 16-bit [1]. It won't run on 64-bit Windows.

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.

[1] http://en.wikipedia.org/wiki/Visual_C%2B%2B

Re: TrueCrypt suggesting migration to BitLocker?

#289

In order of likelihood: * 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 o…

After examining all the facts, I think it's most likely they just didn't want to develop it anymore: * 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,…

I agree that it appears the developers are calling it quits. If you look at the diff itself, they have replaced large chunks of logic with an abort routine, passing the message "Insecure App".

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.

Re: TrueCrypt suggesting migration to BitLocker?

#290
post #116

Earlier quoted context omitted.

There is a relatively recent audit[1] of EncFS with some damning results. I really wouldn't use it. [1]: https://defuse.ca/audits/encfs.htm

> damning results 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?

> EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature.

Which, seeing as my current major use case is to lock down Dropbox, kind of renders it useless for me.

Post reply on HN