And it still seems to be the only solution to work cross platform, free, open source, that offers plausible deniability, and doesn't have any critical bug or backdoor.
What would be nice would be for these researchers to publish those fixes. And let the unofficial forks (like Veracrypt) to incorporate them.
Researchers can't necessarily actually publish "fixes", they might give some recommendations or suggestions how to mitigate it, but they might actually be unable to publish full code fixes because it's simply not their area of expertise.
Bruce Schneier for example is some one who's able to design actual ciphers and cryptographic systems, but I'm not sure if he can actually "build" them as far as software systems go. From what I know of him, his works, and from reading his books he's a traditional computer scientists and much less of a developer, and I'm really not sure if he's up to date with the current C++ language standards and compiler architectures or insert what ever language you want here, in fact I would bet my money on the fact that he isn't but he's more than capable enough to find the right people to do that work for him.
That said based on reading the audit report form the TC audit the findings are detailed enough so if you are capable of truly understanding them you should be capable of finding a way to resolve them, if not you shouldn't be developing cryptogrphic software in the first place.
Not for encrypting USB drives. If that's your use case then it's probably better than any unaudited software.
I don't get this obsession with updates. If it's secure now for certain use cases then an update could only put that use case at risk. It's not like it can get "more secure" or something.
Of course it can. A system that was secure in 2005 doesnt necessarily have to be secure in 2015. With that in mind, it might be a good idea to slowly move away from TrueCrypt to a system that is equally secure but actually maintained.
Time, it's less about new vulnerabilities being introduced and more being discovered, some issues for example like identifying some statistical bias within say the software PNRG that could potentially be used to regenerate encryption key enmass more economically also only increase with time.
That said considering the circumstances in which the "developer" of this software disappeared, how it was presented and the fact that it is not maintained anymore should make people think twice about using it.
The second paragraph of the article lists multiple new vulnerabilities found in Truecrypt just recently, some of which make the overall encryption weaker, others which allow attacking a mounted drive.
An attacker knowing these flaws now has a smaller attack surface than a decade ago, since he now knows some weaknesses.
I don't use TrueCrypt myself, and haven't followed what's happening with it in any detail, but I'll comment on the general question here: why do you need to keep up to date with vulnerabilities in order to keep secure.
First, nothing is ever totally secure. If a system gets audited today, the best the auditors can say is that to the best of their knowledge, the system has either no flaws, or list the vulnerabilities they know about. There might be vulnerabilities they missed. Some of the unknown ones might be blatant (say, a backdoor), or very subtle. When the unknown ones are found later on, and become public, the only way to not be vulnerable to those is to update.
Second, a system may become vulnerable later by the environment around it changing. This might be, for example, a change in the compiler (you rebuild for a new platform, and the kernel introduces a vulnerability), or in the language interpreter, or some library that the software uses, or the operating system kernel, or something else. It might be that you upgrade the CPU and the hardware random number generater on the new CPU is worse than in the old CPU. It might be that you move your system from physical hardware you control to a virtual machine you rent, thereby violating security assumptions made by the software.
A system, or software, that is never updated stays still, and never gets better, while potential attackers learn more tricks and more ways to attack. Sooner or later they'll find a way to attack any stale systems.
And that is why updating is important for security.
Vulnerabilities don't "magically appear". They're there from the beginning and the goal of the game is to find them and fix them before the bad guys find them and exploit them.
If you use a software which isn't maintained, it's insecure not because of its vulnerabilities, but because of its environment, which is ready to attack the vulnerabilities. From a general point of view, it's not risky to use a software from 2005. It's just risky to use it in 2015.
Try installing a Flash version from 2005 and open a web browser with it in 2015. That's basically killing your computer, and yet we were all using this Flash version in 2005 without a problem (or almost).
TrueCrypt shut down because it was indeed the most secure encryption software ever made (and mostly used). Government forced creators to shut it down and agreement conditions remain unknown. Any vulnerabilities found and disclosed after then do not compromise the security of a fully encrypted drive or file when analyzed on another machine. In fact, if the software was indeed vulnerable then it would still remain active since it would be decryptable by governments agencies.
Note: This is MY opinion on this subject, I might be totally wrong.
But what is more probable? The number of known NSA backdoors is greater than zero, but is small compared to the number of known lazy or sloppy programming mistakes.
That said, the likelihood that a potential exploit will be used by the NSA is very close to if not exactly 100%. You don't have to inject a vulnerability into a system when there are more than enough unintentional holes already.
Does no one else find the "our audited software isn't secure, please switch to any of these (compromised) options" rather suspect? I figure it was a as direct a warning that the devs could give based on whatever was happening.
I'm very skeptical, but that was very, very weird, and not too far fetched in our world of gag orders.
Is there a stronger explanation for the erratic behavior?
If you want to use Truecrypt tech but something that is still updated, try VeraCrypt [1]. It uses the same codebase but has a number of fixes and improvements.
The chance of TrueCrypt suing anyone is near zero. They only stipulation they really gave anyone for using their code was to not use the same name, which VeraCrypt is satisfying (unlike the knuckleheads at truecrypt.ch).
Isn't that riskier than using a buggy but well audited code base? So far I've stuck to TC for the simple reason that without thorough audits I imagine it would be fairly easy for an attacker to compromise something like veracrypt.
> [...]TrueCrypt cannot actually properly protect data on a running system.
This I understand : as long as you store the encryption key in RAM somebody that can access your system can get it.
> If such protection is desired, one cannot get around solutions that use smartcards or other hardware-based key storage such that the encryption key can be better kept a secret.
26 comments
[ 3.6 ms ] story [ 66.8 ms ] threadWhat would be nice would be for these researchers to publish those fixes. And let the unofficial forks (like Veracrypt) to incorporate them.
Bruce Schneier for example is some one who's able to design actual ciphers and cryptographic systems, but I'm not sure if he can actually "build" them as far as software systems go. From what I know of him, his works, and from reading his books he's a traditional computer scientists and much less of a developer, and I'm really not sure if he's up to date with the current C++ language standards and compiler architectures or insert what ever language you want here, in fact I would bet my money on the fact that he isn't but he's more than capable enough to find the right people to do that work for him.
That said based on reading the audit report form the TC audit the findings are detailed enough so if you are capable of truly understanding them you should be capable of finding a way to resolve them, if not you shouldn't be developing cryptogrphic software in the first place.
I don't get this obsession with updates. If it's secure now for certain use cases then an update could only put that use case at risk. It's not like it can get "more secure" or something.
Can you clarify what you mean by this? What sort of vulnerability could magically appear in Truecrypt to make it less secure now than a decade ago?
That said considering the circumstances in which the "developer" of this software disappeared, how it was presented and the fact that it is not maintained anymore should make people think twice about using it.
An attacker knowing these flaws now has a smaller attack surface than a decade ago, since he now knows some weaknesses.
There's the magic.
First, nothing is ever totally secure. If a system gets audited today, the best the auditors can say is that to the best of their knowledge, the system has either no flaws, or list the vulnerabilities they know about. There might be vulnerabilities they missed. Some of the unknown ones might be blatant (say, a backdoor), or very subtle. When the unknown ones are found later on, and become public, the only way to not be vulnerable to those is to update.
Second, a system may become vulnerable later by the environment around it changing. This might be, for example, a change in the compiler (you rebuild for a new platform, and the kernel introduces a vulnerability), or in the language interpreter, or some library that the software uses, or the operating system kernel, or something else. It might be that you upgrade the CPU and the hardware random number generater on the new CPU is worse than in the old CPU. It might be that you move your system from physical hardware you control to a virtual machine you rent, thereby violating security assumptions made by the software.
A system, or software, that is never updated stays still, and never gets better, while potential attackers learn more tricks and more ways to attack. Sooner or later they'll find a way to attack any stale systems.
And that is why updating is important for security.
If you use a software which isn't maintained, it's insecure not because of its vulnerabilities, but because of its environment, which is ready to attack the vulnerabilities. From a general point of view, it's not risky to use a software from 2005. It's just risky to use it in 2015.
Try installing a Flash version from 2005 and open a web browser with it in 2015. That's basically killing your computer, and yet we were all using this Flash version in 2005 without a problem (or almost).
Note: This is MY opinion on this subject, I might be totally wrong.
Never attribute to maliciousness what can adequately be explained by laziness.
That said, the likelihood that a potential exploit will be used by the NSA is very close to if not exactly 100%. You don't have to inject a vulnerability into a system when there are more than enough unintentional holes already.
I'm very skeptical, but that was very, very weird, and not too far fetched in our world of gag orders.
Is there a stronger explanation for the erratic behavior?
[1] https://veracrypt.codeplex.com/
I seem to recall that part of the problem with doing a follow-up project based on TC's source was the license.
Has VeraCrypt addressed this successfully or did they just went along, assuming no one would come forward to sue them for license breach?
Does anyone have any more info on that?
This I understand : as long as you store the encryption key in RAM somebody that can access your system can get it.
> If such protection is desired, one cannot get around solutions that use smartcards or other hardware-based key storage such that the encryption key can be better kept a secret.
Can someone expands a bit on this please ?
Using a hardware based key makes digital attacks impossible AFAIK. Although it's still subject to physical attacks (eg: theft, coercion).
BTW, I'm surprised there is no mention of SSD and other flash drives, since IIRC that poses problems for FDE.