Another update on the Truecrypt audit
blog.cryptographyengineering.comThis project will probably get outdated by windows 11 or 12, it will lose support and become legacy ...
I don't see why people should spend money auditing it, instead of building maintainable alternatives
TrueCrypt was much more flexible than anything Windows has to offer.
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?
Not to mention how much the US governments advocates against encryption they can't have backdoors to. They have a lot more influence over the encryption in Windows than TrueCrypt. Not suggesting they DO have backdoors to Bitlocker, there's not enough evidence, but the probability is much higher.
They do in the form of OneDrive.
https://news.ycombinator.com/item?id=8546524
Short story is that if you use Windows 8{.1} and have a Microsoft account then it will upload your BitLocker keys by default. Seems to me like a backdoor if ever I heard one.
Tar the directory(s) and use GnuPG/libgcrypt aes-256-gcm https://www.gnupg.org/documentation/manuals/gcrypt/Available...
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/
This is a huge pain for when you want to read it again. Truecrypt will let you define little mountable volumes which can be loaded as you need them.
I find tarsnap much easier/better than any block crypto mount. Intelligent backups that only synch what you've changed. Luks containers and tc-play exist if you must use a mounted container.
Both Bitlocker and Filevault allow this same UX. On Windows, you create and encrypt a VHD. On OSX, you create an encrypted DMG. There's even an OSX tool, "Knox", that (when we used it) did a really great job managing lots of little encrypted volumes.
If you want to move an encrypted file from Linux to Windows, though, you should use something like PGP.
So tptacek's argues that sector-based full-disk encryption is inherently vulnerable, especially if used on the boot volume, because if someone grabs your laptop everything's still loaded in memory.
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.)
If the documents aren't in constant use, the most secure way to encrypt them is with a userland program like PGP. Userland crypto knows where files begin and end, and can store metadata to improve the encryption. They can provide cryptographic integrity --- far more powerful than the incidental integrity check Bitlocker tried to provide, or the virtually zero integrity that XTS provides. They're randomized, so the ciphertext can have semantic security; it reveals nothing at all about the plaintext, even as the files are edited in place under the same key.
Sector crypto can't do anything even approximating this without contortions like geli.
If I was trying to protect files from nation state adversaries, I would not consider Truecrypt.
That doesn't mean I think you shouldn't run something like Truecrypt. I think you're better off with whatever your OS provides, but some kind of sector-level crypto, be it Bitlocker, Truecrypt, or Filevault, is still useful.
But if you're serious about protecting a specific set of files, encrypt them manually, no matter what else you do.
Can PGP do true edit-in-place, or do I have to decrypt to local disk first? Because decrypting to local disk is very likely to leave plaintext lying around somewhere unless my primary SSD supports "secure erase free space" and I remember to use it.
Good point. It doesn't; you need to securely delete temporary files. Mitigating that:
* Sector-level crypto is cryptographically incapable of secure in-place editing; they can gradually leak information about the plaintext as edits happen. That's not a big deal for a PDF, which aren't on-line live real-time edited, but it can be a big deal for other kinds of files. I tend to err on the side of systems programming weaknesses rather than crypto weaknesses. We're better at dealing with them.
* No matter what kind of cryptography you're using, the assumption you should be making is that plaintext is at some point exposed to someone who owns up your live running system.
I think concern about unlinked plaintext-containing sectors is reasonable, and a good reason to use both sector-level crypto and file-level crypto. I use both, as does everyone at Matasano.
If any of the TrueCrypt forks gain traction, this will be useful as at least it establishes an audited baseline.
(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 )
I would use the word "messy" in preference to "ugly", since I think there are best intentions all around in this situation.
Not sure why you've been downvoted. There is no active development on the project any more and it doesn't work with UEFI.
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.
This is HackerNews. Being right doesn't get you upvotes.
This is extremely unlikely. Windows API doesn't change that drastically between versions. Which is why people don't have to recompile their programs for newer/different versions of Windows.
Windows maintains good compatibility for userspace applications, but they don't guarantee driver compatibility. A Windows 95 program might run on Windows 7, but drivers for Windows 95 probably wouldn't!
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.
I don't see why people should spend money auditing it, instead of building maintainable alternatives
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.
I think the main issue with encryption from windows is the lack of opacity.
I don't think he meant use Bitlocker, but that the current Truecrypt will stop working in Windows 11 or 12.
Or you can start trusting forks of Truecrypt that base their code on the post-audit code for Truecrypt.
Ah, oops. But yah, overall I think auditing TrueCrypt is just as relevant today as it was when it was stalled in development and they raised the funds.
I think the word you're looking for is 'transparency'.
right, I would have rather written "their opacity", rather than "their lack of opacity".
People have already spent the money to audit it, back before development was officially discontinued. What do you expect them to do with the money? Return it to the people who donated?
Do you have any source to say Truecrypt becomes outdated? The last I checked, it was working just fine in Windows 8.
I don't think anything would be _drastically_ changing in Windows 11 and 12.
I'm looking forward to the next report.
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]
It doesn't at least try CryptGenRandom?
You are right, it does use that if available. It grabs a bunch of other system state as well, depending on the situation.
More discussion: https://news.ycombinator.com/item?id=9069295
Can you explain this quote from you and your involvement in the TrueCrypt audit?
"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.
It's pretty easy to explain - and in fact, you got your answer[0]
> 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].
Though I'm no tptacek, I think the reasoning here is that even though TrueCrypt is undergoing an audit, it's not under active development and unfortunately due to the licensing, any patches produced by the community could be on uncertain footing legally.
You can be proud, make 10000% more money that true crypt developer for several years working and now act like nothing happened. This audit was reasons why TT is offline
Sorry, didn't understand that.
Think he was getting at a theory that the development of TrueCrypt was abandoned because of the audit, for some reason. Maybe for reasons of pride (questioning their integrity by looking for backdoors) or fear that something nefarious would be uncovered.
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.
From Wikipedia:
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?
> Since TrueCrypt is dead, what is the purpose of auditing it?
I asked that question, and received a response from tptacek here: https://news.ycombinator.com/item?id=9070420
> But we needz more money to audit it more?
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.
> Since TrueCrypt is dead, what is the purpose of auditing it?
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.
If someone needs to access existing truecrypt volumes in order to migrate data, I dont see how the audit helps since the only way to get the data is to use truecrypt.
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.
> Since TrueCrypt is dead, what is the purpose of auditing it?
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.
> Since TrueCrypt is dead, what is the purpose of auditing it?
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.
It's worth noting, I believe the effort to audit TC began before they "shut down".