public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: the grugq <grugq@hcunix.net>
To: Hans Reiser <reiser@namesys.com>
Cc: Jamie Lokier <jamie@shareable.org>,
	Valdis.Kletnieks@vt.edu, Pavel Machek <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH - ext2fs privacy (i.e. secure deletion) patch
Date: Sat, 07 Feb 2004 09:55:36 +0000	[thread overview]
Message-ID: <4024B618.2070202@hcunix.net> (raw)
In-Reply-To: <40247A63.1030200@namesys.com>

Sure, but to a large extent it depends on your threat model. If you say 
"an extremely well funded government entity wants to examine your hard 
drive" then they will have access to insane technologies like electron 
microscopes. This makes any software solution to secure deletion 
practically impossible (if we trust the literature).

If, on the other hand, we have a threat model of, say, the police, then 
things are very different. In the UK, there is a law which requires you 
to turn over your encryption keys when the court demands them. The 
police have a tactic for extracting keys which involves physical 
violence and intimidation. These are very effective against encryption. 
However, the police do not have access to hardware based analysis 
technologies, they are just too expensive. So, while they can recover 
something that has been encrypted, they can't recover something that has 
been securely deleted. (Not without begging the .gov to perform a 
hardware analysis, something which would be quite unlikely in the normal 
course of events).

The majority of forensic analysis is performed with software tools on a 
bit image of the hard drive. If this bit image doesn't contain the data, 
the software tools won't see it, and the forensic analysis will fail. I 
would suggest adding secure deletion, because it does provide a pretty 
good level of protection. It is not a 100% solution, but neither is 
encryption. The two in combination are complementary technologies.


peace,

--gq


Hans Reiser wrote:
> There is an extensive literature on how you can recover deleted files 
> from media that has been erased a dozen times, but breaking encryption 
> is harder.  It is more secure to not put the data on disk unencrypted at 
> all is my point.....
> 
> Hans
> 
> the grugq wrote:
> 
>> Well, I think secure deletion should be an option for everyone. Using 
>> encryption is a data hiding technique, you prevent people for 
>> detemining what sort of data is being stored there. Now, admittedly I 
>> dont know at what level the reiser4 encryption appears, but I would 
>> think its safer to have complete erasure when a file deleted 
>> regardless of how well protected its contents were.
>>
>> just a thought.
>>
> 
> 

  reply	other threads:[~2004-02-07  9:58 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-28 16:30 PATCH - ext2fs privacy (i.e. secure deletion) patch the grugq
2004-02-03 22:20 ` Pavel Machek
2004-02-04  0:33   ` the grugq
2004-02-04  0:43     ` Pavel Machek
2004-02-04  0:48       ` the grugq
2004-02-04  0:55         ` Pavel Machek
2004-02-04  0:58           ` the grugq
2004-02-04  1:10             ` Mike Fedyk
2004-02-04  6:29       ` Theodore Ts'o
2004-02-04 13:08         ` the grugq
2004-02-04 17:05           ` Bill Davidsen
2004-02-04 17:14             ` Valdis.Kletnieks
2004-02-04 23:47               ` Bill Davidsen
2004-02-04 23:51                 ` the grugq
2004-02-05  1:48                 ` the grugq
2004-02-05  4:38                 ` Valdis.Kletnieks
2004-02-07  3:30                   ` Bill Davidsen
2004-02-05  3:35               ` Theodore Ts'o
2004-02-06  0:00                 ` the grugq
2004-02-12 22:59         ` Robert White
2004-02-13  3:41           ` Jamie Lokier
2004-02-13 21:30             ` Robert White
2004-02-18  3:48             ` Bill Davidsen
2004-02-18  9:48               ` Jamie Lokier
2004-02-17 12:00           ` Pavel Machek
2004-02-04  3:20     ` Valdis.Kletnieks
2004-02-07  0:20       ` Jamie Lokier
2004-02-07  1:15         ` Hans Reiser
2004-02-07  1:29           ` the grugq
2004-02-07  5:40             ` Hans Reiser
2004-02-07  9:55               ` the grugq [this message]
2004-02-07 10:47                 ` Jamie Lokier
2004-02-07 11:02                   ` the grugq
2004-02-07 11:09                     ` Jamie Lokier
2004-02-07 11:46                       ` the grugq
2004-02-07 12:01                         ` Jamie Lokier
2004-02-07 16:52                           ` Hans Reiser
2004-02-07 17:22                           ` Pavel Machek
2004-02-08  0:04                             ` Jamie Lokier
2004-02-07 16:50                         ` Hans Reiser
2004-02-07 16:44                   ` Hans Reiser
2004-02-09 12:07                     ` Edward Shishkin
2004-02-10  7:18                       ` Hans Reiser
2004-02-07  2:17           ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2004-02-07  9:55 Albert Cahalan

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=4024B618.2070202@hcunix.net \
    --to=grugq@hcunix.net \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=reiser@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox