Live data from Hacker News

TrueCrypt suggesting migration to BitLocker?

truecrypt.sourceforge.net

351–360 of 414 posts

Re: TrueCrypt suggesting migration to BitLocker?

#352
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"

FDE was available from different vendors (I bought DriveCrypt PlusPack more than 15 yr ago and tried CompuSec (free) more than 10 yr ago, Comodo FDE is around since ~2k8). So availability of FDE software can hardly be the reason. Neither the credibility of M$, in matters of quality of code as well as especially being an US based company.

Re: TrueCrypt suggesting migration to BitLocker?

#353
post #208

Interestingly, an Infoworld review of the recent TrueCrypt audit [1] says: "One major issue was how compiling TrueCrypt from source required the use of an older Windows build environment that's noticeably out of date [...] using a shockingly old version of Microsoft Visual C++ released in 1993." Align this with what the TC website says now: "development of TrueCrypt was ended in 5/2014 after Microsoft terminated supp…

Nothing kept them from having an XP (VM) offline just for compilation. It was best practice for security related products (actually for any development) to develop and compile offline anyway.

Re: TrueCrypt suggesting migration to BitLocker?

#354
post #134
post #70

Earlier quoted context omitted.

If the audit turned up something bad, the obvious step to take would be to publish it in all detail, fix the flaw, and then tell users to upgrade as soon as possible. Not go "OK SHOW'S OVER, USE PROPRIETY SOFTWARE FROM NOW ON".

Nitpick: Truecrypt is proprietary (it's source is viewable, but you aren't licensed to distribute modifications of it).

Open(ish) source but non-free.

Re: TrueCrypt suggesting migration to BitLocker?

#355

Earlier quoted context omitted.

...or that BitLocker isn't.

I know everyone likes to bash MS around here but is there any actual proof of Bitlocker's insecurity that is more recent than 2008? If you look at wikipedia it seems like the only known real vulnerability requires someone with physical access to boot via USB into another OS within a few minutes of turning the computer off. When is this a real risk for anyone? I am not a security expert but unless you are doing things…

Don't forget that M$ gives you the great 'service' to store your BL-key in your M$-account (on their servers) as soon as a) your machine is not connected to a domain and b) you're [...] enough (most are!) to log on with an M$-account to Win8.x.

Re: TrueCrypt suggesting migration to BitLocker?

#356
post #161

Earlier quoted context omitted.

It doesn't matter why. If "we are now insecure" then the last thing you say is, "so please download these new versions, used only to decrypt your old files and nothing else." No we won't tell you what, if anything, was wrong, so you can make an informed decision.

The motivation would be so that if you had a TrueCrypt archive lying around on a drive that you find in 5 years time, it would be possible to decrypt it - but they don't want to allow encryption because they won't be continuing development, and so fixing future bugs will not be possible.

No matter how far in the future: If you find an 'old' TC volume/drive all you need to do is to install Win2k/XP/Vista/7, install TC 7.1a and decrypt. There's simply no need and practical use for a TC 7.2 with crippled functionality. Except one is forced by 'force majeure'. BTW: 7.1a is around on so many mirrors (and would be uploaded by enthusiasts if not) that it is ridiculous to post a crippled 7.2. Except one is forced by 'force majeure'.

Re: TrueCrypt suggesting migration to BitLocker?

#357
post #182

I'll leave others more knowledgeable in such things to comment on the legitimacy of this, but one practical thing I'll note: the assertion on the site that Windows Vista/7/8 has support for encrypted disks is only half true. Quoting from Wikipedia [1] "BitLocker is available in the Enterprise and Ultimate editions of Windows Vista and Windows 7. It is also available in the Pro and Enterprise editions of Windows 8." S…

It's worth pointing out that it doesn't leave people with a free migration path, but it is absolutely easy. Windows 7 and 8 both support "anytime upgrade" functionality, where you can pretty trivially upgrade from Home/Home Premium to a higher-level edition of Windows without needing to reinstall anything or move data--just as long as you pay for the more expensive edition.

Also there are 3rd party (paid and free) FDE tools available.

Re: TrueCrypt suggesting migration to BitLocker?

#358

In case this is legit: Bitlocker so far so good, but neither Bitlocker nor any other crypto solution offer plausible deniability (aka hidden volumes).

I've heard multiple rumors that the NSA has a backdoor in Bitlocker. I don't trust any of this.

I suppose this leaves yet another possible explanation: A secret order with the intention of getting people to stop using truecrypt and start using bitlocker (possibly either bl and/or tpm has some convenient back doors in them...)?

Re: TrueCrypt suggesting migration to BitLocker?

#359
post #266
post #230

Earlier quoted context omitted.

It's not that simple. It won't match anyway. Signatures, compiler versions, SDK versions, etc.

This guy managed to compile a previous version and have it match the released binaries https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binarie...

Not quite. First, it was a ton of work to do so. Second, in the end he in fact only managed to match most of the released binary. Then, for most of the unmatched parts he came up with some solid arguments why they would be different (timestamps, pathnames and such). However, in the end there were still a couple of chunks of unmatched data that he couldn't explain why it has the value it does. Finally he argues that these chunks probably can't contain any hidden backdoors. This last bit I have a bit of a problem with because it's just speculation, all the rest of the research is very solid and without guesswork, and the conclusion of the article IMO incorrectly states he "has matched the binaries".

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.

Post reply on HN