Date: Thu, 20 May 1999 20:13:31 +1000 (EST) From: Darren Reed <darrenr@reed.wattle.id.au> To: gsutter@pobox.com (Gregory Sutter) Cc: darrenr@reed.wattle.id.au, wes@softweyr.com, imp@harmony.village.org, ilmar@ints.ru, posix1e@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: secure deletion Message-ID: <199905201013.UAA12994@avalon.reed.wattle.id.au> In-Reply-To: <19990520023416.A46301@001101.zer0.org> from Gregory Sutter at "May 20, 99 02:34:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
In some email I received from Gregory Sutter, sie wrote: > On Thu, May 20, 1999 at 04:42:18PM +1000, Darren Reed wrote: > > In some email I received from Wes Peters, sie wrote: > > > Warner Losh wrote: > > > > > > > > Does it doe the DoD recommended patter of deletion? That is overwrite > > > > > > The standard used to be 100 overwrites of 0xe5 then 0x5e, but they > > > changed the standard just as I was leaving the defense industry in > > > 1991. Does Posix or SUS have anything to say about this? > > > > I'd worry about this sort of thing when and if FreeBSD is ever used for > > storing of (officially) classified/confidential material and even then, > > the solution is likely to be to take a hammer or drill to the disks. > > If someone is going to be coding this, it would be better to code it > correctly the first time than have to add it later. It seems easy > enough to add--after the first bit compare, should that be enabled, > have a second for 'quick' or 'secure' zeroing. So properly in this case means using memset rather than bzero and a variable number of passes, correct (with perhaps a programmable pattern) ? Being able to verify that the file's contents get nuked to the value the pass is meant to have set it to might be worthwhile. After the first pass, I'm not sure that there is any meaningful addition to the security of the erased data. Access to sophisticated machinery is required to circumvent it, but if that is what you're trying to protect against then why fool yourself by deploying a level of security that is known to be less than Government bodies who physically destroying disks. I don't think you understand the problem properly if you think it can be coded "correctly" - what you're proposing just isn't possible via software where one overwrite is pretty much as good as multiple. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905201013.UAA12994>