1 |
Am Fri, 14 Apr 2017 09:37:09 +0200 |
2 |
schrieb Marc Joliet <marcec@×××.de>: |
3 |
|
4 |
> (Sorry for the late reply, I hope it's still useful to you.) |
5 |
|
6 |
NP. The links below were interesting. |
7 |
|
8 |
> On Dienstag, 4. April 2017 00:46:54 CEST Kai Krakow wrote: |
9 |
> > Am Mon, 3 Apr 2017 16:15:24 -0400 |
10 |
> > |
11 |
> > schrieb Rich Freeman <rich0@g.o>: |
12 |
> > > On Mon, Apr 3, 2017 at 2:34 PM, Kai Krakow <hurikhan77@×××××.com> |
13 |
> > > |
14 |
> > > wrote: |
15 |
> [...] |
16 |
> > > |
17 |
> > > If it contains data you'd prefer not be recoverable you might |
18 |
> > > want to use shred or ATA secure erase. |
19 |
> > |
20 |
> > I wonder if shredding adds any value with the high density of modern |
21 |
> > drives... Each bit is down to a "few" (*) atoms. It should be pretty |
22 |
> > difficult, if not impossible, to infer the previous data from it. I |
23 |
> > think most of the ability to infer the previous data comes from |
24 |
> > magnetic leakage from the written bit to the neighbor bits. And |
25 |
> > this is why clever mathematicians created series of alternating bit |
26 |
> > patterns to distribute this leakage evenly, which is the different |
27 |
> > algorithms the shredder programs use. |
28 |
> > |
29 |
> > Do you have any insights on that matter? Just curious. |
30 |
> |
31 |
> For the record, there was some discussion on this on this not too |
32 |
> long ago [edit: oops, looks like it was almost two years ago now]: |
33 |
> see the thread "Securely Securely deletion of an HDD" (yes, I |
34 |
> including my spelling mistake), which you can find online at https:// |
35 |
> archives.gentoo.org/gentoo-user/message/a01e0ad7b07855647a528f1e0324631a |
36 |
> and |
37 |
> https://archives.gentoo.org/gentoo-user/message/582fe3c66c7e13de979b656e9db33325. |
38 |
|
39 |
So you suggest shooting a bullet at the disks? ;-) |
40 |
|
41 |
You could also use the hammer method: |
42 |
https://youtu.be/oNcaIQMjbM8?t=2m55s |
43 |
|
44 |
> > > Shred overwrites the drive with random data using a few passes to |
45 |
> > > make recovery more difficult. Some debate whether it actually |
46 |
> > > adds value. |
47 |
> > |
48 |
> > For a mere mortal it is already impossible to recover data after |
49 |
> > writing zeros to it. Shredding is very time consuming and probably |
50 |
> > not worth the effort if you just want a blank drive and have no |
51 |
> > critical or security relevant data on it, i.e. you used it for |
52 |
> > testing. |
53 |
> > |
54 |
> > But while you are at it: Shredding tools should usually do a read |
55 |
> > check to compare that the data that ought to have been written |
56 |
> > actually was written, otherwise the whole procedure is pretty |
57 |
> > pointless. As a side effect, this exposes sector defects. |
58 |
> > |
59 |
> > If you want to do this to pretend data has never been written to the |
60 |
> > drive, you're probably out of luck anyways: If you'd be able to |
61 |
> > recover data after a single write of zeros, it should be easily |
62 |
> > possible to see that the data was shredded with different bit |
63 |
> > patterns. The S.M.A.R.T counters will add the rest and tell you the |
64 |
> > power-on hours, maybe even amount of data written, head moves etc. |
65 |
> > |
66 |
> > (*): On an atomic scale, that's still 1 million atoms... |
67 |
> |
68 |
> I don't think using zeros is enough, certainly not on SSDs that do |
69 |
> their own compression, I would think. |
70 |
|
71 |
Well, I don't think that compression and its overhead to be effective |
72 |
is worth the effort to implement it. I don't think drives do this. |
73 |
Especially that the bus speed is becoming the bottleneck. Thus to be |
74 |
effective, data would have to be compressed before transferring over |
75 |
the bus and uncompressed after. Also deduplication is very unlikely to |
76 |
be done in firmware. I wouldn't take that as an argument why you want |
77 |
use random data. |
78 |
|
79 |
But I think the point here is sector remapping (as pointed out in the |
80 |
references threads): SSDs do that through the FTL constantly, HDDs do |
81 |
that upon encountering physical problems on the platter. It absolutely |
82 |
makes no difference if you put random data or zero data to the disk: |
83 |
You won't reach the previously mapped sector locations. Secure erase is |
84 |
probably the only thing you can do here, hoping that it covers all |
85 |
sectors (also the spare sectors and unmapped sectors). |
86 |
|
87 |
> And AFAIK using random data |
88 |
> can still fill the drive at native write speed, so I don't see what |
89 |
> you gain by avoiding that. But really, if you haven't already, check |
90 |
> the primary sources in the thread I mentioned above. |
91 |
|
92 |
Depends on what's your random source: /dev/random won't generate |
93 |
entropy fast enough to do this. /dev/urandom could, but actually it's |
94 |
not that very random because it's generated mathematically. That |
95 |
somehow defeats the purpose for using as overwrite source. A mixture of |
96 |
both could do good enough, that's probably where special wiping software |
97 |
comes in. |
98 |
|
99 |
Conclusion: If you don't store state secrets, overwriting with zeros |
100 |
should be enough. If you store data in a high security environment, |
101 |
you're probably required to physically destroy the disks anyway. If you |
102 |
mind remapped sectors, you could use secure erase but you don't know |
103 |
how thoroughly that really works, thus the only other option would be |
104 |
to physically destroy the disk. |
105 |
|
106 |
Then there's the option to use full disk encryption right from the |
107 |
beginning. Still, no encryption has been unbreakable as of today. So |
108 |
physically destroying the disk is still the only option. |
109 |
|
110 |
Of course you can feel better when you used semi-random data to |
111 |
overwrite. If it's not going to slow things down, it's probably the |
112 |
best option to use, followed by a secure erase. |
113 |
|
114 |
But the original question was: How to bring the drive back into orignal |
115 |
vendor delivered state: It contained zeros, not random data. But still, |
116 |
it's not possible to bring it back completely to that state as SMART |
117 |
counters already changed. |
118 |
|
119 |
For SSD, trimming/discarding the whole device would be enough and |
120 |
fastest if you don't mind that your previous data may still physically |
121 |
be there for a while (but inaccessible thru ATA commands). |
122 |
|
123 |
|
124 |
-- |
125 |
Regards, |
126 |
Kai |
127 |
|
128 |
Replies to list-only preferred. |