TrueCrypt suggesting migration to BitLocker?
271–280 of 414 posts
Re: TrueCrypt suggesting migration to BitLocker?
#272Earlier quoted context omitted.
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,…
>>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.
Does National Security Letter sound depressing enough?
Re: TrueCrypt suggesting migration to BitLocker?
#273Earlier quoted context omitted.
VC++ 1.52 is required to build the boot loader. You can still download it from MSDN. I can see why they would have an "if it ain't broke, don't fix it" attitude there.
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.
Re: TrueCrypt suggesting migration to BitLocker?
#274In 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 think it's most likely they just didn't want to develop it anymore...
It would be so easy for the person(s) in question to just say that, though.
I don't know what to think.
Re: TrueCrypt suggesting migration to BitLocker?
#275Re: TrueCrypt suggesting migration to BitLocker?
#276Earlier quoted context omitted.
We don't know much about the TC developers, do we? It's also possible that they're just really cavalier about this stuff, and that this is their response to the TC audit process ("stop bothering us about it and use something that's maintained").
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"
Re: TrueCrypt suggesting migration to BitLocker?
#277Interesting github project:
Re: TrueCrypt suggesting migration to BitLocker?
#278Earlier quoted context omitted.
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,…
>>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.
Re: TrueCrypt suggesting migration to BitLocker?
#279Earlier quoted context omitted.
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 think it's most likely they just didn't want to develop it anymore... It would be so easy for the person(s) in question to just say that, though. I don't know what to think.
After the years of silence and the previously infrequent updates, I don't consider it farfetched at all.
Re: TrueCrypt suggesting migration to BitLocker?
#280Is it possible that this is the result of a "dead man's switch" (DMS) set by the developer(s)? Perhaps a (continually updated) process was set up so that TrueCrypt would shut itself down if the developer were unable to prove he or she was still actively maintaining the software. 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…
What about the version 7.2 released? Either the dead man's switch:
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.