Talk:Hardware-based full disk encryption: Difference between revisions

Content deleted Content added
SineBot (talk | contribs)
m Signing comment by 212.79.110.32 - ""
Line 1:
{{WikiProject Computing|class=stub|importance=mid|hardware=yes|hardware-importance=mid}}
== Wrong assumption ==
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. <small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/212.79.110.32|212.79.110.32]] ([[User talk:212.79.110.32|talk]]) 14:11, 17 December 2014 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
 
 
Another part of the sanitization is slightly off, if not amusing: ''"There is no way to retrieve data once erased in this way - the keys are self generated randomly so there is no record of them anywhere."'' - except that:
# There is no perfect randomness, especially on such weak solutions as SEDs, many vulnerabilities were found where the RNG could be narrowed down a lot.
# The keys are either generated by the SED solution itself (if broken, big vulnerability) and forced on the users, or (very often) it is defined by the user's password input (dictionary attack!) with the occasional salting often being poorly implemented.
# The keys are stored in various places depending on the chosen solution: on the disk (= can be recovered), on the circuit board in the EEPROM (= can be recovered too, with the residual charges if the sanitization procedure only overwrite once and/or zeroes the bits, while the encryption of the key is often poor or nonexistent)(first page of googling "eeprom data retention" gives you [https://www.cl.cam.ac.uk/~sps32/DataRem_CHES2005.pdf '''this''']).
 
I'm not saying changing the key on a SED isn't a clever and very efficient way for sanitization, just that it's not a foolproof solution for critical data. A proper sanitization procedure would change the key several times to make it harder to recover the initial key. And if the encryption system is cracked (or partially cracked), then only overwriting over and over to reduce the probability of data remanence remains the only reliable way to sanitize a disk: at the very least, a few "random" passes with each new keys could help mitigate these 2 risks in one go.
 
So, in my opinion, the article could use some small corrections on the actual reliability of SEDs and the sanitization. At the moment it looks a little like a presentation by a product manager, trying to convince companies to subscribe to their SED transition cycle offer. The information are good, just not as accurate (in terms of exhaustivity) as they could be. --[[Special:Contributions/164.177.113.225|164.177.113.225]] ([[User talk:164.177.113.225|talk]]) 12:36, 23 June 2016 (UTC)
 
== Bad article ==