Talk:Hardware-based full disk encryption
|WikiProject Computing / Hardware||(Rated Stub-class, Mid-importance)|
SDD disk sanitization is completely different then regular disks. The claim that SDD can help to reduce amount of time for sanitization is therefore wrong. — Preceding unsigned comment added by 188.8.131.52 (talk) 14:11, 17 December 2014 (UTC)
This article is not written in a style suitable for Wikipedia. It looks more like magazine article based on a couple of press releases. There are a lot of terms used but not explained
Examples: FDE, OPAL, Enterprise standards, attack vector, Enterprise SAS, bridge and chipset, Stonewood, Flagstone.
The article should start with an explanation of what the topic is, not from where it's available. Vendor names should be removed, or moved to a less prominent place at the end of the article. There are disadvantages with hardware-based full disk encryption, but they aren't mentioned. Stated facts needs reference.
Questionable facts: "HDD FDE is available ... via the Trusted Computing Group." Perhaps it wasn't the authors's intention that I have to buy such drives via TCG, but it says so.
Merge with Disk encryption hardware
FDE is only safe with off or hibernated?
I removed this content because it conflicts with my direct experience and it is not sourced. If someone can find a source then we should reconsider it and I can examine why I do not see this in my system.
FDE is only safe when the computer is off or hibernated. When the computer is stolen while it is turned on or suspended, a restart which boots from a USB stick will reveal the data without need for the password. The problem is that these so called warm reboots will not prompt for the HD password, nor the power-on-password for that matter. This is as a security risk. In contrast, software-based encryption will prompt for the password on a warm reboot.
I had added this, and I'm disappointed you removed it. It is consistent with my experience on a Thinkpad laptop both X61 and T61. If you do a restart from the OS, i.e. a warm reboot, you are not prompted for the password THis is indeed what seagate also states. http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=205983
When I researched this issue I came across a discussion stating that making the machine prompt for a password with a warm reboot was technically difficult. Maybe this has been improved on recent machines, or it is unique to seagate discs. I have put it back in because I think it is important, but now I have added the references.
- It is always best to include a source for any material added to any article. I reworded your entry to more specifically support the sources you listed. Frankly I could not find the specific mention on the Seagate site to which you discuss. Maybe you can identify the specific entry on that Q&A page to help us also see it. The Forum talk page is not typically a valid source, but I did not want to get into a edit war with you so I left it in until we resolve the issue on the talk page here. Thanks for your consideration. § Music Sorter § (talk) 09:12, 6 September 2011 (UTC)
Neutral point of view issues
This article seems to me to have several issues with its point of view, specifically:
- It spends a great deal of time talking about the manufacturers of hardware-based full disk encryption (HBFDE) compared to HBFDE itself.
- This is purely my own opinion, but I think it's worth mentioning: the article reads like an advertisement one might find in a magazine, that is written in a style such that it will get mistaken for a magazine article. In other words, it's an advertisement that looks like a Wikipedia article, and gets around looking like an advertisement by mentioning more than one manufacturer.
- There is no discussion of any drawbacks of hardware-based disk encryption. While I am not well-versed enough in the technology to know what those drawbacks would be, I've never come across anything that had zero drawbacks. Does this cost more? Is it more labor-intensive to install? Lioux (talk) 01:12, 17 April 2013 (UTC)
- Agreed. The real problem with hardware encryption is that it's difficult to verify the crypto implementation (for backdoors and other weaknesses) and manufacturers have a track record of getting it wrong. Some relevant sources:      -- intgr [talk] 09:18, 17 April 2013 (UTC)