mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: Roy Sigurd Karlsbakk <roy@karlsbakk.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: secure erasure of files?
Date: Sun, 17 Feb 2002 22:19:47 +0100	[thread overview]
Message-ID: <20020217211947.GA17457@ii.uib.no> (raw)
In-Reply-To: <200202121326.g1CDQct12086@Port.imtp.ilyichevsk.odessa.ua> <Pine.LNX.4.30.0202121431560.18694-100000@mustard.heime.net>
In-Reply-To: <Pine.LNX.4.30.0202121431560.18694-100000@mustard.heime.net>

On Tue, Feb 12, 2002 at 02:33:47PM +0100, Roy Sigurd Karlsbakk wrote:
> > IMHO overwriting with /dev/zero or /dev/random is sufficient.
> > Recovering data after that falls into urban legend category :-)
> 
> I know of personal experience that the company ibas (http://www.ibas.com)
> have, in lab, recovered data overwritten >30 times. To recover data
> overwritten from /dev/zero is done in minutes.
> 

Interessting, but according to the following newsposting (in
Norwegian) IBAS is clearly stating that they don't know of any
documented methods to read back overwritten data, or know of anyone
who are able to do this.


   -jf

-----------------------------------------------------------------------------
Path: nntp.uib.no!uio.no!nntp.uio.no!not-for-mail
From: "Erik Andersen" <Erik@Andersen.tf>
Newsgroups: no.fag.jus.it
Subject: Re: Loggføring av bevegelser på  Internett
Date: Thu, 22 Mar 2001 10:17:50 +0100
Message-ID: <99cg5n$8ur$1@readme.uio.no>
Reply-To: "Erik Andersen" <Erik@Andersen.tf>
Xref: nntp.uib.no no.fag.jus.it:387

Med tillatelse fra FoU-sjefen gjengir jeg hans svar i sin helhet:



Jeg skal forsøke å svare på dine spørsmål:

Det korte svaret er: Nei det er ikke mulig å lese data som virkelig fysisk
er blitt overskrevet.

Imidlertid er grunnen til dette litt annerledes en det du beskriver.  For å
snakke fornuftig om dette er det først nødvendig med forståelse av hva et
bit på en HD er. En HD opererer ikke med individuelle bit, men med
flux-endringer. Flux retning er enkelt fortalt hvorvidt magnet-feltet på
disken peker mot eller med klokka (CW eller CCW). Så en flux endring er
altså en endring fra f.eks CW til CCW flux retning. Mapping mellom flux
endringer er ikke en-til-en. Det betyr at man IKKE benytter CW=0, CCW=1. I
stedet gir en enkelt.flux-endring opphav til 2.5 til 3 bit. I tillegg
benytter disken sekvens detektering. Dvs. at den ikke prøver å dekode
bit'ene hver for seg, men i stedet ser på en hel sekvens (typisk 4096 bit =
sektor).

Denne sekvensdetekteringen disken gjør ligner mye på hvordan vi leser en
dårlig telefax. Hvis vi forsøker å lese faxen bokstav for bokstav kan vi
f.eks lett forveksle en a med en o. Hvis denne bokstaven er en del av ordet
'bank', og vi tolker bokstav for bokstav ender vi med ordet 'bonk'.  Hvis vi
ser på hele ordet (sekvensen med bokstaver) kan vi se at det mest
sannsynlige ordet er 'bank'.

Det man kan si er at man etter en overskriving kan måle hvor sterke de
gamle dataene er i forhold til de nye. Det betyr at alle 'gamle' signaler
faktisk ikke forsvinner. Våre undersøkelser viser imidlertid at det ikke
finnes noen beskrivelser i litteraturen om hvordan man kan omdanne disse
signalrestene til de opprinnelige dataene.

Det kan synes som at dette krever banebrytende oppdagelser i en rekke
disipliner: Ikke-linjær analyse og modellering, lavt-støyende elektronikk
(cryo-elektronikk), datamaskin teknologi (superraske tallknusere).

Og det var det lange (kompliserte) svaret :)

Det som er sikkert: Ibas kjenner ikke til dokumenterte metoder,
vitenskapelige miljøer eller kommersielle tjenester som utføre eller
demonstrere lesing av overskrevne data.

--
Thor Arne Johansen
Avdelingssjef FoU, Ibas AS



Han har nå lagt til følgende:


Det er imidlertid på sin plass å nevne at dette er et tema
hvor de 'lærde' strides. Dvs. det finnes enkelte som mener at det er mulig
å lese overskrevne data. Men vi har som sagt ikke kunnet finne noe
vitenskaplig dokumentasjon eller beskrivelser av hvordan dette kan
gjøres.

-----------------------------------------------------------------------------


  -jf

  reply	other threads:[~2002-02-17 21:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200202121326.g1CDQct12086@Port.imtp.ilyichevsk.odessa.ua>
2002-02-12 13:33 ` Roy Sigurd Karlsbakk
2002-02-17 21:19   ` Jan-Frode Myklebust [this message]
2002-02-19 12:54     ` Jens Schmidt
2002-02-19 14:24       ` Richard B. Johnson
2002-02-21  2:56         ` Petro
2002-02-21  3:20           ` M. Edward Borasky
2002-02-21 17:01             ` Holger Lubitz
2002-02-26  3:39             ` Petro
2002-02-19 16:19 Jesse Pollard
  -- strict thread matches above, loose matches on Subject: below --
2002-02-19 14:48 Roy Sigurd Karlsbakk
2002-02-19 17:32 ` Rogier Wolff
2002-02-19 17:59   ` Martin J. Bligh
2002-02-19 18:48     ` Rogier Wolff
2002-02-19 20:01       ` Andreas Dilger
2002-02-19 23:13 ` Roy Sigurd Karlsbakk
2002-02-12 21:14 Torrey Hoffman
2002-02-12 13:12 Roy Sigurd Karlsbakk
2002-02-12 13:41 ` Davidovac Zoran
2002-02-12 14:03   ` Padraig Brady
2002-02-12 15:55   ` Andreas Ferber
2002-02-12 19:47     ` Jan Hudec
2002-02-12 20:25       ` Andrew Morton
2002-02-13  0:03         ` Jeff Garzik
2002-02-13  9:33     ` Helge Hafting
2002-02-13 18:27       ` Mike Fedyk
2002-02-13  0:36 ` Tom Vier
2002-02-13  0:45   ` Jeff Garzik
2002-02-20 15:34 ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020217211947.GA17457@ii.uib.no \
    --to=janfrode@parallab.uib.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roy@karlsbakk.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®