linux-ext4 - Re: Shred mount option for ext4?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Nov 2006 11:52:42 -0500 (EST)
From:	Nikolai Joukov <kolya@...sunysb.edu>
To:	Ric Wheeler <ric@....com>
cc:	Andreas Dilger <adilger@...sterfs.com>,
	Erik Mouw <erik@...ddisk-recovery.com>,
	Samuel Tardieu <sam@...1149.net>, linux-ext4@...r.kernel.org
Subject: Re: Shred mount option for ext4?

> >>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).

Encryption is another possible secure deletion solution.  Usually it is
used by systems that already encrypt the data anyways.  In that case the
key management and run-time overhead costs are already paid.

> >The drawback is there is a runtime overhead to encrypt/decrypt the file

The difference is that in case of encryption there are overheads for read
and write operations whereas in case of overwriting there are overheads
only for infrequent unlink/truncate operations.

> I think that having the data encrypted on disk is a generically useful
> feature, but in this case it might not count for much since the key is
> stored right next to the data in that EA...

Agreed.  Key management is a big issue in any encryption system.  In this
particular solution the key management is simple but there is also no
real protection of the live data.

Nikolai.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html