Which encryption program for SSD?

zazzn said:
I choose the lessor of the two evils, in this case the government. If i'm doing something illegal, then yes I should go to jail and be caught. 3rd party auditors are much more supportable to bribery than government agents.

In computer security there is nothing you can trust 100%, you opinion is the government is out to get you... If you are a criminal they should be.

BTW, Please prove the government malice due to Full Disk Encryption failures. (Good luck finding that)
Click to expand...
See the link I posted: http://www.pcworld.com/article/2454...-weak-crypto-standard-nist-advisers-find.html (which is just a random Google hit btw)

The controversy around https://en.wikipedia.org/wiki/Dual_EC_DRBG was not a small one.

By government malice I meant that they are actively weakening crypto standards, let alone what they mandate to corporations that they do in their closet. At this point you have to assume that every closed source cryptosystem by a US company is outfitted with mandatory backdoors.[1] The evidence is clear.

As for security though obscurity, your right in the security field it's generally not accepted. Especially if it's your ONLY protection, in this case it's not. It's an extra layer to help protect the total security of the software.
Click to expand...
This is plain wrong. If you obscure the code itself, you _have_ no secure layer that you're adding an obscure layer to. The obscure layer becomes the only one. This is the most basic crypto knowledge there is.

What proof to your claim that hardware encryption questionable? Can you prove it?
Click to expand...
See above.

If the only claim is that it's not FIPS validated then?
Click to expand...
At this point in history, any government certification should be a reason to look at the code even closer, not to trust a complete lack of code visibility more.

Is it that you do not trust AES256?
Click to expand...
The most critical part is not using a certain algorithm, it's using it _correctly_. Most trouble comes from botched _implementations_, not from using completely self-rolled crypto algorithms, which would be even more negligent.

Even your worshiped solution truecrypt uses defacto encryption standards such as AES256. So I don't see why you believe truecrypt is any better than hardware encryption.
Click to expand...
Implementation and key management is crucial. Slapping on a "uses AES256" sticker doesn't magically make it secure. You have to get the implementation right.

Unless of course you are saying virtually every tech company is malicious. As the OPAL standard for hardware encryption is supported by all these the TCG members.
Click to expand...
The point is, you cannot know.

Of course, use whatever fits your threat model. But to correctly assess that, you need correct information and not FUD and "trust the government" hogwash. If someone is interested in using crypto, it's best they err on the side of caution.

Edit:

[1] Not in the sense that the product phones home or is accessible from the outside, but mainly that it uses weak/not-random/predetermined/... keys.
 
Last edited:
zazzn said:
Even your worshiped solution truecrypt uses defacto encryption standards such as AES256. So I don't see why you believe truecrypt is any better than hardware encryption.
Click to expand...

Because we can check its implementation.

Software full disk encryption encryption always has to have the encryption key in system memory after authentication. It's susceptible to attack though many various methods (resume from sleep, if the machine is left on but locked at OS ect)
https://en.wikipedia.org/wiki/Cold_boot_attack
In the case of hardware encryption, none of the encryption keys leave the physical hard disk making it much more secure and does not need the keys to be stored in memory.
Click to expand...

None of that makes it any better if the computer is on as all your files are then accessible anyway. Other than cold boot attack which has an extremely limited application, I have yet to see the security benefit of HW encryption.

99% of users will not do any code review even if it was available, so it's irrelevant IMO, but this is a fight that will go far beyond me and you for security transparency.
Click to expand...

1% is still worlds bigger than 0%.

Code quality on open/closed isn't really the issue, it's freeware / paid. I view paid software as better quality because it will be maintained regularly, generally with the health of the company as the motive.
Click to expand...

H..ha....hahaha! Sorry, but really?

So bottom line is pick your poison, and in my case, I recommend the solution best meets your needs.

Hardware encryption
-No slowdown / bottle necks
-no compatibility issues with OS's
-no filter drivers
-multi boot options
-no wait time for encryption
Click to expand...

-questionable security
 
Meeho said:
None of that makes it any better if the computer is on as all your files are then accessible anyway. Other than cold boot attack which has an extremely limited application, I have yet to see the security benefit of HW encryption.
Click to expand...

Security benefit, none. Assuming proper implementations HW/SW doesn't make much a difference from a security standpoint.

HW FDE is great because its transparent to the OS, it also makes ATA Secure Erase a fast and very secure (just regen the hw key). It's also pretty fast, as the cypto is done in hardware, most drives that support HW FDE are actually always doing FDE even if you don't 'secure' it, they just use a default password until you change it.

The major con of HW FDE as a crypto system (and ATA Secure Erase as well) is you have to trust the manufacturer to implement/use correct crypto primitives (such as AES256) and (this is the important part) actually use them correctly to create a secure crytpo system.

There are so many ways to screw up putting together a crypto system even when using correct crypto primitives that it is difficult to blindly trust OEMs to do it correctly (setting aside malice) without allowing verification. There was a study that was looking at Secure Erase implemented in various SSDs that found one model that reported erase success but didn't actually do anything, data was still intact on the drive and filesystems were still mountable.
 
TCM2 said:
So what? The source was available and proven to match the binaries. The crypto was audited. How would you even begin to audit BitLocker?
Click to expand...

And the professional auditors missed the recent vulnerability to truecrypt.

https://threatpost.com/veracrypt-patched-against-two-critical-truecrypt-flaws/114833/

So while truecrypt might have the benefit of OSS, it's also a project that was run by probably a handful of devs at most. Microsoft has thousands of devs & billions to spend. Obviously given the number of windows updates, it's not always great quality.

And FYI, large enterprises can sign NDA's and audit windows code.
http://www.microsoft.com/en-us/sharedsource/enterprise-source-licensing-program.aspx
 
dave99 said:
And the professional auditors missed the recent vulnerability to truecrypt.

c/

So while truecrypt might have the benefit of OSS, it's also a project that was run by probably a handful of devs at most. Microsoft has thousands of devs & billions to spend. Obviously given the number of windows updates, it's not always great quality.

And FYI, large enterprises can sign NDA's and audit windows code.
http://www.microsoft.com/en-us/sharedsource/enterprise-source-licensing-program.aspx
Click to expand...

In fairness the audit team wouldn't have been looking for code injection exploits, and assuming they were, they would have been only concerned with the components in the crypto system itself. The vulnerability isn't a cryptographic weakness.

Regarding MS code auditing, without knowing who, if anyone, has actually taken them up on that offer and what resources they put toward the audit and what components of the system they audited we can't really make useful statements about it. Also assuming someone found something, did they tell MS about it or silently decide to use a different vendor. The NDA makes it all pretty useless as detailed statements can't be made about anything regarding the process.
 
TCM2 said:
See the link I posted: http://www.pcworld.com/article/2454...-weak-crypto-standard-nist-advisers-find.html (which is just a random Google hit btw)

The controversy around https://en.wikipedia.org/wiki/Dual_EC_DRBG was not a small one.

By government malice I meant that they are actively weakening crypto standards, let alone what they mandate to corporations that they do in their closet. At this point you have to assume that every closed source cryptosystem by a US company is outfitted with mandatory backdoors.[1] The evidence is clear.

This is plain wrong. If you obscure the code itself, you _have_ no secure layer that you're adding an obscure layer to. The obscure layer becomes the only one. This is the most basic crypto knowledge there is.

See above.

At this point in history, any government certification should be a reason to look at the code even closer, not to trust a complete lack of code visibility more.

The most critical part is not using a certain algorithm, it's using it _correctly_. Most trouble comes from botched _implementations_, not from using completely self-rolled crypto algorithms, which would be even more negligent.

Implementation and key management is crucial. Slapping on a "uses AES256" sticker doesn't magically make it secure. You have to get the implementation right.

The point is, you cannot know.

Of course, use whatever fits your threat model. But to correctly assess that, you need correct information and not FUD and "trust the government" hogwash. If someone is interested in using crypto, it's best they err on the side of caution.

Edit:

[1] Not in the sense that the product phones home or is accessible from the outside, but mainly that it uses weak/not-random/predetermined/... keys.
Click to expand...

Your points while certainly valid, mean nothing because there are no other solutions out there for you to use. Truecrypt uses the same implementation so I don't see what you are fighting here.

Again, you are trying to make out like he's looking for a solution that is 100% which is NEVER going to happen. If you are looking for an industry best that's AES256, with FIPS validation. If you are trying to hide from US government / Allies, then you need to write your own software/crypto and hide under a tinfoil hat.

I've already stated there are FIPS validated HW implementations for hardware encryption, and JUST like software encryption you have to worry about the implementation, which is why FIPS is even there in the first place. For the common man/company in USA you are looking for FIPS validation at least. If FIPS validation is not trustworthy to you, then there is no solution on the market for you really without a custom solution.

As a previous poster said, yes, you can sign NDA's and many companies will give you access to the code for review, at my company we have had to do this several times.

Meeho said:
H..ha....hahaha! Sorry, but really?
Click to expand...

Really, I have bills to pay... Just like you do.
 
Truecrypt uses the same implementation so I don't see what you are fighting here.
Click to expand...
I'm baffled by the argument. AES is an encryption algorithm. A cryptosystem consists of more than an encyption algorithm. You have to deal with random number generation, key management, maybe key derivation from a password, all that sort of stuff. That's what is generally meant by the implementation of a cryptosystem. As I said, just because it has an AES256 sticker doesn't make it secure.

And then you still haven't covered malice and government coercion. When the government isn't actively trying to sabotage your algorithms, who says that the certification of your device in hand is even matching the code that runs in it?

If you can't look, you can't know. There is no way around that.

If you want to cover your ass and be able to point fingers, without any care about whether the data is actually secure, you use "certified" systems.

If you want your data to be secure, you use open source and pay for an audit or two if you're a company.
 
zazzn said:
Your points while certainly valid, mean nothing because there are no other solutions out there for you to use. Truecrypt uses the same implementation so I don't see what you are fighting here.

Again, you are trying to make out like he's looking for a solution that is 100% which is NEVER going to happen. If you are looking for an industry best that's AES256, with FIPS validation. If you are trying to hide from US government / Allies, then you need to write your own software/crypto and hide under a tinfoil hat.

I've already stated there are FIPS validated HW implementations for hardware encryption, and JUST like software encryption you have to worry about the implementation, which is why FIPS is even there in the first place. For the common man/company in USA you are looking for FIPS validation at least. If FIPS validation is not trustworthy to you, then there is no solution on the market for you really without a custom solution.

As a previous poster said, yes, you can sign NDA's and many companies will give you access to the code for review, at my company we have had to do this several times.



Really, I have bills to pay... Just like you do.
Click to expand...

FIPS covers implementation of crypto primitives, but how those primitives are used is just as important as choosing them. I can use a FIPS compliant implementation of an AES256 cipher in my crypto system, but if I use the same key for every ciphertext I've created a horribly broken crypto system. It's also these kinds of flaws that have been at the core of major SSL/TLS bugs like BEAST. The TLS spec defining the crypto system had to be fixed even though there was nothing wrong with the underlying primitives.
 
zazzn said:
https://blogs.mcafee.com/business/security-connected/bitlockertruecrypt-decryption-tool/
Real safe :)
https://www.youtube.com/watch?v=LqYAE-VYTfY
Click to expand...

It even mentions BitLocker alongside with TrueCrypt, since this a completely different attack vector that applies to everything a computer does in memory.

Other tools.

https://www.youtube.com/watch?v=859Qgn2Z8hA
Click to expand...

A dictionary bruteforce attack. Yawn. The fact that he can crack it so quickly is of course because the correct passphrase is in the dictionary file! Duh!

Is this supposed to discredit TrueCrypt or disk encryption in general? I can't really tell.
 
The point is there are tools available period to make people like the one in the video even able to attack the software easily.
Yawn all you want, and keep thinking you are safe, because you are not.
 
The fact that you think that this tool could crack an unknown password in 10 seconds is absolutely hilarious. This guy had the password in the dictionary for demonstration purposes as I already said.

It's a simple bruteforce dictionary attack which works on any cryptosystem. Why do you think we have all these huge keyspaces and key derivation functions? To make this attack hard!

This has nothing to do with TrueCrypt in particular whatsoever.
 
You must log in or register to reply here.
Back
Top