From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>, linux-kernel@vger.kernel.org
Cc: kentborg@borg.org, alan@lxorguk.ukuu.org.uk, jgarzik@pobox.com
Subject: Re: Where is ext2/3 secure delete ("s") attribute?
Date: Fri, 22 Nov 2002 08:13:12 -0600 [thread overview]
Message-ID: <200211220813.12136.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <200211220122.gAM1MQY305783@saturn.cs.uml.edu>
On Thursday 21 November 2002 07:22 pm, Albert D. Cahalan wrote:
> Alan Cox writes:
> > On Thu, 2002-11-21 at 19:05, Kent Borg wrote:
> >> Another example of why this needs to be done in the file system. (And
> >> that help is sometimes needed from the "disk" particularly in cases
> >> like flash IDE rives.)
> >
> > The file system can't do it
> > The flash device won't give you the info to do it
> > The ide disk wont give you the info to do it
>
> That's being an idealist. You can protect against everybody
> except the NSA and the disk manufacturer. Most likely they'd
> need to spend lots of money in a clean room to get your data.
incomplete list....
NSA
DoD
Homeland Defense gestapo
disk manufacturer
anybody willing to spend about $1000-$5000.
And I'm not sure it is impossible to just reset the bad block list either.
I've been able to do that to SCSI drives in the past, so I think it is
still possible to do.
> Forget the shred program. It's less useful than having the
> filesystem simply zero the blocks, because it's slow and you
> can't be sure to hit the OS-visible blocks. Aside from encryption,
> the useful options are:
>
> 1. plain old rm (protect from users)
> 2. filesystem clears the blocks (protect from root/kernel)
> 3. physically destroy the disk (protect from NSA & manufacturer)
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next prev parent reply other threads:[~2002-11-22 14:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-22 1:22 Where is ext2/3 secure delete ("s") attribute? Albert D. Cahalan
2002-11-22 1:30 ` Jeff Garzik
2002-11-22 2:41 ` Albert D. Cahalan
2002-11-22 4:39 ` Jeff Garzik
2002-11-22 5:55 ` Albert D. Cahalan
2002-11-22 7:12 ` Ingo Oeser
2002-11-22 13:38 ` Alan Cox
2002-11-22 13:27 ` Nikita Danilov
2002-11-22 2:06 ` Mike Dresser
2002-11-22 14:13 ` Jesse Pollard [this message]
2002-11-22 21:31 ` Krzysztof Halasa
-- strict thread matches above, loose matches on Subject: below --
2002-11-24 6:40 Albert D. Cahalan
2002-11-21 18:20 Marc-Christian Petersen
2002-11-21 22:43 ` Harald Arnesen
2002-11-21 17:52 Kent Borg
2002-11-21 18:24 ` Jeff Garzik
2002-11-21 18:39 ` Kent Borg
2002-11-21 19:20 ` Alan Cox
2002-11-21 19:05 ` Kent Borg
2002-11-21 20:28 ` Alan Cox
2002-11-21 19:14 ` Jeff Garzik
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=200211220813.12136.pollard@admin.navo.hpc.mil \
--to=pollard@admin.navo.hpc.mil \
--cc=acahalan@cs.uml.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=kentborg@borg.org \
--cc=linux-kernel@vger.kernel.org \
/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