With the suspicious disappearance of TrueCrypt and the strange advice of moving to bitlocker now showing on the original site, can you recommend suitable alternatives to what TrueCrypt used to be known for?
Im not entirely sure, but I think you an use older versions of truecrypt.
Since you self-hash your encryption (via random mouse movements), there is no "magic key". So an older, uncompromised version should work.
Does anyone know the current status of the second phase of the TrueCrypt audit? I've heard nothing since the completion of the first phase, which has been some time now.
As far as replacements, use Linux and do a full disc encryption install.
@Phantom
Do you know what the last known good version of TrueCrypt was? I've been told 7.1a, but I'm not sure if that's true.
@Resistor
I want to make the move to Linux, but at the moment I use several programs that aren't available on that platform and the alternatives aren't as good.
You should see if they will run with Wine on Linux imo.
Version 7.2 is the latest version and 7.1a is the version before and the version I use (installed prior to fiasco).
It doesn't make sense to ask "what the last known good version of TrueCrypt was" because version 7.2 was signed using the same key that signed 7.1a. This means we don't have any actual reason to trust 7.1a over 7.2 and vice-verca since the same verification was used for both versions.
They prolly just didn't want to support the software anymore for various reasons.
P.S. Virtual box/wine are available for linux and LVM allows for FDE right at install time for linux distros worth using.
Kind of interesting pertaining to this. https://www.livebusinesschat.com/smf/index.php?topic=5629.0
Well I had a big long explanation typed up as to why true crypt is possibly vulnerable but my cat jumped on the keyboard and its that's all gone now I probably should have typed the response in a word processor first and then pasted into the response box but I didnt so now you get the voice recognition dictated version it's going to be messy and lacking a lot of punctuation and I apologize for that but it's a nice day out and I want to get out on the bike.
When the true crit project was shattered the dead simply stated that the software was vulnerable in that you should use something else they were very nonspecific and it didn't bother to provide any detail as to what the vulnerability actually was. Who knows why they did this was it because they wanted to protect users of the product during the transitional time that they would need to move from true crypt to another product? Did they do it because they thought that true crypts would be found to be vulnerable to warring Indian head being independent audit of the software and dean one a few like they ended up with egg on their face after almost a decade of development? I don't know and I don't think anybody ever will. The one thing we can be sure of is that they bought somehow the product was vulnerable and whether they actually knew specifically with what was vulnerable war what the vulnerability was that might be debatable.
So what is it that we know about true cryp to right now? We know that the first part of the independent audit cryp Autoit is complete. In the first part of the audit the parts of true cryp that were a analyzed were the boot loader and the kernel drivers or at least they were the primary focus of the audit. The audit found that there were no major vulnerabilities or backdoors in this part of troop crypt. This is actually sort of the interesting because traditionally these are the places where you'd expect to find those things because vulnerabilities here would essentially allow you to trick your way into the encrypted data. So if the known vulnerabilities aren't there there's only 1 other police for it to exist and that's in the encryption algorithm itself. And that sort of makes sense because lately the threat to encrypt should that we've been seeing has been an attack on the keys space.
With this type of attack the hacker or let's say maybe a gov't looks at an encrypted piece of data and is able to determine that the key for accessing that the data actually only falls within a key space of 100,000 possibilities vs. The encryption is in hearing 100,000,000 possibilities this greatly narrows than necessary scope of attack and with the increasing availability of cheap computing power and keys spaces that all orders of magnitude smaller than the algorithm had been designed four these makes the encryption itself vulnerable to attack.
So ultimately it doesn't matter what version of true cryp you're using and it doesn't matter whether you are hashing yourself or if are rated number generator is doing it for you.Because underneath of all that you have the same algorithms protecting the data. Ssome of these algorithms that have been around for years are having to be looked and thought about differently. That's why people like google are learning to use parabolic curve algorithms to protect data going forward. these new algorithms will provide a much more secure key space while it at the same time using a key that will be small enough as to not hinder the performance of applications and operating systems using encrypted data.
Its very important in a time where a lot of the algorithms we've been reliant on turn out to have been developed by the same people we are now concerned are eaves dropping on our data. It's a complicated question because on the other hand to you trust? open projects like true crypts where we have real Idea who the developers and contributors are? Do you trust a private company like Microsoft who has traditionally worked with or rolled over four various governments around the world? Do you trust the governing itself? At least we know they're snooping on the data.
silly kitten ^^
The Truecrypt dev team did not actually say that there was a real vulnerability; they only implied that their could be one. Warning: "Using TrueCrypt is not secure as it may contain unfixed security issues". -Well that's true for anything and everything. This is why Linux derivs, iOS, Android, Windows, Firefox, Chrome, LastPass, TLS, and Wordpress all need to be regularly updated. Truecypt was designed with security in mind from the start so there's a significantly smaller attack surface but improving the coding style and fixing minor issues discovered through an update would be nice. The same could be said for BitLocker, Linux's LVM partition encryption and OS/X's container encryption which they suggest using.
Personally, I think the comments about vulnerable software directly relate to them ceasing development since they won't be updating the software (they won't but Truecrypt.ch is picking up the project). Technicality all the minor issues pointed out in the audit are “unfixed security issues” and they could be saying that they don't want to be responsible for fixing them anymore.
So why are they ceasing development? If you look at what happened to Lavabit and the fact that government agencies are asking software vendors to install back-doors in their software, it's entirely possible that the developers simply didn't want to be put in that position: install a backdoor or go to jail. So they left before they were put in that position. Secret government orders are pretty scary.
However, we don't know. We can speculate all we want, but we haven't actually discovered any real vulnerabilities that they claim might be in the software.
The attack you speak of on the keyspace is an attack on the psudo random number generator that truecrypt uses when creating the actual encryption keys and that is incredibility unlikely to present a real vulnerability since TC uses mouse movement as a seed to prevent exactly that (the TC dev team is/was pretty paranoid). TC uses AES 256 minimum so a key of 256 bits and even if we assume poor RNG (the attack you suggested) and zero our half the bits, the keyspace is 2^128 and that's level of encryption is still unbreakable and will be for a while short of quantum computing. A 128 key space is what protects our SSL/TLS atm and the most I've heard of the government actually cracking is 56-bit DES. Given that tinfoil sales are up, we might assume that 64-bit or shorter symmetric keys (depending on cipher) are brute-forcable. But none of this makes sense because why bother to crack a 1024-bit RSA certificate when you can just go to the organization that issued it and demand their private key (Lavabit)? Why bother trying to put a backdoor in TC to reduce the keyspace when you can just threaten some citizen with legal action if they don't give you their password or the “unencrypted contents” of their containers? It's rarely the math or software that's the issue when a security breach occurs, it's nearly always the human factor. I mean people actually tell border patrol what their passwords are for their devices when asked just because the person asking is in a uniform. Seriously >.<
Even if we assume they tried anyway, we have every reason to “trust the math” (especially when the spot most likely to have a back door turned up clean) and no reason not to despite some unsubstantiated claims to the contrary. Even if the developers are the ones saying that, nothing changes. Which means 7.1a and 7.2 merit the same amount of trust (whatever that level may be).
As a developer, if I was dumping a project, I'd prolly upload/compile whatever bug fixes I had finished (7.2), and then wash my hands of the entire affair.
Totally forgot about the original post. So as alternatives to TrueCrypt! For data privacy, there are ideas of container-level encryption, file-level encryption and full disk/partition level encryption.
Truecrypt always did container-level since it offers better obfiscation of meta-data like file names, access dates, the fact that the container might be empty etc. TC also offered full disk or partition level encryption for windows only.
File-level: For alternatives to TC, it might be better to simply switch to file-level encryption since it's more appropriate for a hybrid cloud enviornment (BoxCryptor, AxCrypt, Cloudfogger) but for strait up alternatives:
FDE: For windows Bitlocker (it's totally usable), OS/X ionu, don't use it anyone know of something?, Linux: LVM partition-level encryption only.
There's also this super-neat project called Qubes OS which solves most of the problems that truecrypt had when used in FDE mode (DMA related issues mainly) by using IOMMU/VT-d (hardware enforced device/bus isolation) that is focused around creating many Intel-V/AMD-V supported VM's (which totally means windows apps can be virtualized at near-native performance!).
Container-level: For Windows, combine VHD files (can be created using disk manager) with bitlocker selective drive encryption. For OS/X use disk utility to create password-protected containers as recommended by the TC team. and ionu about Linux (anyone know of a container-style encryption solution for a Linux deriv?)