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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200611011720.kA1HKrJc005424@agora.fsl.cs.sunysb.edu>
Date:	Wed, 1 Nov 2006 12:20:53 -0500
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Nikolai Joukov <kolya@...sunysb.edu>
Cc:	Ric Wheeler <ric@....com>, 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? 

Also of note is that some government standards for data destruction (e.g.,
NIST and NISPOM) specifically require that files be overwritten with a
certain pattern, and even multiple times for different security levels.  So
those sites who have to comply with such standards won't be able to use an
encryption-only solution to discard data.

The other problem with crypto on persistent media is that you can't easily
predict how secure data will be in the really long run, say years or
decades.  Suppose an attacker manages to get their hands on a crypto disk
whose keys were destroyed.  With today's technology, the attacker might not
be able to break the crypto.  But wait 10 years, and who knows what kinds of
computing powers we will have then.  (Even ten-year old data, if recovered,
could still be highly valuable -- eg., top-secret military files).

Crypto is great.  But overwriting data even just a couple of times w/ random
bits, elevates the level of attack required to recover such data, well past
crypto.

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