According to the Truecrypt Web site http://truecrypt.sourceforge.net/
Truecrypt is no longer supported or recommended. Is this also true with Realcrypt?
If so, what (if any) is the replacement? I DEPEND on this program to access my data
using both encrypted containers and full disk encryption.
On Thu, 29 May 2014 15:36:01 +0000, dragonbite wrote:
> Yeah, the version they are providing now only decrypts, and does not
> encrypt articles say.
In addition, there’s a suggestion floating around that the 7.2
“decryption-only” version may be compromised as well.
Until we have news from someone with actual knowledge of the situation, I
would advise (a) not panicing, and (b) wait until more information is
available.
What I read about this yesterday included a comment from one of the
people involved in the code/security audit, who said that he hasn’t been
able to reach the developers (whom he apparently knows) to find out
what’s going on. He said that the version used in the review - 7.1a -
had a few minor issues they found, but nothing critical or particularly
earthshattering. They were going to make some sort of announcement about
the audit this week, but he said this wasn’t what was planned, to his
knowledge.
Although commercial solutions to crack TrueCrypt almost immediately(claim within 30 min) by dumping a copy of existing memory when a TrueCrypt encrypted partition is mounted and simply locating the keys as identifiable strings have been around for a few years now, the problem has gained new visibility recently.
The current recommendation is to implement something like LUKS instead.
If this is something caused by the NSA or some such agency, they may also be under some “gag order” like restraint and are not free to talk about any of the dealings at this point.
It may also be a form of protest, if they are not allowed to talk about it. It has brought up speculation and is getting people talking & thinking about security and privacy a bit more.
Skimming your link, it looks to me like just a lot of uninformed speculation and imagination gone wild.
As I described, there is a fundamental flaw to <all> (yes, the whole family) of encryption solutions that function like Truecrypt, and that includes Microsoft’s much-bally-hooed Bitlocker… The approach is just fundamentally flawed as of today.
You can look it up, Passware and Elcomsoft released tools in 2012 that capitalize on fundamentally how things work by parsing out the unencrypted keys in memory whenever the partition or disk is mounted. It’s so fundamental to how machines work, it’s doubtful there can be a solution any time soon.
The commercial tools are themselves just optimized versions of open source tools which have been widely available for decades. It just took someone to figure out the vulnerability and now there is no answer.
Bottom line, don’t use Truecrypt if you really don’t want someone to access your data. It’s broken. Don’t use an old version which is what some people are saying, that’s totally ignoring the problem that Truecrypt can’t guarantee your data is protected.
I only expect disk encryption (I’m using LUKS), to protect me if my laptop is stolen while powered off, and to protect me when the hard drive eventually fails and is tossed into the recycling bin.
> Although commercial solutions to crack TrueCrypt almost
> immediately(claim within 30 min) by dumping a copy of existing memory
> when a TrueCrypt encrypted partition is mounted and simply locating the
> keys as identifiable strings have been around for a few years now, the
> problem has gained new visibility recently.
Arguably, you don’t even need a memory dump. There are ways to brute-
force attack the header as well (though arguably a memory dump is
cleaner, since the mounted volume’s keys are already exposed).
On Fri, 30 May 2014 00:36:01 +0000, nrickert wrote:
> I don’t see this as a problem.
>
> I only expect disk encryption (I’m using LUKS), to protect me if my
> laptop is stolen while powered off, and to protect me when the hard
> drive eventually fails and is tossed into the recycling bin.
That’s pretty much why I use TrueCrypt myself. I’ve had a couple drives
fail with sensitive data on them, and ended up having to pay to have them
ground into dust.
Whether you decide to continue to use Truecrypt or not, you should at least consider other options particularly LUKS instead when it’s equally if not easier to setup and does not have the security issues Truecrypt does.
If a person is setting up for the first time, typically I’d recommend just starting with the “better” solution unless and until those issues are addressed.
> Whether you decide to continue to use Truecrypt or not, you should at
> least consider other options particularly LUKS instead when it’s equally
> if not easier to setup and does not have the security issues Truecrypt
> does.
But when you’ve got a 2 TB and 4 TB drive with full encryption, moving
off Truecrypt is a non-trivial issue.
A Steve Gibson opinion that TC is “safe to use” without including any technical opinion.
(Those who have been around long enough know that despite all the good SG has done, he will always be shadowed by his earliest efforts which have no real relevance today)
It may well be that many will feel that TC is fine as it is. There is no doubt that the issues I have read about require special access and sometimes special circumstances, but at the moment there are also substantial concerns, and IMO this is because of what TC is supposed to protect against which is a very high bar… A hacker with physical access/possession. Then, you have to consider the march of technological advances, what existed years ago when the solution was designed, what exists today and what will exist in the near and intermediate future since we never want to implement something that will be worthless next week or next year… maybe even 2-5 years from now.
Take a look at the openSSL issue. When SSL first became a standard, authentication wasn’t part of the spec. Later, it was added but only as an <option>. As time went on, various people “got the word” and implemented authentication, but since it has always not be a requirement, it left the door open for someone to overlook and apparently the openSSL project overlooked. Even now, the SSL auth spec still is typically implemented one way. One day, maybe that will also become obsolete and 2-way auth will become more than a recommendation and general practice will require 2-way auth.
Time marches on, and therefor requirements if not absolute become recognized to be practical necessities.
I doubt the original TC developers would be willing to discuss publicly any really, deep concerns they might have… That would put a real nail in the coffin of TC and would even be irresponsible causing a zero-day vulnerability issue If such doesn’t exist, then so much the better but it’s better to just not touch the topic altogether.
But, everyone has been warned as much as they can be…
If you <really> want better protection, don’t use TC unless you have good reason to.