The money was raised to audit TrueCrypt before the developers abandoned it. The money must go toward that audit. The fact that the TrueCrypt devs abandoned the project changes what we should expect from it. Specifically, we should expect that moving forward, it's going to be a bad idea to use it.
This viewpoint isn't just tptacek's. When the TrueCrypt devs shut down TrueCrypt, they posted in big red letters "TRUECRYPT SHOULD BE CONSIDERED INSECURE" or something to that effect. They did that because, like tptacek, they are responsible crypto devs and are doing their duty: when no one is actively maintaining a project, it is inherently insecure because the security landscape changes so rapidly.
If the TrueCrypt devs were to step out of the shadows with some money to audit TrueCrypt's current codebase, yet maintained their stance that not having an active dev team makes the project insecure, would you aggressively badger them for their "contradictory beliefs"?
There is value to be had in auditing an insecure project's open source codebase. If any security problems are discovered, users will be able to assess their potential impact based on how they were previously using TrueCrypt. If they have old images laying around which are discovered to be decryptable, users will be able to delete them before someone else discovers that flaw and steals their data.
Secondly, if the codebase survives the audit relatively unscathed, then it serves as an example of how to write production crypto code (at the time it was written, not presently!) similar to how tarsnap is currently such an exemplar. The TrueCrypt code can't be used directly due to licensing issues, but it nonetheless serves as a "here is how to use these arcane Windows APIs in the context of security." Such guidance will be extremely valuable for future similar projects.
Lastly, I am kind of afraid to talk to you at all in case I incur your bullying wrath somehow, because if that were to happen, you'd kill the fun of HN for me. I imagine you're killing the fun of HN for tptacek.
Actually, tptacek isn't suggesting that the murky status of TrueCrypt's source code is why you shouldn't use it, he's suggesting that the disk encryption mode itself (XTS) is why no one should use it.
> Thomas changed his comments about 50 times between when we were replying to one another and now, so in all likelihood what I've written makes no sense in relation to what he's written anymore.
I was watching his comments and your replies back then in real time, and this did not happen at all.
You were seriously watching all of our interactions over the course of the past 6 hours, with enough detail so as to be able to diff individual comments over the entire time period?
Not all of your interactions over the past 6 hours as of that time, just most of the back-and-forth, in particular, with comments being posted up to "10 minutes ago" so there is a chance of ninja-edits made to be more polite (something I often do) and checking later I recognized all the sentences I read.
He added in the positive comments about TrueCrypt. Previously, his comments read as if he were completely opposed to all forms of TrueCrypt's use.
He also removed quite a bit of negativity and snark from his comments. Without those, the tone of the conversation shifts considerably.
What I'm trying to get at here is that there's a need for a TrueCrypt like product, and Thomas seems to think there isn't, or didn't last time I read his comments. He was suggesting that anyone who wants to actually encrypt their code should use PGP. I was arguing that such a strategy isn't realistic given the UX/workflow that TrueCrypt gave.
As I said earlier, what do you think the function of this comment is?
Of course you'd say something to this effect. The purpose of a comment would be to elaborate on why what I said was wrong; providing examples or evidence to the contrary is a great way to further any conversation.
I, unfortunately, have no evidence. So it's just my word. I realize that's not super valuable, but that's what I've got.
The point is that you were worsening the quality of HN by prosecuting an off-topic and seemingly personal agenda and taking the thread way into the weeds. Please don't do that. To steal a phrase from the HN guidelines, it never does any good and makes for boring reading.
If you have concerns about other things on HN, we'd be happy to look into them for you, but the way to make that happen is to email hn@ycombinator.com as the guidelines ask.
As a casual user, I would like to know how I am endangering users by encouraging them to use TrueCrypt? And what should I be encouraging them to use instead?
If your disk is mounted when your computer is stolen or confiscated, your data is accessible.
If your adversaries want your data, FDE will help them and not you. If you have secrets that would put you in danger if revealed, you would now be danger.
The alternative is file-level encryption. The only accessible files at any given time are the ones you're using, so if you are relieved of your laptop on short notice, not all beans will be spilt.
File-level encryption is a pain in the neck to work with. FDE is much more convenient, and a pretty good answer if your threat model doesn't include "drive by laptop snatching" as a major concern. This is most people.
> If your adversaries want your data, FDE will help them and not you.
Sorry to nitpick, but it may confuse a casual user: FDE will not help your adversaries, it just won't help you. That is, in those circumnstances (i.e., when your disk is mounted) FDE won't have any effect.
Agreed. The comparison which wasn't clear in that sentence was to file-level encryption.
At the point of seizure, your chosen data protection method is either helping your adversaries by offering all files unimpeded, or helping you by not doing so.
It's equivalent to having no data protection at all, if you adversaries are competent.
Ah, I see. Am I correct then that the cautionary note was just in general about the pitfalls of FDE if a mounted drive is compromised while mounted? I think I misinterpreted it to mean that there was a specific problem with TrueCrypt which leads its use to endangering users.
In my own use case and in that of people I've recommended TrueCrypt to, having the hard drive apprehended while shut down, specifically during customs checks, is a far greater risk than having the computer compromised while the encrypted drive is already mounted.
Given that particular threat model, is it OK for me to continue to use and recommend using TC?
If you cannot be surprised while the drive is mounted, and cannot be compelled to mount it (maybe just by booting the machine) then there is no known specific additional risk to running FDE.
Note that "surprised" might include a networked attack, in addition to being tackled in a coffee shop.
File-level encryption protects your data until you reach the court order level of compulsion, and possibly further. At least in civilized countries.
So, given those caveats, I'd say your answer is "yes", but...the best plan is to do both. FDE as a matter of policy, and file-level on any files of specific value.
Thanks again. Can you please clarify what is meant by networked attack in this context? Someone gaining access to the mounted drive over a network, or something else?
Sure. If your FDE disk is mounted and your machine is susceptible to any kind of remote exploit (OpenSSL, Adobe flash, weak ssh password, etc) then the attacker has full reign over your disk when they arrive.
File-level encryption constrains them to just the files you have open at the time, although of course any breach might be persistent, so they could theoretically wait around until supersecret.txt gets opened and grab it then.
