All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jurgen Botz <jurgen@botz.org>
To: Hans Reiser <reiser@namesys.com>
Cc: KELEMEN Peter <Peter.Kelemen@cern.ch>, reiserfs-list@namesys.com
Subject: Re: secure delete?
Date: Mon, 22 Mar 2004 17:37:33 -0800	[thread overview]
Message-ID: <405F94DD.80004@botz.org> (raw)
In-Reply-To: <405AD9B5.80102@namesys.com>

Somebody asked:
 > Is there a way to securely delete a file or directory in
 > ReiserFS ... ?

Hans Reiser answered:
> Encrypt everything is what will work best.

This actually isn't a good answer... the problem domains of
"secure my data" and "don't let anyone recover this data I'm
removing" are sufficiently different that one mechanism
probably can't address them both.

Specifically, encryption has the limitation that some of the
time you want your data un-encrypted (so that you can
access it) and that even when the data is encrypted the key
is recoverable by various means (like rubber-hose crypt-
analysis if nothing else.)

If I store a file on my encrypted filesystem and then
decide that this file is dangerous, and I'd rather not leave
any evidence of it ever having been there, removing it won't
be enough any more than it would be if the filesystem had
not been encrypted in the first place, because:

- If I remove it, it might still be recoverable by anyone
   who has access to my computer while the filesystem is
   mounted (i.e. decrypted).

- If I unmount the filesystem (so that it's encrypted) and
   "never mount it again" someone can still discover the key,
   which is presumably stored on disk somewhere and beat the
   passphrase out of me.

- I could remove the file containing the key, but then I'm
   back to needing a secure delete capability for that!

In short, secure delete capability is needed.  If the file-
system makes it impossible for an application program to
implement this (because of data logging) then the filesystem
itself needs to provide this capability.

:j




Why do you want to encrypt all data?  Well, one reason is to
protect against your machine being stolen and the thief then
having access to your data.

Why do you want secure delete?  One reason is the same as the
above, and encryption takes care of this.  But another reason
is to protect yourself from overzealous law-enforcement, and
probably encryption can't help you there because you won't
have time to

  parent reply	other threads:[~2004-03-23  1:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-19 10:13 secure delete? Peter Foldiak
2004-03-19 11:01 ` Cami
     [not found]   ` <20040319110748.GA30491@chihiro.cern.ch>
2004-03-19 11:29     ` Hans Reiser
2004-03-19 11:51       ` Peter Foldiak
2004-03-19 16:04         ` Hubert Chan
2004-03-19 17:54           ` Bennett Todd
2004-03-20 23:45         ` The Amazing Dragon
2004-03-20 23:59           ` Andrew Clausen
2004-03-23  1:37       ` Jurgen Botz [this message]
2004-03-23  2:49         ` Valdis.Kletnieks
2004-03-23  6:22         ` Hans Reiser
2004-03-23  6:40           ` Hendrik Visage
2004-03-23 16:34           ` Jürgen Botz
2004-03-23 21:03           ` Jason Holt
2004-03-23 21:40             ` Hans Reiser
2004-03-24  2:36               ` Tom Vier
2004-03-24  6:26                 ` Jason Holt
2004-03-24  7:39                   ` Hans Reiser
2004-03-24 15:38                     ` Jason Holt
2004-03-29 12:59                       ` Hans Reiser
2004-03-24  7:54                   ` Hans Reiser
2004-03-24  8:04                     ` Vladimir Saveliev
2004-03-24 23:18                       ` Enrique Perez-Terron
2004-03-25  3:49                         ` Tom Vier
2004-03-25 13:00                           ` Vladimir Saveliev
2004-03-24 18:20           ` Valdis.Kletnieks
2004-03-25  3:16             ` Tom Vier
2004-03-30  1:10               ` Valdis.Kletnieks
  -- strict thread matches above, loose matches on Subject: below --
2004-03-30  2:13 Burnes, James

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=405F94DD.80004@botz.org \
    --to=jurgen@botz.org \
    --cc=Peter.Kelemen@cern.ch \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.