From: Andreas Dilger <adilger@clusterfs.com>
To: Nikolai Joukov <kolya@cs.sunysb.edu>
Cc: Erik Mouw <erik@harddisk-recovery.com>,
Samuel Tardieu <sam@rfc1149.net>,
linux-ext4@vger.kernel.org
Subject: Re: Shred mount option for ext4?
Date: Thu, 2 Nov 2006 00:17:00 +0800 [thread overview]
Message-ID: <20061101161700.GA5212@schatzie.adilger.int> (raw)
In-Reply-To: <Pine.GSO.4.53.0610311444550.4220@compserv1>
On Oct 31, 2006 15:14 -0500, Nikolai Joukov wrote:
> 1. One of the patches performs N overwrites with configurable patterns
> (can comply with NIST and NISPOM standards). Because of the transaction
> compaction we had to separately add overwriting as separate transactions.
> Fortunately, the whole procedure is still atomic due to the orphan list.
> The problem that we have right now is per-file syncing of dirty data
> buffers between overwrites. We sync the whole device at the moment.
Did anyone discuss doing this with crypto instead of actually overwriting
the whole file? It would be pretty easy to store a per-file crypto key
in each inode as an EA, then to "delete" the file all that would be
needed would be to erase the key in a secure matter (which is a great
deal easier because inodes don't move around on disk).
The drawback is there is a runtime overhead to encrypt/decrypt the file
data, but honestly, if people care about secure deletion don't they also
care about security of the undeleted data also? By having an (unknown
to the user) per-file crypto key then if the file is deleted the user
can also plausibly deny the ability to recover the file data even if
they are forced to surrender their key.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
next prev parent reply other threads:[~2006-11-01 16:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-31 20:14 Shred mount option for ext4? Nikolai Joukov
2006-11-01 16:17 ` Andreas Dilger [this message]
2006-11-01 16:38 ` Ric Wheeler
2006-11-01 16:52 ` Nikolai Joukov
2006-11-01 17:20 ` Erez Zadok
2006-11-01 16:57 ` Wolber, Richard C
2006-11-20 10:52 ` Rupesh Thakare
-- strict thread matches above, loose matches on Subject: below --
2006-10-31 10:36 Samuel Tardieu
2006-10-31 12:32 ` Erik Mouw
2006-10-31 13:02 ` Samuel Tardieu
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=20061101161700.GA5212@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=erik@harddisk-recovery.com \
--cc=kolya@cs.sunysb.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=sam@rfc1149.net \
/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;
as well as URLs for NNTP newsgroup(s).