Which encryption program for SSD?

Joined
Apr 29, 2015
Messages
31
Which encryption program is the best to lock down SSD for Ubuntu & Win7 OS & HDD for media?

I've used truecrypt in the past but it's clearly been compromised.

Is bit locker the best or is there something better?

I'm not opposed to a paid program but free is always nice.

Do I need to install the encryption software BEFORE the OS? Or can it be done afterwards?

Is there an encryption software that is compatible with both Ubuntu and Win7? I'd prefer to only deal with one type of program.
 
Last edited:
The only encryption solution on the market that can do what you are asking is OSA from WinMagic.

http://www.winmagic.com/products/features/sed-self-encrypting-hard-drives

You need HD's with OPAL compatibility.

This works because it uses the hardware to do the encryption vs software. When you software encrypt bitlocker win7, linux wouldn't understand the disk. If you encrypted in linux it windows wouldn't be able to read the disk.

OSA would be the ideal solution or you should look into running Ubuntu or windows in a Virtual machine instead.

TPM is junk for full disk encryption, and offers little other than brute force protection.
 
I planned on having Ubuntu and win7 on their own separate SSDs, does that eliminate the problem of bit locker not understanding the different OS if I had intended did to have them on a single SSD?
 
That's what I meant by trying to use/stay true/become familiar with one encryption program for two different OS - that they would be on separate and dedicated Samsung 850 Pro SSDs. (hopefully the best, something better than truecrypt which I was using before and clearly had holes in it)

Is bit locker the best/most secure/offers highest level of encryption/possible hidden partition/completly uncrackable in any way including brute force these days?

Then I just need to figure out if encryption must be added before OS is loaded onto SSD or if encryption is done after OS is loaded onto SSD?

Or would the AES 256 bit encryption that Samsung 850s come with built into the hardware be a better choice over a software based system like bit locker or perhaps even diskcryptor? (are either of these the top of their game and trustworthy to not have any backdoors?)

I've been reading and you need your mobo bios to be able to enable the encryption on HDD/SSD with a password set in bios upon every boot up.

So how can I tell if my Asus mobo bios allows/enables a startup password for an encrypted HDD/SSD?

My mobo is: http://m.newegg.com/Product?itemNumber=N82E16813131277
 
Last edited:
Ubuntu has had full disk encryption built in since v11.04 iirc, at least that is how long I have been using it. Full disk encryption is not on by default, you have to set that up during the install, home dir is encrypted by default regardless of Full disk encryption. If you want one that is cross OS compatible use, use truecrypt's last release. You will get better answers by stating your threat model.
 
Because it's been extensively audited? That's a very valuable property of an encryption tool.

Recommending not to use TC because it's "EoL" is short-sighted because there is no proper replacement - maybe VeraCrypt which is a direct successor to Truecrypt.

If TC has all the features you need, you should still be using it. Anything that's closed-source and commercial is not to be trusted.
 
Truecrypt is obsolete, not just EoL.

Doesn't work with modern UEFI systems for full disk encryption.

So you are out of luck with most kit made in the past 3-4 years.

To be honest I think that's the reason they abandoned it. Just too much hassle to get it to work.

I still use it for encrypted containers.
 
Why not just use Bitlocker for the Windows partition/disk and LVM encryption for the Linux partition?
 
optional key escrow, not mandatory. You can absolutely have a standalone bitlocker that doesn't backup the key to active directory or a hotmail/live.com account (or anything/anyplace else)
 
And I am sure he still thinks Skype communications are safe as well. :D

If you are recommending anything that has inbuilt key escrow as "secure", may you be tar and feathered and branded a peddler of snake oil for the rest of your days or at least until you wake up.
 
Last edited:
Hmm let me see what is the likely scenario that 99% of encryption has to do battle with and prevent access to the data from?

Honestly? The most usual will be your mates or Gf wanting to borrow your laptop. The second is preventing the guy who found or stole your laptop from looking at your data for all of 3 minutes before he loses interest and slaps a cracked copy of Windows over it to sell it down the bar for drug money.

Very few, if any of you have data that the Chinese/Russions/Feds will send their best agents after. Sorry to burst your bubble on that one.

Just has to stop your mum looking at your porn collection. That's all usually.
 
Why settle with less? OP asked for the best.

Hmm because maybe OP really doesn't have a clue what they actually want/need it for?

I've seen so called 'tech experts' full disk encrypt their test/workbench machines because they thought it clever to do so. I've sat back and watched, just waiting for the moment a BSOD or lock up corrupts the HDD and its then tears before bedtime.


The old adage of just because you can...doesn't mean you should.

Full Disk Encryption isn't for everyone. It can bite you just as hard as not being encrypted.

Unless you have data that could be sensitive in the wrong hands just don't bother or just use simple container encryption instead with Truecrypt to protect the few bits and bobs you might have.
 
Last edited:
I've seen so called 'tech experts' full disk encrypt their test/workbench machines because they thought it clever to do so. I've sat back and watched, just waiting for the moment a BSOD or lock up corrupts the HDD and its then tears before bedtime.
Is Truecrypt known to do this? If not, what has it got to do with anything?

Unless you have data that could be sensitive in the wrong hands just don't bother or just use simple container encryption instead with Truecrypt to protect the few bits and bobs you might have.
Data in the wrong hands is always sensitive. That's why it's called the "wrong" hands.

Truecrypt is EoL, yes. Obsolete? No. What's with the FUD against TC?
 
Is Truecrypt known to do this? If not, what has it got to do with anything?

Data in the wrong hands is always sensitive. That's why it's called the "wrong" hands.

Truecrypt is EoL, yes. Obsolete? No. What's with the FUD against TC?

Oh boy, if you drive gets corrupted and it has data on it you need (again a lot of folks don't do backups). You then have to un-encrypt the HDD to get the data back. Again only use encryption if you really have to. And especially not on a unstable machine or one you do a lot of testing on. Encryption can bite like that. Also folks that encrypt their machines without fully understanding the ramifications often to forget to make a copy of the key or decrypt CD or lose it somewhere. I have had failed HDDs brought in to me for recovery that have been encrypted. "Okay do you have the decryption key or CD?"

"Whats that?" is the reply. Bravo!

Truecrypt IS obsolete for full disk encryption as it doesn't work with modern UEFI systems. Basically most laptops and PCs made in the past 3-4 years.

Its only good for old systems or containers.
 
Oh boy, if you drive gets corrupted and it has data on it you need (again a lot of folks don't do backups). You then have to un-encrypt the HDD to get the data back. Again only use encryption if you really have to. And especially not on a unstable machine or one you do a lot of testing on. Encryption can bite like that. Also folks that encrypt their machines without fully understanding the ramifications often to forget to make a copy of the key or decrypt CD. I have had failed HDDs brought in to me for recovery that have been encrypted. "Okay do you have the decryption key or CD?"

"Whats that?" is the reply. Bravo!
Cool story but completely off-topic. No one was asking whether to use encryption at all.

Truecrypt IS obsolete for full disk encryption as it doesn't work with modern UEFI systems. Basically most laptops and PCs made in the past 3-4 years.

Its only good for old systems or containers.

As long as you can legacy-boot a UEFI system, Truecrypt works. If you use an SSD, chances are it's smaller than 2TB, so you don't need GPT so you don't need UEFI boot.

TC is still perfectly usable today for full-disk encryption. Why do you have a problem with that?
 
Cool story but completely off-topic. No one was asking whether to use encryption at all.



As long as you can legacy-boot a UEFI system, Truecrypt works. If you use an SSD, chances are it's smaller than 2TB, so you don't need GPT so you don't need UEFI boot.

TC is still perfectly usable today for full-disk encryption. Why do you have a problem with that?

Why would you want to disable UEFI and most machines will only allow Truecrypt if you do a legacy/full reinstall from scratch. Again a lot of people are not going to know or want to do that. Used to be you could just run Truecrypt on any old machine, slap in a password, burn your CD and then go do some chores while it did it's work.

That doesn't happen anymore.

It's therefore, IMO obsolete if it doesn't fully support current factory/industry standards.
 
Not mandatory (that you know of).

really? You think given that bitlocker is used by millions of users, including IT pros and security experts, that they haven't done egress testing to watch if a machine happens to send the bitlocker key out during or after the encryption process?
 
Who says it actually needs to send a key somewhere?

With zero insight into how keys are _generated_, what makes you so sure the actual key is not a product of some pre-determined calculation process without any actual randomness? Even if you can look at the key, you can't distinguish a real random key from the output of an encryption process to which only Microsoft knows the input. That's why _any_ closed-source encryption software can't ever be trusted. There is just no way around that.
 
Last edited:
True, there isn't any way to know. Of course truecrypt wasn't audited until it was EOL, pretty sure the vast majority of users (myself included), just took a leap of faith that it was right. I do think the odds favor bitlocker being legit, because of the number of people that have worked on it inside microsoft. This isn't joes encryption software company, where 2 guys built a closed source FDE system. Over the past decade, I'd guess there have been hundreds of MS software engineers that have rotated through the bitlocker dev process. I don't recall hearing any stories of any of them coming out after they moved on from microsoft saying anything like 'don't trust bitlocker' or 'there is a backdoor in bitlocker' or 'the crypto in bitlocker is just bad'.

I just have to think by now, if there was a hole in in it, one of these devs would have spilled the beans.
 
I don't trust the integrity of single people inside large groups at all. If history taught me anything, it's that people in large groups are far more likely to keep their mouths shut.

Microsoft is the supplier of the most dominant OS on the market. It's a huge corporation with many small cog wheels and bureaucracy.

I mean, just look at how advanced the NSA spying procedures already were before someone blew the whistle on that one. And then it was an outside contractor, not an insider.

Never underestimate the common human's capability to keep his eyes wide shut if it means job security and it's "just against the t'rr'rists" anyway.

Trust in large groups is a pacifier for when you have no other choice. It's to calm yourself down. Given a choice, I would never choose closed-source willingly when it comes to crypto.
 
Last edited:
Also keep in mind that bitlocker code is reviewable by 3rd parties, if they sign an NDA.

I'd prefer if they opened the source for it, but doubt that will ever happen.
 
That's what I meant by trying to use/stay true/become familiar with one encryption program for two different OS - that they would be on separate and dedicated Samsung 850 Pro SSDs. (hopefully the best, something better than truecrypt which I was using before and clearly had holes in it)

Is bit locker the best/most secure/offers highest level of encryption/possible hidden partition/completly uncrackable in any way including brute force these days?

Then I just need to figure out if encryption must be added before OS is loaded onto SSD or if encryption is done after OS is loaded onto SSD?

Or would the AES 256 bit encryption that Samsung 850s come with built into the hardware be a better choice over a software based system like bit locker or perhaps even diskcryptor? (are either of these the top of their game and trustworthy to not have any backdoors?)

I've been reading and you need your mobo bios to be able to enable the encryption on HDD/SSD with a password set in bios upon every boot up.

So how can I tell if my Asus mobo bios allows/enables a startup password for an encrypted HDD/SSD?

My mobo is: http://m.newegg.com/Product?itemNumber=N82E16813131277

Bitlocker is good as long as the machine is not powered on just like any software encryption. IF the machine is powered on, and you have already booted to the OS (using preboot authentication) then it's very easy to break bitlocker let alone any software solution.

http://www.zdnet.com/article/free-cofee-opens-microsoft-bitlocker/

Remember, full disk encryption (FDE) is ONLY really protecting if the machine is OFF. So that no one can steal the contents of the HD. If you need application / File folder encryption that is a different story, but very cumbersome to use because you have to authenticate every time you need to access something or store the keys in memory.Not to mention slow.

Since you are going to use 850PRO's you can use 1 drive or two using the WinMagic OSA solution that I mentioned above. Why? Because it uses the OPAL commands to turn on hardware encryption on the 850 PRO's which are much much more secure than software encryption as no key data is EVER stored in system memory. Also, it will allow you to do Dual boot if you have a MS boot loader or Grub. Basically, after the disk unlocks and you pass (Preboot authentication) it will restart the system and boot normally to whatever boot loader you had.

Also the WinMagic solution supports UEFI/Legacy bios. Using the onboard 850's encryption is the BEST option. If you can enable it though the BIOS, I would be surprised, usually only big box machines like Dell, HP, Lenovo allow this and usually only on corporate devises. (Dell does it though bios, Lenovo HPM, HP though their software suite which uses WInMagic as the engine) The only problem with the Bios solutions are there is no recovery if you forget the password. (except HP since it uses WinMagic's engine which allows for recovery though self help questions)

Disclosure.

I'm a 10 year veteran in Full disk encryption, and I work for a encryption company

I hope this helps. If you would like to PM me I can be more specific on some of the items.
 
A "10 year veteran" telling you to trust encryption of which you cannot see a single bit of code.

Comedy gold.
 
Glad you had a chuckle!

But you are clueless sir.

Any and virtually all encryption solutions use standard encryption algorithms such as AES256. Also any solution worth anything will be certified though FIPS validation and NIST/Common Criteria.

Such as something like this.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1880

The fact that in this case I recommend a HARDWARE solution's (activated though a FIPS validated software management tool) ensures all the chains in the link are strong.

There are a few (very few) FIPS validated self encrypting HD's that Seagate used to and still may make, I don't know if the 850PRO's are FIPS validated.

So your argument is that open source means it's safer? Shall we talk about Shellshock or Heartbleed?

There will always be bugs no matter how many eyes look at the code. The question is will they be reported or exploited.

There are pros/cons for both options of open/close source. But when it comes to security, not having someone know the internal workings of something is the first step of a layered blanket of security. NOTHING is hack proof even AES256 can be broken. Just like physical security like a bank vault.

You just have to throw more and more obstetrical in the way to make it harder for the attacker to gain the ultimate goal.

Oh by the way, tell me ONE software that is open source that can control self encrypting disks?

That's what I though Mr. Chuckles.

Oh PS. Yes this 10 year veteran is telling you to use the same software that is approved for SECRET data for the NSA. So go get your free opensource encryption solution, where you have NO idea on the integrity of the people maintaining aren't making a profit to maintain and update the software and tell me how well it's working out for you when you can't boot that UEFI machine of yours.
http://www.businesswire.com/news/ho...cureDoc-v4.3-Canadian-Government#.Vg9rEnpVhBc

Wanker.
 
Last edited:
Any and virtually all encryption solutions use standard encryption algorithms such as AES256. Also any solution worth anything will be certified though FIPS validation and NIST/Common Criteria.

Such as something like this.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1880

The fact that in this case I recommend a HARDWARE solution's (activated though a FIPS validated software management tool) ensures all the chains in the link are strong.
So basically your argument is "government said so and I have no means to check for myself" when government clearly demonstrated malice in the past 2+ years.

http://www.pcworld.com/article/2454...-weak-crypto-standard-nist-advisers-find.html

So your argument is that open source means it's safer? Shall we talk about Shellshock or Heartbleed?
Yes, it is safer. How do you check not only for mistakes but pure malice in code you cannot even get at?

There are pros/cons for both options of open/close source. But when it comes to security, not having someone know the internal workings of something is the first step of a layered blanket of security. NOTHING is hack proof even AES256 can be broken. Just like physical security like a bank vault.
Wrong. Hiding the code is _never_ a security layer. Hearing this from a "professional" makes me sad. https://www.schneier.com/essays/archives/2004/10/the_non-security_of.html https://www.schneier.com/crypto-gram/archives/2002/0515.html

Oh by the way, tell me ONE software that is open source that can control self encrypting disks?
Why should it, if the encryption in the disk is questionable? You simply don't use the encryption of the disk itself and treat it as dumb storage to hold your own ciphertext.

Oh PS. Yes this 10 year veteran is telling you to use the same software that is approved for SECRET data for the NSA.
Yes, it works _for_ the NSA. Which means if _you_ use it, the NSA still has their backdoor.

So go get your free opensource encryption solution, where you have NO idea on the integrity of the people maintaining aren't making a profit to maintain and update the software and tell me how well it's working out for you when you can't boot that UEFI machine of yours.

So instead of having people work on crypto where you don't know their motives but where you can look at the code is somehow worse than having people in your crypto where you _know_ they are malicious _and_ where you can't look at the code.

Seriously, move into comedy or something. Crypto isn't for you.
 
Last edited:
Glad you had a chuckle!

But you are clueless sir.

Any and virtually all encryption solutions use standard encryption algorithms such as AES256. Also any solution worth anything will be certified though FIPS validation and NIST/Common Criteria.

Such as something like this.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2013.htm#1880

The fact that in this case I recommend a HARDWARE solution's (activated though a FIPS validated software management tool) ensures all the chains in the link are strong.

There are a few (very few) FIPS validated self encrypting HD's that Seagate used to and still may make, I don't know if the 850PRO's are FIPS validated.

So your argument is that open source means it's safer? Shall we talk about Shellshock or Heartbleed?

There will always be bugs no matter how many eyes look at the code. The question is will they be reported or exploited.

There are pros/cons for both options of open/close source. But when it comes to security, not having someone know the internal workings of something is the first step of a layered blanket of security. NOTHING is hack proof even AES256 can be broken. Just like physical security like a bank vault.

You just have to throw more and more obstetrical in the way to make it harder for the attacker to gain the ultimate goal.

Oh by the way, tell me ONE software that is open source that can control self encrypting disks?

That's what I though Mr. Chuckles.

Oh PS. Yes this 10 year veteran is telling you to use the same software that is approved for SECRET data for the NSA. So go get your free opensource encryption solution, where you have NO idea on the integrity of the people maintaining aren't making a profit to maintain and update the software and tell me how well it's working out for you when you can't boot that UEFI machine of yours.
http://www.businesswire.com/news/ho...cureDoc-v4.3-Canadian-Government#.Vg9rEnpVhBc

Wanker.

Proper design of a crypto system not only involves picking appropriate crypto primitives but also in how the crypto primitives are configured and used within the system. FIPS certified primitives are useful for building secure crypto systems but how they are used is also important as a crypto system. Security can be undermined by very subtle design flaws.

There is a common advice in software engineering regarding crypto. Don't roll your own crypto. People often think that is referring to crypto primitives like ciphers and hashes and while you certainly don't want to make your own crypto primitives the advice is actually referring to not designing ones own crypto systems such as trying to reinvent TLS or PGP.

Ultimately I have to agree with TCM2, you have to take a leap of faith when trusting crypto systems that are not open. There are a lot of ways to screw up the design of a crypto system and even professionals get it wrong, setting aside the possibility for malice.

While I agree, that hardware encryption is is great in theory, ultimately one is trusting the manufacturer to implement the crypto system correctly without allowing you to verify it and they haven't really earned that trust.
 
Bitlocker is good as long as the machine is not powered on just like any software encryption. IF the machine is powered on, and you have already booted to the OS (using preboot authentication) then it's very easy to break bitlocker let alone any software solution.

http://www.zdnet.com/article/free-cofee-opens-microsoft-bitlocker/

Remember, full disk encryption (FDE) is ONLY really protecting if the machine is OFF. So that no one can steal the contents of the HD. If you need application / File folder encryption that is a different story, but very cumbersome to use because you have to authenticate every time you need to access something or store the keys in memory.Not to mention slow.

Since you are going to use 850PRO's you can use 1 drive or two using the WinMagic OSA solution that I mentioned above. Why? Because it uses the OPAL commands to turn on hardware encryption on the 850 PRO's which are much much more secure than software encryption as no key data is EVER stored in system memory.

How is that article showing breaking of Bitlocker or software encryptions in general and how would hardware disk encryption be any different when accessing a live running computer and looking at disk content?
 
So basically your argument is "government said so and I have no means to check for myself" when government clearly demonstrated malice in the past 2+ years.

http://www.pcworld.com/article/2454...-weak-crypto-standard-nist-advisers-find.html

Yes, it is safer. How do you check not only for mistakes but pure malice in code you cannot even get at?

Wrong. Hiding the code is _never_ a security layer. Hearing this from a "professional" makes me sad. https://www.schneier.com/essays/archives/2004/10/the_non-security_of.html https://www.schneier.com/crypto-gram/archives/2002/0515.html

Why should it, if the encryption in the disk is questionable? You simply don't use the encryption of the disk itself and treat it as dumb storage to hold your own ciphertext.

Yes, it works _for_ the NSA. Which means if _you_ use it, the NSA still has their backdoor.



So instead of having people work on crypto where you don't know their motives but where you can look at the code is somehow worse than having people in your crypto where you _know_ they are malicious _and_ where you can't look at the code.

Seriously, move into comedy or something. Crypto isn't for you.


i love how you speak like you've gone through the entire codebase of these OSS encryption tools yourself

encryption tools are all about what is "good enough", you speak like there is a holy grail of disk encryption software

just use bitlocker or veracrypt (whichever is easier for you) and be done with it, OP
 
And your actual point is?

that you tout transparency for transparency's sake and ultimately you're trusting those devs instead of other devs... it's stupid to think someone building an OSS encryption tool is somehow more virtuous then a closed source one... the truecrypt devs stayed anonymous throughout the entire dev of the program... thats kind of shady
 
the truecrypt devs stayed anonymous throughout the entire dev of the program... thats kind of shady

So what? The source was available and proven to match the binaries. The crypto was audited. How would you even begin to audit BitLocker?

You seem to defend closed source, but without any factual evidence. Basically, you can view closed source and open source as to be completely equal when it comes to developers and code quality. The difference is then in whether you can view the code. That's all. How does that make open source worse?

In the absolute worst case it's equal to closed source. That still wouldn't be a reason to trust closed source.

If you know no one can view your source code, it's actually an enticement to hide malicious code if you're somehow forced to implement a cryptographical backdoor (skewed RNG etc.).

So yes, the plain _ability_ to view the code makes open source better. It doesn't mean open source is free from bugs or even malice. Do you think something like Heartbleed would ever become visible in a closed source project?
 
So basically your argument is "government said so and I have no means to check for myself" when government clearly demonstrated malice in the past 2+ years.

So you posted a link about NSA causing weak cryto? Did you find better yourself, did you write a new crypto engine? No exactly... Then shut-up, because we have to use what is available and generally everyone uses at LEAST AES256. (Bitlocker on windows 7 does not by default)

http://www.pcworld.com/article/2454...-weak-crypto-standard-nist-advisers-find.html

Yes, it is safer. How do you check not only for mistakes but pure malice in code you cannot even get at?

Wrong. Hiding the code is _never_ a security layer. Hearing this from a "professional" makes me sad. https://www.schneier.com/essays/archives/2004/10/the_non-security_of.html https://www.schneier.com/crypto-gram/archives/2002/0515.html

Why should it, if the encryption in the disk is questionable? You simply don't use the encryption of the disk itself and treat it as dumb storage to hold your own ciphertext.

Yes, it works _for_ the NSA. Which means if _you_ use it, the NSA still has their backdoor.



So instead of having people work on crypto where you don't know their motives but where you can look at the code is somehow worse than having people in your crypto where you _know_ they are malicious _and_ where you can't look at the code.

Seriously, move into comedy or something. Crypto isn't for you.

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)

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. The question is not IF it will be broken but when, so throwing all the road blocks you can up is the best solution. You can debate this all you like it doesn't matter, because this is really all opinions. (showing windows users names vs having to type them at logon)

What proof to your claim that hardware encryption questionable? Can you prove it? If the only claim is that it's not FIPS validated then? Is it that you do not trust AES256? Hardware is generally not FIPS because of the time it takes to obtain certifications. Generally the hardware is obsolete by the time the validation comes though. Regardless, you don't trust any of these certifications anyways right?

The REAL question is what's GOOD ENOUGH for what you are protecting?

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.
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.

http://www.trustedcomputinggroup.org/about_tcg/tcg_members

So in closing the solution for the OP is what I recommended several posts ago.

How is that article showing breaking of Bitlocker or software encryptions in general and how would hardware disk encryption be any different when accessing a live running computer and looking at disk content?

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.

And your actual point is?

Point is you have no idea what is better just an opinion because you have no FACTS. Stop trying to portray that you know factually what is better when you have done none of the actual cracking or software testing. Or even code review!

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.

Basically, you can view closed source and open source as to be completely equal when it comes to developers and code quality. The difference is then in whether you can view the code. That's all. How does that make open source worse?

If you know no one can view your source code, it's actually an enticement to hide malicious code if you're somehow forced to implement a cryptographical backdoor (skewed RNG etc.).

So yes, the plain _ability_ to view the code makes open source better. It doesn't mean open source is free from bugs or even malice. Do you think something like Heartbleed would ever become visible in a closed source project?

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. (putting food on the table) Not knowing i'm going to ever get an update for that bug on freeware encryption is pretty riveting, let along the time to decrypt/encrypt with another solution.

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
 
Back
Top