[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fwd: Re: kdelibs/kio
From:       Waldo Bastian <bastian () suse ! de>
Date:       2000-05-26 20:11:44
[Download RAW message or body]

On Fri, 26 May 2000, Andreas Pour wrote:
> David Faure wrote:
> > 
> > Hmmm...
> > 
> > ----- Forwarded message from Waldo Bastian <bastian@kde.org> -----
> > 
> > From: Waldo Bastian <bastian@kde.org>
> > To: kde-cvs@max.tat.physik.uni-tuebingen.de
> > Subject: Re: kdelibs/kio
> > Date:   Thu, 25 May 2000 19:16:42 -0700
> > 
> > On Thu, 25 May 2000, CVS by faure wrote:
> > > kdelibs/kio kshred.cpp,1.6,1.7 kshred.h,1.3,1.4
> > > Author: faure
> > > CVSROOT: /home/kde
> > > Thu May 25 21:36:28 UTC 2000
> > > Update of /home/kde/kdelibs/kio
> > > cvs.kde.org hosted by sourceforge.net
> > >
> > > Modified Files:
> > >       kshred.cpp kshred.h
> > > Log Message:
> > > Contributed by Andreas Pour <pour@mieterra.com> :
> > > // UPDATED: this function now uses 35 passes based on the the article
> > > // Peter Gutmann, "Secure Deletion of Data from Magnetic and Solid-State
> > > // Memory", first published in the Sixth USENIX Security Symposium
> > > // Proceedings, San Jose, CA, July 22-25, 1996 (available online at
> > > // http://rootprompt.org/article.php3?article=473)
> > 
> > So it writes 35 times a lot of grabage to the linux kernel... which uses
> > write caching and only writes the last version to disk... repeat after me
> > "faked security".
> 
> It's not that bad, as a "flush()" is done after every write (this is
> proven by the length of time it takes to do the shred -- even a 3K file
> takes about 10 seconds).  However, there is still the problem of caching
> in the disk cache, and I don't know if Linux flushes the drive cache (as
> opposed to memory) on a flush.  I suggested to David that we do a
> sleep(1) after each flush to give the drive a chance to flush its
> buffers to disk.  I suppose one could improve the likelihood of that
> happening by doing a bunch of reads on the device during the "sleep"
> period.

Sure if you do enough stuff which you have no idea of what it does, you will
surely get the desired result after some time. Monkeys.. typewriters...
shakespear.
   
> In the end, all we can do is the best we can do.

And when that is not enough we shouldn't be doing it all.

> It's certainly not
> "faked security", although it's not 100% guaranteed to be impossible to
> reconstruct the file either.

I think it is 0% guaranteed. I think you can't even guarantee that grep
/dev/hda doesn't give you your, oh so confidental, data back. 

Luring people into a false sense of security is worse than having no security
at all.

Cheers,
Waldo

[prev in list] [next in list] [prev in thread] [next in thread]