I don't see why people should spend money auditing it, instead of building maintainable alternatives
Bitlocker is great for enterprise-style encryption, in particular on machines with TPM chips. However many consumer machines do not include a TPM, even in 2015.
TrueCrypt allowed you to encrypt individual drives, even offline drives, with no Bitlocker overhead. You also weren't required to decrypt them upon each boot like Windows' Bitlocker insists upon.
Additionally TrueCrypt would also encrypt directories, USB drives, hidden volumes, various encryption algorithms, double encryption, and so on.
Plus it was cross-platform friendly (or at least more so than BitLocker). What are we meant to use to move encrypted data from Linux to Windows now? 7Zip w/AES 256?
OpenSSL is on every system and can encrypt files with aes-256-gcm if for whatever reasons libgcrypt can't be used http://stackoverflow.com/questions/12153009/openssl-c-exampl...
Tarsnap you can copy keys to any platform that will run Tarsnap http://www.tarsnap.com/man-tarsnap-keygen.1.html http://jamesoff.net/site/2009/09/10/tarsnap-under-cygwin/
If you want to move an encrypted file from Linux to Windows, though, you should use something like PGP.
What if my use case is different: keeping just a particular set of documents not in constant use secret? Perhaps stored on a removable drive? Truecrypt is great for this. It does have the risk of information leakage via tempfiles and swap, but it also makes you a lot harder to raid unless you've got the incriminating document open on your screen in a cafe (you fool).
(I was asked by someone I know who works in international human rights "How do I get my case files safely across borders?" and didn't have a good answer.)
(TrueCrypt had a weird license that makes forking a little strange; more here: https://security.stackexchange.com/questions/58994/are-there... )
(Edit: just saw tptacek recommending against the forks. I guess this is uglier than I thought. https://news.ycombinator.com/item?id=9069708 )
There's no free full disk encryption for Windows users with modern (UEFI) boxes. The money would be better spent on that, but returning crowdfunded money... tricky.
Truecrypt manages to create virtual disks that look a lot like regular disks, so I assume it does some kernel-level stuff to make that work.
When someone builds a new one (as happens every other day), we'll have to start again, right back at the beginning, fixing all the bugs in it and auditing it. About halfway through that process, someone will come along and say "I don't see why people should spend money auditing it, instead of building maintainable alternatives"...
There will always be new projects doing things in different ways. That's no reason not to make sure that something we have now works properly.
Or you can start trusting forks of Truecrypt that base their code on the post-audit code for Truecrypt.
I don't think anything would be _drastically_ changing in Windows 11 and 12.
One thing I noticed looking through the code is that the key generation on Windows mixes a CRC32 of a MOUSEHOOKSTRUCT. If you look at it, there isn't a huge amount of entropy in there... Some fields, such as the window handle, don't change between callbacks. Others, such as the hit test code are enums with limited possible values, and the way that most people move the mouse around will return the exact same value all the time. The difference in time between two different values is run through CRC32 a few times and then the whole thing is run through a real hash. Most users don't bother adding entropy from the keyboard.
While I don't think any of this is a vulnerability, I think it could be better.
[edit: I'm talking about Common/Random.c in 7.1a. And by better I'm suggesting additional sources of entropy be included in the process]
"By encouraging people to rely on tools like Truecrypt, you are, in a very small but real way, endangering them." [0]
It just seems like you supporting the audit (and therefore supporting TrueCrypt) is at direct odds with what you said an hour ago.
> Block-level encryption is a terrible, terrible approach for many reasons (which 'tptacek has referenced a million times). However, Truecrypt is the best such implementation, and it's a required approach in certain cases. You should be doing crypto at the application/filesystem level; if you can't, use Truecrypt. This isn't contradictory advice.
The only reason this even seems remotely contradictory is because you've taken Thomas's statement completely out of context (perhaps because it's nested about 50 lines in from the top-level comment that even provided the context in the first place).
Alternatively, it's only contradictory if you take a black-and-white, all-or-nothing interpretation of what Thomas says... which is quite ironic, because one of his key criticisms of Truecrypt is that it is all-or-nothing, as stated in the very same post that you quote[1].
The first is plausible, the second doesn't sound like the reaction an anonymous author would have.
Most plausible reason the devs abandoned it imho is that they got bored.
TrueCrypt is a discontinued source-available freeware utility used for on-the-fly encryption. It can create a virtual encrypted disk within a file or encrypt a partition or the entire storage device.
Since TrueCrypt is dead, what is the purpose of auditing it? Is there an official team that is ready, willing and able to take over maintenance and development?
If anything should be audited I would think it should be one of the forks.
But the author makes the following comment on the other thread:
---------------------------------- Also: speaking in no "official" capacity whatsoever, I'd advise you to stay away from the forks of Truecrypt. Unless something new has come to light since last I looked, the licensing situation on the TC code is weird: http://lists.freedesktop.org/archives/distributions/2008-Oct.... ... which means there is a pretty strong disincentive for people with serious crypto and systems expertise to invest their time and energy building on it. You don't want to trust crypto platforms with built-in adverse selection problems.
---------------------------
So the forks have issues and the main project is dead?? But we needz more money to audit it more?
I am also unclear what the first expensive audit accomplished if it did not cover encryption. Sounds like having an inspection on a house that covers part of the roof and two rooms and nothing else like the foundation. Does anyone have a link to the original campaign to raise money?
I asked that question, and received a response from tptacek here: https://news.ycombinator.com/item?id=9070420
Where do you see them asking for more money? They talk about how they're going to make what they have last longer, but they don't ask for additional donations.
To access existing volumes. All my backup CDs were TC encrypted.
And I haven't found a replacement that is all of easy to use, stable, and cross-platform. New encrypted volumes I make are LUKS but the Windows FreeOTFE is even deader than TrueCrypt. It still works, mostly, but could be a lot better.
I guess the alternative is to just lose all the data.
If the audit found any problems then it would most likely mean that further use was problematic, not that migrating existing volumes was problematic.
It makes sense to audit the common ancestor rather than a single one of the derivatives because you'll cover more bases. If TC is found to have a critical vulnerability then you'll know all forks have the problem. If one fork is found to be vulnerable then you'll need to figure out whether it's a TC vulnerability or some subtle dependency on the new code.
Because people still use it. There are no good, cross-platform alternatives at the moment. And even though they said it "might" have vulnerabilities none have ever been found despite the project being open-source. So yeah, it's a great thing that the audit is still going ahead.
