From kde-core-devel Fri May 26 20:11:44 2000 From: Waldo Bastian Date: Fri, 26 May 2000 20:11:44 +0000 To: kde-core-devel Subject: Re: Fwd: Re: kdelibs/kio X-MARC-Message: https://marc.info/?l=kde-core-devel&m=95937320229236 On Fri, 26 May 2000, Andreas Pour wrote: > David Faure wrote: > > > > Hmmm... > > > > ----- Forwarded message from Waldo Bastian ----- > > > > From: Waldo Bastian > > 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 : > > > // 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