Performance of FullDisk Encryption DriveCryptor vs Truecrypt?

My assumption is that the FBI wouldn't have the option to not tell, or to stop the defendants from telling, that they had cracked TC if they were using evidence from cracked TC containers in public courts to convict criminals.

I'm sure the FBI and other law enforcement agencies have ceased numerous encrypted hard drives from dirty accountants, suspected pedophiles, etc. and would love to present the evidence contained within those drives to juries across the US if they could crack the encryption.

 

Yeah, my point exactly. Due to the nature of the legal system, it would be hard to keep this under wraps for very long.

If anyone can crack TC it would be NSA (and it's doubtful even they can). However, NSA's purpose is much different than FBI's (NSA is not law enforcement), and thus they would have a lot more of a reason to keep such capabilities quiet.

 

That was an excellent post, and thanks for posting the link.

 

The new version of disc cryptor 1.x has a obtimised serpant code that can process 50 mb/s on a atom 1.3GHz cpu.
TC can only get at best 20 MB/s with AES on the same machine.

 

yeah I serpant'd my netbook with drivecryptor.

Working fine. Haven't really noticed anything different except for the extended hibernation set/resume that you mentioned. Battery life and speed seems to be the same for stuff like watching videos, and net browsing, including the CPU intensive flash stuff.
Just wondering about disk or file system corruption. With TC you have the rescue disk you made, but how do you rescue the data from a drivecryptor'd drive if it became corrupt and no longer loaded?

What would the proceedure be?

I was thinking of maybe encrypting all my computers with this, but if PGP or TC can recover data or access to drive and this can't, then I"ll just keep this for low powered devices like netbooks.

 

What is "drivecryptor" ? Do you mean DriveCrypt or the free DiskCryptor ? In the latter case there is this page that explains how to create a rescue media.

 

thanks for that. Yeah Diskcryptor

 

This article is from 1998. Presumably, if the NSA was continuously intervening in the development of all encryption products, there would be (a) numerous such reports in the public domain and (b) more recent reports. Do we see either occurring?

Also, note the pledge provided by PGP on this subject...

 

What makes you think (especially in a post-911 world) that NSA would stop this behavior? I have no doubt in my mind they still do this. They are an organization with many thousands of employees and a $30 billion yearly budget (by most estimates -- the actual budget is secret). They have plenty of motive and resources to weaken non-NSA encryption systems. Besides, which is easier: Breaking crypto algorithms or planting backdoors? If I were NSA I would do the latter. It's obviously much easier to do.

I never said anything about PGP. They are one of the few (only?) proprietary encryption vendors that supply source code and I applaud them for it. Most vendors do not supply code, so using their products is akin to using a black box that you just have to blindly trust. This is especially true of hardware crypto (which seems to be a bigger target for NSA, especially those that export their hardware to foreign entities).

Now, let's assume PGP's source code was reviewed by a panel of top crypto experts and found to be clean. Even if this were true, there is no guarnatee it will work as expected (at least not on a Windows machine). Why? Because all it takes is a faulty RNG to compromise the entire system and we already know that the NSA has planted crypto backdoors in Windows (see _NSA_KEY).

If you can't break the algorithm and if you can't backdoor the source code itself, then another effective tactic is to compromise the RNG source. And since Windows is closed source, it would be exceedingly difficult to disassemble and decompile the source code to prove anything was amiss (though not impossible). I say "not impossible" because some crazy cryptologists have actually taken the time to do just this with Windows code. A couple of Israeli researchers decompiled and reverse-engineered the RNG code to Windows 2000 and discovered that it had SEVERE flaws -- flaws they said that were so blatant and easily avoided that either MS has extremely incompetent crypto people or they did it on purpose. (MS said they have since fixed the problem). I have read the entire research paper and you can tell by their comments that they're shocked at how such a flaw could find its way into the most widely used OS in the world. Keep in mind this attack was not some theoretical "look at use we're awesome and are going to get academic accolades for our totally impractical attack", but was a real practical attack. This attack could be used by an adversary to reveal all keys created with the RNG (all past and future keys -- a pretty horrendous flaw). Now since NSA has the source code to Windows, do you think they didn't discover this flaw independently? I would bet my house they did.

Now fast forward a few years past the above-mentioned Windows 2000ish RNG flaw. More recently another RNG was introduced, the Dual_EC_DRBG RNG (which is included in more modern versions of Windows -- but it is not the default RNG, just to be fair). This RNG is actually a NIST standard and was designed by the NSA. It was studied by a few crypto experts (Neils Ferguson among them) and they came to the conclusion that the elliptic curve constants used in the design were chosen by NSA and thus would make it extremely easy for them to hide a backdoor in the RNG itself. This would be almost impossible to prove by an outsider, but the potential for it is clearly there and would be simple for NSA to do. As you know, anyone who has control of the RNG has control over the entire crypto system and all encrypted data produced by it (no matter how strong the crypto software is).

The problem with crypto is there are so many moving (and extremely complex) parts that its hard to get right even when you are trying to get it right. You have RNG's, ciphers, hash functions, key strengthening mechanisms, padding, salts, etc. Therefore, it is extremely easy for an organization with NSA's technical expertise to compromise it. That's why having open-source code and an open discussion of the design (both before and after it is implemented) is so important. This is why I think all future algorithms and hashes should be selected by a process like the AES and SHA-3 competitions.

And this is why I am suspect of the SHA-1 and SHA-2 hash family design (they were designed solely by NSA). Sure, they might be perfectly secure, but with NSA's history it's just hard to trust them. This is why I am ready for the SHA-3 algorithm to be adopted, as all the candidates were designed by independent experts in the field.

So in closing, we have three major strikes against closed-source crypto:

1) _NSA_KEY
2) Windows 2000/XP RNG flaw
3) Dual_EC_DRBG included in all Windows versions (but not used by default)

All three of these flaws are in Windows itself, unfortunately. But the same problems could be there in any closed-source crypto.

 

I'm thinking of trying DiskCryptor v1.0.716.109 beta on my laptop with Mobile DualCore Intel Core 2 Duo T7100 1800 MHz (9 x 200) CPU. Is Serpent the recommended choice for non-atom laptops as well, or should I go with AES or Twofish?

 

A very interesting post, Chronomatic! A few observations to continue the conversation...

Why do you believe that the content of this single article is truthful and accurate? Reports that the FBI inserted a backdoor into OpenBSD, for example, have been shown to be a nothing more than a fabrication (see this thread). My point is simple: if the NSA were in fact forcing every major vendor of encryption software to include a backdoor, then those actions would be widely known by now.

You are assuming that PGP is using the RNG functionality implemented within Windows which, as far as I know, is not the case.

Additionally, note Bruce Schneier’s comments on this issue: “I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.” (see here)

 

Because the articles actually name names and give quotes from people who work for these companies -- Microsoft included. That and the original article came from CNN. Now, the MS spokesman did not admit "yeah we backdoor Windows" but he did say "whenever you develop something to do with crypto, you are always going to be working closely with NSA." One can take that comment two ways:

A) NSA is there to help make a secure product.
B) NSA is there to make sure the crypto isn't too strong.

I think B makes more sense. After all, Americans aren't the only people to use Windows and NSA wants to ensure they can read foreign communications. That's their job. It's what they spend billions doing. It's why they are the single largest employer of mathematicians in America. I don't mind NSA reading my stuff, but it's a slippery slope. Perhaps tomorrow other agencies will want this same access. And then later, LEA's will want it. And then the local police will be jealous and also want the ability to read all encrypted mail. Before long we have witch hunts. You get the idea. We have already seen this same scenario (of Police wanting the help of intelligence agencies) with the now defunct NAO. That was an office that would give cops access to spy satellite data. The idea was introduced by Bush but later killed by Congress, thank God.

Another issue is that introducing intentional flaws for intelligence agencies often comes with other problems which make the crypto susceptible to hackers and people in the private sector who exploit these holes. Intentionally weakening something is simply not a good idea because the "trap-door" never stays secret. Someone on the outside will be smart enough to find it eventually.

You might be right, I don't know the specifics. But I would be surprised if it didn't use CryptGenRandom() for the seed to its own PRNG. I know GnuPG on Linux and Windows uses OS sources of entropy. Truecrypt, I know, uses its own RNG, but it still pulls some of its entropy from OS sources. I suspect most crypto software is like that.

I admit we are speculating on the Dual_EC_DRBG backdoor, but the research showed that it would be easy to implement if NSA so desired. Perhaps NSA thought they could hide it in plain sight and no one would suspect such an obvious flaw. Perhaps they are just incompetent and designed a slow RNG that no one would ever use. But, as Bruce says, it makes no sense for them to push this thing as a NIST standard. It basically sucks. So either NSA sucks at designing RNG's or they had other motives.

 

Chronomatic, the hypothesis that the NSA is forcing every vendor of encryption software to include a backdoor may be subject to an empirical test. What if you created your own company and proceeded to develop and sell encryption solutions to the public? Do you believe that the NSA would promptly arrive at your doorstep and, using potentially nefarious techniques, compel you to insert a backdoor into the product? Do you honestly believe this to be true?

A third option, and perhaps the most plausible one, is that the NSA is rightfully serving in its authorized capacity to determine which cryptographic products may or may not be exported from the United States. Doesn't that interpretation seem the most likely?

Isn’t there a substantial difference between an encryption product that (a) uses an RNG embedded within Windows versus one that (b) pulls “some of its entropy from OS sources”? Is TrueCrypt less secure because it pulls “some of its entropy from OS sources”? It’s not at all clear to me that such is the case.

 

If it's for sale to foreign nations, then yes, I believe it. It has been admitted by various hardware and software crypto vendors. Now the export laws have been loosened a bit since the 90's, so whether they still do this, I don't know.

That is option B. They would not want the "crypto to be too strong" precisely because of export controls (which used to limit algorithms to 40 bit strength). The question is what else did NSA do to the product that wasn't exported?

Well, I am torn on TC itself. The developers make me uneasy. Their anonymity isn't that big a deal, but their refusal to publicly publish bugs and publish a changelog is highly suspicious. Any project that considers itself open-source does not hide bugs and refuse to publish changelogs. Truecrypt has no SVN/Git tree that is publicly accessible, that is their code is not collaborative -- only they can change it. And they do not accept patches from third parties. It's also difficult to get past versions of the source code which makes it difficult for people on the outside to keep track of changes in the code from one version to the next.

On just a perusal of their software, it looks very solid and well done (and it might be) but their coding practices and secrecy makes one suspicious. There is absolutely no reason for them to do the things they do if they are really wanting to be transparent and open.

As for their RNG, it is documented on their site. They use mouse movements as the primary source of entropy, but also pull entropy from OS sources to mix into the pool.

 

An interesting conversation continues...

To clarify, are you claiming that the NSA will force a company to insert a backdoor (or other weakness) into an encryption product, if that product might be used outside of the United States?

Again, this is an easily testable hypothesis: create your own company, produce an encryption product, sell (or freely distribute) it around the globe – and, wait to see if the NSA arrives at your doorstep, compelling you to insert a backdoor into the product.

I am extremely dubious that the NSA could widely engage in the practice of compelling a company to insert a backdoor into an encryption product and not have knowledge of that practice surface and circulate among the public. I strongly suspect that individuals like Phil Zimmermann, Bruce Schneier and others would expose such practices, even at the risk of personal harm to themselves.

There is a substantial difference between the NSA (a) inspecting an encryption product to authorize its export, a legitimate and proper activity; and (b) compelling a company to insert a backdoor or other weakness into the product.

I am not sure that your response addresses the question: “Is TrueCrypt less secure because it pulls ‘some of its entropy from OS sources’?”

P.S.: I enjoy reading your perspectives, Chronomatic. Even if I disagree, I often learn from your writings.

 

i'm about to look into diskcryptor as well, mostly because of truecrypt's non-transparency and claims that there are no externally produced matching binaries. does diskcryptor suffer from the same thing? i.e. even though the source is open, there is no information about how to build an exactly matching binary to verify that the original developer provided binary is actually the one produced from the available source code.

i also just posted a question on their forum how come there is no publicly available source control repository in this day and age.

feature wise i am digging diskcryptor's boot loader a *lot* better than truecrypt's.

 

DiskCryptor Compilation

Latest DC 1.0 beta source code is attached to this post: http://diskcryptor.net/forum/index.php?topic=1985.45#msg5848

AFAIK DC has only two developers, they can't spend too much time on an open source project.

 

mhm, thanks for Compilation wiki link, hadn't arrived there yet.

re developer resource, that's pretty much exactly why they should host their stuff on a proper collaboration site, make it as easy as possible for folks to contribute..

 

Contribute to what? The code? Who will review it?? Anyone is, of course, free to fork the project, after all DC is truly free(GPL Licensed).

If you want to translate or expand the wiki, I think you can do so by PM'ing the Admins(ntldr or gr2y).

 

I have an Intel Core2 Duo, T9300, 2.50Ghz and 2GB RAM. It's a HP Pavilion DV6000 Notebook.

Will TC slow down my Windows much using Truecrypt with those specs?

Will online gaming still be possible?

 

Umm, yeah. That's sorta what open-source projects are all about -- collaboration.

The people in charge of the project, which in this case would be the original developers.

 

And they are too busy to even get v1.0 out of beta...

 

thanks
but it's beta ,isn't ?
i discovered disk cryptor http://diskcryptor.net/wiki/Main_Page/en
only today

is amazing fast!
does FreeOTFE have a

like Diskcryptor ?


thanks

 

jesusjesus: What netbook are you using? I am running my Emachines netbook with a Intel Atom and 1Gb of ram with TrueCrypt FDE (AES-256BIT). My OS is Windows 7 Ultimate and I see no performance issues at all. My computer boots in less than 30 Seconds on a Fresh install. Right now it takes a good minute with all my realtime security but none-the-less I see no performance hit with TrueCrypt. DiskCrypt has the same result with AES; No performance difference. Do you have an older Netbook? Lower powered CPU? I ask out of curiosity as my friend has similar issues and AFAIK our netbooks are identical besides his being an Acer Aspire.

 

I think that they want to keep the public guessing! If you can steer people away from good products like TC etc., you will have a better chance at catching them doing something stupid. This is the most likely explanation. They like giving mixed messages, "yes its uncrackable", "no they can never crack it". People often forget that the psychological attack is a much better tactic than trying to "crack" software products.