"Sebastian G." <seppi@seppig.de> wrote in
news:62qjtgF2484t3U3@mid.dfncis.de:
> bealoid wrote:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:62q4cpF2486s5U1@mid.dfncis.de:
>>
>> [snip]
>>
>>> This is nothing special though, even Peter Gutmann mentions much more
>>> potent ways like magnetic force scanning tunneling microscopy.
>>
>> and even gutmann says that no longer works and that 3 random overwrites
>> is about as good as you can do.
>
>
> And even I wrote that one overwrite is enough, but this doesn't change
> the result that such techniques allow to retrieve information
> statistically significantly better than random guessing. If the high
> level data are encoded with redundancy as well, this might be a problem.
remember that you are allowed as many read passes as you want on each
track. This allows 'averaging out' much of the noise.
You can use heads that are much narrower than the normal read head.
This allows an increased signal to noise ratio for the buried signal near
the outside of the overwrite band since the bands will not overlap exactly.
By using many reads from many 'lanes' through the data, you have a chance
of 'digging' the signal out of the noise.
I think I remember that, at one time, the CIA could dig down through 7
layers of overwriten data to recover the underlying information.
Of course, that may take millions of passes per track.
Knowing what the data could be [a 1 or a 0] makes it much easier than
recovery of an analogue signal (nixon's missing minutes).
--
bz
please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.
bz+spr@ch100-5.chem.lsu.edu remove ch100-5 to avoid spam trap
"Sebastian G." <seppi@seppig.de> wrote in
news:62qjtgF2484t3U3@mid.dfncis.de:
> bealoid wrote:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:62q4cpF2486s5U1@mid.dfncis.de:
>>
>> [snip]
>>
>>> This is nothing special though, even Peter Gutmann mentions much
>>> more potent ways like magnetic force scanning tunneling microscopy.
>>
>> and even gutmann says that no longer works and that 3 random
>> overwrites is about as good as you can do.
>
>
> And even I wrote that one overwrite is enough, but this doesn't change
> the result that such techniques allow to retrieve information
> statistically significantly better than random guessing. If the high
> level data are encoded with redundancy as well, this might be a
> problem.
I'd be keen to see any cites for people actually doing this.
> "Sebastian G." <seppi@seppig.de> wrote in
> news:62qjtgF2484t3U3@mid.dfncis.de:
>
>> bealoid wrote:
>>
>>> "Sebastian G." <seppi@seppig.de> wrote in
>>> news:62q4cpF2486s5U1@mid.dfncis.de:
>>>
>>> [snip]
>>>
>>>> This is nothing special though, even Peter Gutmann mentions much more
>>>> potent ways like magnetic force scanning tunneling microscopy.
>>> and even gutmann says that no longer works and that 3 random overwrites
>>> is about as good as you can do.
>>
>> And even I wrote that one overwrite is enough, but this doesn't change
>> the result that such techniques allow to retrieve information
>> statistically significantly better than random guessing. If the high
>> level data are encoded with redundancy as well, this might be a problem.
>
> remember that you are allowed as many read passes as you want on each
> track. This allows 'averaging out' much of the noise.
I doesn't average out the noise that is itself part of the recorder signal
on the media, which is the main reason why this technique isn't effective
any more.
bealoid wrote:
> "Sebastian G." <seppi@seppig.de> wrote in
> news:62qjtgF2484t3U3@mid.dfncis.de:
>
>> bealoid wrote:
>>
>>> "Sebastian G." <seppi@seppig.de> wrote in
>>> news:62q4cpF2486s5U1@mid.dfncis.de:
>>>
>>> [snip]
>>>
>>>> This is nothing special though, even Peter Gutmann mentions much
>>>> more potent ways like magnetic force scanning tunneling microscopy.
>>> and even gutmann says that no longer works and that 3 random
>>> overwrites is about as good as you can do.
>>
>> And even I wrote that one overwrite is enough, but this doesn't change
>> the result that such techniques allow to retrieve information
>> statistically significantly better than random guessing. If the high
>> level data are encoded with redundancy as well, this might be a
>> problem.
>
> I'd be keen to see any cites for people actually doing this.
Unruh wrote:
> bealoid <signup@bealoid.co.uk> writes:
>
>> "Sebastian G." <seppi@seppig.de> wrote in
>> news:62as0jF21pbucU1@mid.dfncis.de:
>
>> [snip]
>
>>> Either you have a really really long fire (hours till days) of
>>> constant high heat, or you may simply resort to degaussing or acid.
>
>> Obviously: Degaussing the platters, not the whole drive. Which I've seen
>> people recommend as a way of disk erasing.
>
> Degaussing would I think be a terrible technique. It wold leave data all
> over the place. Fire will do it-- raise the temp about the neal point and
> the domains all disappear.
>
You have to shred the drive at the point of origin so it can be
transported with minimum security to the smelter; i.e. junk dealer.
>"Sebastian G." <seppi@seppig.de> wrote in
>news:62qjtgF2484t3U3@mid.dfncis.de:
>> bealoid wrote:
>>
>>> "Sebastian G." <seppi@seppig.de> wrote in
>>> news:62q4cpF2486s5U1@mid.dfncis.de:
>>>
>>> [snip]
>>>
>>>> This is nothing special though, even Peter Gutmann mentions much more
>>>> potent ways like magnetic force scanning tunneling microscopy.
>>>
>>> and even gutmann says that no longer works and that 3 random overwrites
>>> is about as good as you can do.
>>
>>
>> And even I wrote that one overwrite is enough, but this doesn't change
>> the result that such techniques allow to retrieve information
>> statistically significantly better than random guessing. If the high
>> level data are encoded with redundancy as well, this might be a problem.
>remember that you are allowed as many read passes as you want on each
>track. This allows 'averaging out' much of the noise.
No it does not because the "noise" is on the disk. It is not random added
noise. It is part of the magnetism of the disk, which is the same on each
read. Now if you had 1000 disks all with the same data and all erased the
same way, then noise averageing may stqnd a chance.
>You can use heads that are much narrower than the normal read head.
And yu think they do not use read heads which are as narrow as possible
now? How do you think they get terrabytes on a tiny disk that once held
10MB for the same area?
>This allows an increased signal to noise ratio for the buried signal near
>the outside of the overwrite band since the bands will not overlap exactly.
Ancient technology.
>By using many reads from many 'lanes' through the data, you have a chance
>of 'digging' the signal out of the noise.
>I think I remember that, at one time, the CIA could dig down through 7
>layers of overwriten data to recover the underlying information.
And once upon a time disks held 10MB of datq
>Of course, that may take millions of passes per track.
>Knowing what the data could be [a 1 or a 0] makes it much easier than
>recovery of an analogue signal (nixon's missing minutes).
>--
>bz
>please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
>infinite set.
>bz+spr@ch100-5.chem.lsu.edu remove ch100-5 to avoid spam trap
>> You can use heads that are much narrower than the normal read head.
>
> And yu think they do not use read heads which are as narrow as possible
> now? How do you think they get terrabytes on a tiny disk that once held
> 10MB for the same area?
Not because the heads got narrower; they're rather fucking huge, and only a
very fine control of positioning and signal strength makes it possible to
record high density. Indeed, if you just judge by the size of head, we'd
still dig around with 10 MB per plater.
I didn't see any mention of the fact that for most disks there
isn't a way to erase revectored (i.e., replaced) blocks.
I looked at "Serial ATA Specification V2.6",
dated 15-February-2007, file name:
SerialATA_Revision_2_6_Gold.pdf
(Available to members or for sale at: https://www.sata-io.org/secure/spec_download.asp)
and found that the operation of the ERASE and ERASE UNIT commands
were not specified, so, in the absence of a manufacturer's
specification for a particular disk model, one can't be sure
that anything in a sector that has been marked defective is
touched at all.
On Sat, 23 Feb 2008 13:02:40 -0500, Arthur T. <arthur@munged.invalid>
wrote:
> In Message-ID:<Xns9A4DA577A884FYAsfKJXSTO@194.117.143.37>,
> bealoid <signup@bealoid.co.uk> wrote:
>
> >1) The theory is that you don't know what tech your attacker has, and you
> >don't know what tech your attacker will invent in the future, and so you
> >over-write many times with patterns and random data, then take the
> >platters out and physically destroy them.
>
> Pointing out the possibilities of future tech (and the
> near-impossibility of ruling out what future tech might be) puts
> overwriting into a different perspective. Thank you.
>
> >2) You have sensitive information (patient medical stuff, for example)
> >and it's just easier to do the belt-and-braces destroy thing than a
> >sensible destroy, if only to keep the wing-nuts out of your hair. You've
> >removed any doubt.
>
> CYA is a very good reason, but not a technical one ;-).
>
> >People might prefer to do cost-benefit risk analyses - it takes time (and
> >thus money) to overwrite disks.
>
> And, it takes even more time and money to do the analysis of
> how much overwriting is necessary. Thus, we're likelier to get
> "guidelines" than reasoned, technical answers.
>
> So, even if today N overwrites makes a disk unreadable,
> tomorrow someone might find a way to read it. (And, of course,
> even N overwrites might be readable by a closed-mouthed government
> agency.)
>
> Short of a theoretical proof (which unlikely to have much to
> do with real-world technology), N can be argued but might never be
> enough for absolute security.
>
> I think this explains the lack of reasons for the guidelines
> currently available.
>
> Thanks to all who responded to this thread. I responded to
> this post because that's when the answers sunk in, but all of the
> responses were helpful in bringing me to the state where I could
> understand the gestalt.
> Re: "How many overwrites for secure erase?"
>
> I didn't see any mention of the fact that for most disks there
> isn't a way to erase revectored (i.e., replaced) blocks.
>
> I looked at "Serial ATA Specification V2.6",
> dated 15-February-2007, file name:
> SerialATA_Revision_2_6_Gold.pdf
> (Available to members or for sale at:
> https://www.sata-io.org/secure/spec_download.asp)
> and found that the operation of the ERASE and ERASE UNIT commands
> were not specified, so, in the absence of a manufacturer's
> specification for a particular disk model, one can't be sure
> that anything in a sector that has been marked defective is
> touched at all.
SCSI doesn't have such commands either, but it has READ DEFECT LIST and
WRITE RAW SECTOR.
Mark F wrote:
> Re: "How many overwrites for secure erase?"
>
> I didn't see any mention of the fact that for most disks there
> isn't a way to erase revectored (i.e., replaced) blocks.
Good insight! All the more reason to never have unencrypted material of
any size on disk or in memory (suppose a virtual memory block was
revectored).
Re: How many overwrites for secure erase? 
Linear Mode
