Truecrypt versus built-in SSD encryption

lols , yeah ive actually admit ive first trained a couple weeks with random data before using TC on my actual important data , but once you get the touch for it its easy peasy , and dont forget to backup ...as usual xD

been running butter smooth ever since , and its been quite a while , and yes i still trust it over any hardware based "encryption"

 

Ah, I see. It's delicate because it's highly prone to user error. I had a look through the TC forum (who'd've thought to look there?? ) and see what you mean. Well, I don't do any system encryption and I don't do hidden volumes ... two sources of grief. I long ago disabled Windows asking to assign drive letters to the volumes so it doesn't want to format them.

Don't be an idiot, back up your headers!

Thanks to Dan on the Truecrypt forum for the reminder that I should backup my TC volume headers, something I did long ago but sheepishly admit I don't know if they're current. (Hmm ... Dan ... Dantz ... nah)

I think if used appropriately, there's nothing delicate about TC; it always comes back to the user. I was concerned you had meant there was something about using TC that made it inherently risky in terms of losing data.

Incidentally, I also came across this to answer my question about having two drives with the same passwords, asked just yesterday by someone on the TC forum. (Hunh, to think there might be answers on the product's support forum, who'd've thought? )

Is using 2 external disks *with same passwords* a bad idea?

And after some skimming of the TC forums on SSDs, it looks like many users have success with using TC even though it's not recommended in the manual. Something I don't understand yet about TC, though: when you format a volume it writes random data throughout the volume; my understanding of wear-levelling is that it uses unused locations on the SSD to actually store new data. So if TC has filled the volume with random data, how can any wear-levelling take place if there are no unused locations?

*sigh* I have more reading to do...

 

well using an ssd with TC isnt an issue if you do the first thing everyone should be doing before putting anything but a default fresh windows install on it if its your OS drive , that would be to encrypt it from the get go , then TRIM wont matter one bit since any temporary data stored in hidden sectors is gona be RAW format aka unreadable without the password wich is stored in the ram , second thing to do is if using windows then disable page file and setup a ram page file per ram drive , and change the passphrase once more when finished with the entire encryption process just to make sure, making sure theres no on disk page file active ,as well as hibernation and sleep disabled

 

Happy, We've been around the block before about this and I still can't believe you don't accept that hardware encryption is superior to software and it's just a fact it is the preferred route for those with the biggest secrets. Why put "encryption" in quotes?

I'll say exactly what I've said before. At the highest levels of the U.S. government, they use NSA Suite A with hardware encryption. I'm not going to second guess the NSA who hires the best and brightest from MIT, Stanford, CalTech, you name it. The best cryptographers/cryptanalysts in the world work at the NSA. That's a fact, Happy. And trust me, they don't use Truecrypt.

If I was putting together a new system, it would begin with a hardware encrypted SSD drive. These usually have to be ordered directly from the manufacturer, and they're not cheap, but it's serious security. I have the Integral brand drives with hardware encryption. The flash drives can be purchased through Amazon, but the SSD's are purchased directly from Integral. They are quality.
http://www.integralmemory.com/product/crypto-ssd-hardware-encrypted-sata-ii-25

Hardware encryption - in quotes.....really?

`

 

Yes, TrueCrypt is rock-solid if you don't screw it up, but for reasons that sometimes escape me, a lot of users can't seem to stop themselves. They seem to think that the presence of encrypted data can be ignored and they can just mess around with their systems as usual. Wrong!

Common screwups often involve:
disk repartitioning (which is NEVER a good idea in the presence of an encrypted partition),

reinstalling or upgrading the OS while an encrypted partition is present or connected,

deleting a container file by mistake,

formatting the wrong partition by mistake,

allowing Windows to format an encrypted partition or initialize an encrypted disk (which under certain conditions can occur even without prompting),

accidentally overwriting or otherwise losing the partition table,

forgetting their password (aha!),

changing keyboards or keyboard layouts and then discovering that their password doesn't work anymore,

failure to back up their headers,

failure to back up their data,

editing or deleting their keyfile (if used)

failure to back up their keyfile (if used),

failure to back up their keyfile path (if used) or even understand the difference between a keypath and a keyfile,

altering any files or folders in the keyfile path,

failure to back up their rescue disk (for system encryption only),

failure to recognize that encrypted data is more vulnerable than plaintext data, and finally,

behaving cluelessly. (Yes, "behaving cluelessly" in the presence of encrypted data is a good way to lose it.) Hey, I'm just getting started here! But that's all for now.

Yes, Dantz/Dan, amazing similarity, no? Well, yes.

 

Dan(tz), being the perfect Gentleman he is, left out a few :

1 : Failure to .. RTFM !
2 : Failure to .. KISS !!
(NO;
You do NOT 'need' 4 primary partitions, each containing 6 logical partitions !! )

And if you need to ask why you can't do this or that to/from a hidden TC-OS/Volume .. SEE '1' !!!


@ Dan(tz) :
Would you agree that the TC-manual is, in fact, one of the best manuals ever ?
I believe many of the problems You help TC-users with could be avoided if the manual was organized otherwise .. Like : Don't talk about 'Hidden OS'
until you have teached the children what a 'volume' even is ?

 

But here's the quandary for us mere mortals:

1. NSA has provenly backdoor'd hardware encryption in the past.

2. We do not work at, nor have access to the exact hardware that NSA buys/uses...so as to know that a flaw or backdoor doesn't exist.

3. TrueCrypt is provenly secure against US FBI level attacks. (Unless you think the whole Dantas thing was a disinfo campaign).

I'm right there with you: Come to me with a stolen hard drive out of an NSA laptop, and I'll use it in a heart beat Other than that, maybe I'd use TC on the hardware encrypted drive in addition...but I'd really be paranoid that the drive itself was logging keys or something.

PD

 

Even if it were to be proven that NSA uses only hardware encryption, (a claim that is currently supported by a 'foundation' consisting solely of "trust me" -- which proves nothing and is trusted nowhere in the world of logic); but even if this were proven, there would still remain the critical question of whether hardware encryption was chosen because of encryption strength. Given that hardware encryption's touted benefits are in large part found in benefits to large entities, one would suspect that such benefits would have a role in the final encryption choice.

Then there's the "benefit" of hardware encryption that the encrypted data is destroyed by a few wrong password entries. Hello. What a lovely way to lose all of a user's data. So TrueCrypt is fragile compared to this self-destructing data bomb? Sorry, I'm not buying it.

And again, what happens if the tpm, or the motherboard containing the tpm goes bad? All data lost. Kaput. Unless one has an available backup of the tpm data. Another creative new way for everything to go wrong.

At this point I'll take TrueCrypt or DiskCryptor. Thank you very much.

__

 

I've had more than my share of end-users who "never did anything" or "followed the instructions, but...".

You make a convincing case for hardware based encryption on all hard drives if only for the simplicity for the masses, despite potential backdoor issues/suspicions.

Otherwise, anyone who wants a bit more than basic level of protection is required to pass through the learning curve to have the technical expertise (that is in abundance here in these forums) to be able to implement it effectively/safely via software.

Rather than view the users as just plain stupid (how many of us RTFM on everything we use in our daily lives...to extend that logic, who reads all the details in any privacy statement or terms of use, credit card small print, etc), I'd suggest that the marketplace has a gap that needs filling to make these various options more "foolproof".

Until then, people will continue to mess themselves up whether it is stupidity, ignorance, accident, poor practices, or a combination thereof.

 

I'm confused. I honestly didn't "get" what you are writing here on several things.

1.) The NSA uses hardware encryption with their own algorithms and their own hardware chip controllers. It's not a matter of anybody "claiming" this.

2.) A 'foundation' ? What 'foundation' are you talking about that "claims" NSA uses hardware-based encryption? (it's true, but I'm lost on your point.)

3.) A question as to whether the NSA "chose" hardware encryption based on 'encryption strength'? It has nothing to do with encryption strength. The only thing controversial is that they use Suite A algorithms which are proprietary to the NSA. But, I am one who accepts they know what they're doing. It's not a matter of proving anything, it's been fairly common knowledge that that's what they use. It's a matter of combining Suite A with what they call 'types'...I am digressing. But I don't understand what you're saying.

4.) TPM? That's the TCG's controller on motherboards that are used in a lot of laptops in order, frankly, to use Windows BitLocker. These days, most all hardware-based encryption is designed with its own tiny microchip controller handling ALL of the processing on the hardware (the chip) and doesn't use TPM at all.

5. The benefit of hardware-based encryption which allows for an x-number wipe of the device based on number of incorrect entries is a solid feature. Could someone be dumb enough to forget things and it get wiped? Well, yeah. And? You use your debit card and put in the wrong pin X number of times and the bank closes access to your account. Just like any other data, encrypted or otherwise -- you back it up! -- and/or take the security seriously.

6.) A motherboard going bad is not going to touch your encrypted data protected by a crypto processing controller sealed in the drive. Could IT go bad? Well, I suppose, just as anything else in this world is not 100% perfect. Your same argument could be made for software encryption, the computers in automobiles, a jet aircraft, yes, there's a chance anything can happen.

But honestly, I didn't really understand a lot of what you wrote because of your misunderstanding oh how it works and simply wasn't relevant to the comparison.

 

If you don't RTFM.. YOU ARE STUPID !!
Not reading the ~ Snipped as per TOS ~ manual is just plain NOOB-behaviour
and there is NO EXCUSE for refusing to learn !

 

Re LockBox's honest confusion:

Do you have anything other than your own assertion to back up your claims set forth in "1.)"? If not it's just a claim; nothing more.

You can look up the meaning of the word "foundation". It's not complicated.

You didn't clarify what you don't understand in #3. I don't understand what it is you don't understand. Your assertion that NSA relies solely on hardware encryption means nothing. If this knowledge is so common then you should be able to establish your assertion with lots and lots of data. Let's see the convincing data.

Even if NSA did choose hardware encryption (which you have not established) then that choice could have been made for a variety of reasons. NSA's hypothetical choice, alone, would neither establish nor imply that hardware encryption is superior to software encryption, particularly with respect to non-enterprise users. Sorry if you cannot understand this.

As to number 5, self destruction of encrypted data poses a risk to the data. Quite simple. TrueCrypt and other software encryption carry different risks. Nevertheless self destruction of data after a few wrong password entries poses a major danger not present in TrueCrypt and most other software encryption. Nothing complicated here. Compare and contrast. Its a big danger that hardware encryption does have and TC does not have.

Some SSDs require TPM for hardware encryption. The TPM in turn is typically soldered to the motherboard. TPM will be non-functional if motherboard non-functional. Hence loss of TPM functionality or motherboard functionality means data cannot be decrypted unless backup of TPM data available. Nothing complicated here.

__

 

not much more to say +1, same for above post

 

Clever way of trying to turn things around. I hate this....no reason for it.

As per #1 - do your own research.

I wasn't asking what a foundation was (of course, you know that). I asked what you were talking about. As in, what 'foundation' are you talking about? What does it have to do with anything? I've researched it and am, again, confused.

I can understand perfectly well what you're trying to say - but it's non-nonsensical and not based on reality. BTW, I don't expect for everyone to do things as the NSA would, I simply contend that the methods they use are certainly worth considering.

Yes, data loss is not complicated. There are a number of ways to lose data - encrypted or not. What's the point? You said self-destruct only means another way to lose data. I say the feature of self-destruct in hardware-based encryption is solid. To say it's not because you could lose data is like saying you shouldn't drive a car because you might have a wreck. No, TC doesn't have self-destruct because it makes no sense in software encryption. But with that logic, I shouldn't use TC because I might end up with a mangled header (something that can't happen with hardware processors). The answer? Back it up! Same as with hardware-based encryption. You use wise best practices and caution. Know what you're doing.

The confusion per TPM was you obviously thought all hardware-based encryption needed the TPM chip. That was obvious. I said it was just more confusion, because most dedicated devices using hardware encryption don't use TPM.

Why is it so hard to say, "Thanks for clearing those things up?" I don't mean to be rude, but you're misinformation; and then acting like I was somehow not "getting it" is a bit tacky.

 

EDIT

@LockBox,

Please accept my apology for my prior comments. Please also accept my thanks for your numerous contributions, many of which have benefited me personally.

Thanks.

 

Play nice guys, we don't want this fairly illuminating thread shut down. However, from your "disagreements", I must say I've learned quite a lot.

Both TC and hardware encryption will have their sources of failure (from a user's perspective); it's a matter of choosing which ones you'd like to deal with. I for one am glad TC doesn't wipe my data on multiple password failures. Given the length and complexity of my passwords and the aging gracelessness of my fingers (especially when cold), I frequently get the password wrong. 3 tries like an ATM? On bad mornings I sometimes need 10 (at least it feels that way).

I agree, but then from the reading I've done I'm not sure if consumer-level hardware based encryption is ready for the masses. It sounds like in some cases it's not implemented properly or particular laptops don't support it. There's also a small learning curve here in that you have to mess with the bios to set the password(s). As PaulyDefran said,

I would trust industrial-level hardware-based encryption; consumer-level I'm not so sure; but I'm not going to spend the $$ on an industrial-grade 512GB SSD. By "trust" I refer to trusting it to work flawlessly, not trusting that there are no back doors.

TC is no different than any other system software available on Windows; there are a whole number of programs where users can lose their data by misuse (look at imaging software) and/or not reading (or understanding) the manual. My dad has used TC for years and he hasn't run into any issues; of course, he doesn't do any of the configuration but then he doesn't have to -- he can just type in his password and gain access to his files. Too many users feel qualified to take care of the technical details of their computer after skimming through a couple "how to" tutorials; how many of them are their own auto mechanics I wonder.

 

Well, people need to get the message !
Can you imagine how frustrating it is to have to help people,
over and over again, with problems that they caused themselves,
often because of failure to read the ~ Snipped as per TOS ~ manual ?

We actually feel with these people,
it's not funny to loose all your photos,love-letters or whatever it is ..

 

Back on topic.

There is yet another issue relating to hardware/software SSD encryption to explore: the issue of how the encryption processes being considered mesh with SSD drives, in general, and with TRIM processes employed by the SSD. This issue, in turn, has at least two parts: (i) impact on plausible deniability; and (ii) impact on hard drive speed.

I don't use an SSD, so I haven't researched the issues sufficiently to have reached any conclusions. Instead, I simply know the issues do exist and could be significant.

The first TRIM issue, as I understand it, is present when using TrueCrypt (and possibly other software encryption and/or hardware encryption) to accomplish system encryption. Apparently, in the case of system encryption, TrueCrypt doesn't interfere with TRIM operations, leading to the result that the SSD periodically releases unused hard drive memory components to the system, thereby generating data in otherwise encrypted portions of the drive, in the form of unencrypted zeroes, leading to the possible result that an adversary would be tipped off that user's system is encrypted. (See the discussion of "Trim Operation" in the official TrueCrypt documentation.) This does not cause any leakage of encrypted data as I understand it.

Please note happyyarou666's specific TRIM issue suggestions earlier in this thread. Those suggestions might completely eliminate this first TRIM issue; I simply don't know.

The second TRIM issue, again as I understand it, has to do with SSD performance. Here's one on-topic link from April 2010, that highlights the potential issue. Software and/or SSD improvements since then may have changed the overall landscape of the issue considerably, or not. I don't know.

I do know that DiskCryptor was completely revised earlier this year and that a completely new version 1.0.757.115 was released. The new version incorporates specific SSD optimizations and TRIM support options that were introduced in prior versions of DiskCryptor. I don't know how the SSD and TRIM support options impact SSD performance as compared to TrueCrypt and/or hardware encryption; and/or whether same is highly dependent on SSD make, model, and specific use thereof.

Just wanted to note that before making a final decision on SSD encryption, it could be beneficial to research and/or conduct tests to find out outcome of these issues. Perhaps someone here can shed further light on these questions.

__

 

Not sure if you meant this as a personal attack with the word "you" instead of "one". I'll assume not...not looking for an argument here.

Look, from what I get from one of Dantz' major points, unless I misread it, is that hardware encrypted drives is superior to software because we cannot expect all users who want encryption to invest the time to get the level of education / knowledge to be competent in it. Products like TC are really not for the average joe. Hence the term "delicate" he used earlier.

My examples raised earlier were just to point out that there are many things in MOST people's life that they don't / cannot / don't have the background to get into the meticulous and sometimes complex details about (btw, I actually meant EULA vs TOS, as they are more representative of hidden gotchas deliberately inserted). As another, how many people have disputes with insurance companies on what thought they are owed...RTFP...read the fine print (and understand it and all its implications) - even then there is room for interpretation.

I simply think that the loads of reports of people having these problems is more reflective of a gap in the market (they maybe are looking for something more or are attracted to products like TC because it is "free", but they underestimate the task/complexity) rather than classify all cases being due to "stupidity", or implying some sort of laziness.

As mentioned, I've had my share of user support, so know the frustration one can have...maybe we all come here to commiserate!

 

I do agree that it would have to depend on how / how well it is designed and implemented...auto erase after a few password attempts would be scary.

Your last point, eloquently said, is where the crux of the issue is.

I think people are in the past few years starting to come to grips with the whole circle of related issues in our digital age...privacy, security, reliability/redundancy. They have largely been perceived as stand alone issues for consumers but as more of their "stuff" goes digital they will increasingly risk being severely harmed by a loss of that, and that risk is coming from several angles. There is too much for the average joe to have to think about / do right now to be fully covered. We can forget expecting them all to take on TC competently, with proper backups and all.

 

Wow. Thanks for that, SB. Really. Apologies here too.

 

First of all, TrueCrypt is not really recognized as "OpenSource" (especially if you're going to use capital letters like that).

Wikipedia:

"The TrueCrypt License has not been officially approved by the Open Source Initiative and is not considered "free" by several major Linux distributions..."​

And while the license has been updated, and some have said these updates fix the problems cited by developers in the past, the above statement still holds true.

Second, as dantz mentioned, simply having the source available does not mean there is no backdoor. What he said is true, some code could be written in a very sneaky way so as to avoid detection...but with enough eyes on it, things like that wouldn't stay hidden for long (particularly for a security-related program). The more obvious issue is that without extremely difficulte, time-intensive, and costly reverse engineering, you have no way to prove the binaries available on the site are actually compiled from the source code that is published (i.e. that the program you download and install doesn't have different code in it). Obviously the only way to avoid this issue is by compiling the published source code yourself.

As for "a backdoor or its equivalent" possibly existing the OS that it runs on, that would be an argument in favor of using an open-source OS (or even better, a secure operating environment from a Live CD running something like Ubuntu Privacy Remix). And as for a "backdoor" in the hardware that the OS runs on, I'm not so sure about that. It would depend on what hardware we're talking about. If we're talking about a keylogger built in to the keyboard, that seems like a stretch, and there are still ways around it. If we're talking about things like BIOS, there's ways to avoid leaving useful info there too.

Most of these supposed pitfalls are avoided by simply following good security protocol, and what Schneier calls "practicing good hygiene".

And not to mention, virtually none of that sort of stuff even matters if we're just talking about data-at-rest. My OS doesn't really matter if we're simply talking about making sure no one can read the data on my USB thumbdrive I dropped on the bus.

So what? It's all just a matter of math. As long as you use a good cipher with proper implementation and a strong passphrase, they can try 350 billion guesses per second, and it would still take them tens of thousands of years to brute-force the encryption.

A fun little tool (and by tool, I mean an Excel spreadsheet with formulas included) can be found here. Look for the link at the bottom "BruteForce Attack Time Estimator".

As the instructions mention though (be sure to read those), you need to be careful when using a calculator like this. Password-guessing software can be programmed to run through common and likely passwords first...cutting the guessing time down to virtually zero for the vast majority of passwords. This is where actual randomness comes into play. (If you want a good estimate of just how strong your password is, this entropy tool is the best I've seen. Definitely read the "introduction" link.)

 

Easy for you to say. How convenient you live in a country where telling a horrible truth about something your "dear leader" did to a child, isn't illegal. But some people have a belief in this silly little thing called "justice", and sometimes instituting justice and revealing truth that needs to be more widely known involves possessing dangerous and sometimes, yes, illegal material. But for some people, doing the right thing is worth the risk. I suppose for you, "ignorance is bliss", "it's not my problem", "long as it doesn't happen to me", and all that jazz, eh?

The fact is encryption plays a very important role in a world filled with bad guys. Pessimists (I would argue, idiots) try to argue that it gives those bad guys a way to operate in secret. Sure, maybe. Just like telescopes give bad guys a way to scope out a target from far away, and cars give them a way to flee the scene of a crime. But that's not an argument to outlaw or put restrictions on the use of any of those things.

I'm a lot more afraid of what different kinds of bad guys would do to those who would expose them, if these whistleblowers didn't have a way to maintain some kind of secrecy.

Just because you have a desire to hide some information, it doesn't mean you're doing something wrong. And it certainly doesn't mean you're the bad guy.

And what's more, as others touched on, you have no idea what will be used against you...

Plenty to hide

How the NSA Will Use Your Emails and Phone Calls Against You

 

As to the OP, I find it interesting it took so long for anyone to mention the risk that comes with hardware encryption...not only in the potential for a backdoor (which you have virtually no way to preclude), but also the potential for lost data.

Considering how virtually all hardware encryption works, if some piece of the hardware fails, you're going to have a heck of a time trying to recover what you've stored on it.

(Interesting piece on this)

Sure, with no moving parts, SSDs have less opportunity for failure...but that doesn't mean it can't happen. And obviously, if we're talking about hardeware vs. software encryption, a backup of your data would mean ANOTHER physical hard drive. That could get pretty costly, pretty fast.

Let's put it this way:

I might trust hardware-based encryption to stop my kid sister from reading my files, but I wouldn't trust it to stop major governments from reading my files. And I certainly wouldn't trust it with important data, without having a backup somewhere else.

And obviously, a backup of sensitive/important data is most easily implemented with software encryption. It simply gives you a lot more options. (e.g. It's a heck of a lot easier (and I would argue more secure in terms of preventing data loss) to encrypt the data through software and upload it to a cloud storage server.)

 

I like your analogy, very useful...don't mind if I borrow that some time?