secure delete?

secure delete?

[Peter Foldiak]

Is there a way to securely delete a file or directory in ReiserFS or
Reiser4? By "securely delete" I mean the kind of thing one of the PGP
tools tries to do (i.e. overwrite the disk area with random bits several
times). Of course this only works if the information is not moved around
physically a lot (i.e. at all). Could secure delete work? Peter

Re: secure delete?

[Cami]

> Is there a way to securely delete a file or directory in ReiserFS or
> Reiser4? By "securely delete" I mean the kind of thing one of the PGP
> tools tries to do (i.e. overwrite the disk area with random bits several
> times). Of course this only works if the information is not moved around
> physically a lot (i.e. at all). Could secure delete work? Peter

srm will do the trick (securerm)..

Cami

Re: secure delete?

[Hans Reiser]

Encrypt everything is what will work best.

-- 
Hans

Re: secure delete?

[Peter Foldiak]

On Fri, 2004-03-19 at 11:29, Hans Reiser wrote:
> Encrypt everything is what will work best.

I guess you would have to use an encrypted swap area as well, right?
Would the performance be ok for that? Peter

Re: secure delete?

[Hubert Chan]

>>>>> "Peter" == Peter Foldiak <Peter.Foldiak@st-andrews.ac.uk> writes:

Peter> On Fri, 2004-03-19 at 11:29, Hans Reiser wrote:
>> Encrypt everything is what will work best.

Peter> I guess you would have to use an encrypted swap area as well,
Peter> right?  Would the performance be ok for that? Peter

If you have any sensitive information, then encrypted swap is a good
idea.  I'm using encrypted swap, and I'm not experiencing any noticeable
performance hits.  But I have sufficient RAM (374MB) so it doesn't swap
often.  If your machine swaps a lot, I would assume that performance
would be bad (but it's probably already bad if you swap a lot).

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: secure delete?

[Bennett Todd]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

> [...] I'm using encrypted swap, and I'm not experiencing any
> noticeable performance hits. But I have sufficient RAM (374MB) so
> it doesn't swap often.

Not to imply that anybody here doesn't already know this, but just a
general comment: no matter how much memory you have, it's always a
good idea to have at least some swap allocated.

Besides allowing VM to grow past real memory via serious paging,
which as you say has depressing performance, some swap is also good
because it lets the OS page out VM that's really unused. No matter
how much memory you have, this is good for performance, because
Linux is _terrific_ at making productive use of all leftover RAM for
disk buffering.

I generally allocate 128MB for swap no matter how much memory I
have, but then I don't run X, and run an absolutely minimized list
of daemons. On an untuned system with X and a big horkin' desktop,
I'd probably fling a gig of swap at it just to help make sure that
all those zillions of unused daemons can get the heck out of my RAM.

-Bennett

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: secure delete?

[The Amazing Dragon]

> From: Peter Foldiak <Peter.Foldiak@st-andrews.ac.uk>
> On Fri, 2004-03-19 at 11:29, Hans Reiser wrote:
> > Encrypt everything is what will work best.
> 
> I guess you would have to use an encrypted swap area as well, right?
> Would the performance be ok for that? Peter

How many orders of magnitude are disks slower than processors/memory?
Encryption algorithms are designed to be fast to compute. Even the
slowest processors of today will be able to encrypt/descrypt data much
faster than the maximum throughput of hard disks. With swap you're going
to be drowned by seeks anyway.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM@cs.pdx.edu      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Re: secure delete?

[Andrew Clausen]

On Sat, Mar 20, 2004 at 03:45:08PM -0800, The Amazing Dragon wrote:
> > I guess you would have to use an encrypted swap area as well, right?
> > Would the performance be ok for that? Peter
> 
> How many orders of magnitude are disks slower than processors/memory?
> Encryption algorithms are designed to be fast to compute. Even the
> slowest processors of today will be able to encrypt/descrypt data much
> faster than the maximum throughput of hard disks. With swap you're going
> to be drowned by seeks anyway.

I don't think this is relevant.  The question probably wasn't "how much
will it slow down swap read/writes" but rather "how much will it slow
down my system in general".

You may be correct in observing that encryption/decryption won't make a
big difference in the latency on swap I/O.  (If you are getting a good
stream out of a hard disk, it might be hard for crypto to keep up, but
this is unlikely for swap)  However, it still may significantly increase
CPU usage, and hence reduce the amount of CPU available to other
processes (that aren't waiting for swap I/O).  It's not like I/O in
Linux is synchronous!

Cheers,
Andrew

Re: secure delete?

[Jurgen Botz]

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

Re: secure delete?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Mon, 22 Mar 2004 17:37:33 PST, Jurgen Botz said:

> 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

Gee thanks.  I had to get out the glass cleaner and clean the soda off
the monitor. ;)

But seriously, for many people, this is a serious and major component of their
threat model - and in fact, this was part of why Phil Zimmerman did PGP. (For
that matter, I have to admit that on any given day, I swing between "My
government sold out and admitted the terrorists won by passing the Patriot Act
and CAPPS II", and "My government made sure(*) the terrorists were able to do it
so they would have an excuse to pass the Patriot Act and CAPPS II".. so it
isn't just repressive regimes in small banana republics that we need worry about).

(*) And no, I don't need a tinfoil helmet for a conspiracy theory - just ask yourself
why Cheney's old pals at Halliburton are making billions, why we still haven't caught
our former employee Osama bin Laden, and why the FBI admits they dropped the
ball on all the terrorist info they had before 9/11, but still wants MORE surveillance
ability.  I'll stop there. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: secure delete?

[Hans Reiser]

Secure delete doesn't work against people who have the necessary 
equipment to scan the media and find remnants due to track misalignment.

-- 
Hans

Re: secure delete?

[Hendrik Visage]

On Tue, Mar 23, 2004 at 09:22:58AM +0300, reiserfs mailing list wrote:
> 
> Secure delete doesn't work against people who have the necessary 
> equipment to scan the media and find remnants due to track misalignment.

Which means in general language that all bicycles weighs 50 pounds:

a 20 pound bicycle needs a 30 pound lock
a 30 pound bicycle needs a 20 pound lock
a 40 pound bicycle needs a 10 pound lock
and a 50 pound bicycle needs no lock!!!

The specs for goverment etc. says somewhere (and Sun etc. somehow adheres to it)
that a failed disk's platter stays behind, and you just send the electronics
back to the manufacturer.

So: the question that must be answered is: How much do your bicycle weighs?
How large would your lock need to be?

IN geek talk: What's the worth of the data? What equipment can the other side
afford? Will your protection be uneconomical enough for them not to bother
about your protections?

Refer to Bruce Schneier's books on security and the business choices about it.

Hendrik

Re: secure delete?

[Jürgen Botz]

Hans Reiser wrote:
> Secure delete doesn't work against people who have the necessary 
> equipment to scan the media and find remnants due to track
 > misalignment.

No attempts at security are ever perfect; but there are "pretty good"
approaches to protecting yourself from various threat-models.  A good
secure delete algorithm (see Peter Gutmann's 1995 paper on the topic
@ <http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html>) is a
reasonable approach to a threat model that is distinctly different from
the threat models that are addressed by encryption.

And yes, it can work pretty well against people with the type of
expensive equipment you describe.

I don't know enough about Reiser4's plug-in architecture yet to know
if a secure delete method can be plugged-in (superficially it doesn't
seem like it can as-is), but one way or another it will be needed.

:j

-- 
Jürgen Botz               | While differing widely in the various
jurgen@botz.org           | little bits we know, in our infinite
                           | ignorance we are all equal. -Karl Popper

Re: secure delete?

[Jason Holt]

Secure deletion would be a very nice addition to the security features r4 has 
to offer.  After our discussions on the difficulty of getting things like 
shred to work with journalling filesystems, I wrote up a demo that I showed at 
a UUG meeting.  It's here:

http://www.lunkwill.org/tmp/delete/

I get different results every time I run it(!), but usually the last run
(where we create 6 files) produces lots of text on the "disk" even after
shredding.  I suspect that reiserfs would behave the same way.

So some way to ask the fs not to leave extra copies of blocks laying around,
or to securely delete the copies that it makes would be quite useful.

						-J

Re: secure delete?

[Hans Reiser]

Jason Holt wrote:

>Secure deletion would be a very nice addition to the security features r4 has 
>to offer.  After our discussions on the difficulty of getting things like 
>shred to work with journalling filesystems, I wrote up a demo that I showed at 
>a UUG meeting.  It's here:
>
>http://www.lunkwill.org/tmp/delete/
>
>I get different results every time I run it(!), but usually the last run
>(where we create 6 files) produces lots of text on the "disk" even after
>shredding.  I suspect that reiserfs would behave the same way.
>
>So some way to ask the fs not to leave extra copies of blocks laying around,
>or to securely delete the copies that it makes would be quite useful.
>
>						-J
>
>
>
>  
>
Well, I am not opposed to it, I am just not putting it at the top of my 
funding priorities.;-)

Right now we want to complete our darpa contract feature list and get 
everything debugged....  even if we have already spent all of darpa's 
money....

-- 
Hans

Re: secure delete?

[Tom Vier]

someone on l-k recently suggested storing a unique key in the inode. then
only the inode needs to be wiped to render all data blocks (including
strays) meaningless. i don't know how it was suggested this would be
implimented, but i would suggest generating the key at chattr +s time,
reading the file, encrypting it, and writing it back. that of course could
leave stray data, which is why new files should inherit +s from the dir
they're in. (i don't know what the rules are about +s inheritance - maybe it
needs chmod g+s on the dir).

btw, i wrote a file wiper which does blk and char devs, and regular files.
shameless plug:

http://wipe.sf.net/

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: secure delete?

[Jason Holt]

On Tue, 23 Mar 2004, Tom Vier wrote:
> btw, i wrote a file wiper which does blk and char devs, and regular files.
> shameless plug:

I'm curious whether it would work better than shred with the script I posted
earlier.  Would you mind trying it?  How's about with reiserfs?

						-J

Re: secure delete?

[Hans Reiser]

Jason Holt wrote:

>On Tue, 23 Mar 2004, Tom Vier wrote:
>  
>
>>btw, i wrote a file wiper which does blk and char devs, and regular files.
>>shameless plug:
>>    
>>
>
>I'm curious whether it would work better than shred with the script I posted
>earlier.  Would you mind trying it?  How's about with reiserfs?
>
>						-J
>
>
>
>  
>
I  liked Jason's script.  Maybe we should consider putting it in 
reiserfsprogs.  Haven't yet looked at Tom's tool.....

-- 
Hans

Re: secure delete?

[Hans Reiser]

Jason Holt wrote:

>On Tue, 23 Mar 2004, Tom Vier wrote:
>  
>
>>btw, i wrote a file wiper which does blk and char devs, and regular files.
>>shameless plug:
>>    
>>
>
>I'm curious whether it would work better than shred with the script I posted
>earlier.  Would you mind trying it?  How's about with reiserfs?
>
>						-J
>
>
>
>  
>
Oh but wait, I forgot, I think we have some reserved space that Jason's 
shred won't reach.  Vladimir, is that still true?

-- 
Hans

Re: secure delete?

[Vladimir Saveliev]

On Wed, 2004-03-24 at 10:54, Hans Reiser wrote:
> Jason Holt wrote:
> 
> >On Tue, 23 Mar 2004, Tom Vier wrote:
> >  
> >
> >>btw, i wrote a file wiper which does blk and char devs, and regular files.
> >>shameless plug:
> >>    
> >>
> >
> >I'm curious whether it would work better than shred with the script I posted
> >earlier.  Would you mind trying it?  How's about with reiserfs?
> >
> >						-J
> >
> >
> >
> >  
> >
> Oh but wait, I forgot, I think we have some reserved space that Jason's 
> shred won't reach.  Vladimir, is that still true?

no, it looks like currently reiserfs does not have reserved disk space

Re: secure delete?

[Jason Holt]

On Wed, 24 Mar 2004, Hans Reiser wrote:
> I  liked Jason's script.  Maybe we should consider putting it in 
> reiserfsprogs.  Haven't yet looked at Tom's tool.....

You might have misunderstood the script.  It doesn't do secure delete.  It
just demonstrates how shred is ineffective on journalling filesystems.

						-J

Re: secure delete?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Tue, 23 Mar 2004 09:22:58 +0300, Hans Reiser said:
> 
> Secure delete doesn't work against people who have the necessary 
> equipment to scan the media and find remnants due to track misalignment.

Notice that the people who have the necessary equipment and assume that the
adversaries are equally well-stocked don't seem to agree:

Canadian RCMP TSSIT OPS-II says: "Must first be checked for correct functioning
and then have all storage areas overwritten once with the binary digit ONE,
once with the binary digit ZERO and once with a single numeric, alphabetic or
special character, " (http://jya.com/rcmp2.htm)

American DoD 5220-22.M says: Overwriting all addressable locations with a
character, its complement, then a random character and verify.

That's our official government recommendation for what's sufficient when
we're throwing away stuff that the Other Guys might actually do this to.
I have to assume that if the DoD or RCMP thought this wasn't sufficient
to protect *our* secrets, they'd have a stricter standard.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: secure delete?

[Enrique Perez-Terron]

Hello all,

A few years ago a university administration staff member asked an
assistant to  wipe out all his files in preparation for retirement.
He got angry when he soon found his web searches in the browser history
and cache, and asked how is that possible.

No "secure" delete would have helped him, but standard delete would have
been fully adequate had he only known what to delete. There was no
chance in hell that anyone would engage in a block device scanning of
his abandoned disk, much less track alignment variation analysis.

Such are the vast majority of the cases.

Even moderate security is a challenge, and a "secure delete" facility is
one of the tools. Considering how the word processors create recovery
files, auto-saves, backups, how the documents get automatically indexed,
there are many parts of this equation.

On the other hand, it is not completely true that encryption does not
help against track alignment analysis because "they" can find the key
file and beat the passphrase out of me. Beating the passphrase out of me
can easily become quite expensive - not only for me :). In addition,
there is no guarantee that the writes of sensitive material will happen
with any larger misalignment than usual, to make those bits reliably
recoverable. Even though sophisticated methods can reveal up to twenty
layers of old data, they can only do so with an increasingly high bit
error rate. It does not take many bit errors to ruin the prospect of
decryption, except for the most outlandish recovery budgets.

So, even a fairly cheap and quick encryption system combined with a
"secure delete" facility makes it many orders of magnitude more
expensive to recover any information from the disk. While it is hardly
the first priority, there might still be many customers that will one
day be willing to pay for this.

Regards, 
Enrique

Re: secure delete?

[Tom Vier]

On Wed, Mar 24, 2004 at 01:20:47PM -0500, Valdis.Kletnieks@vt.edu wrote:
> That's our official government recommendation for what's sufficient when
> we're throwing away stuff that the Other Guys might actually do this to.
> I have to assume that if the DoD or RCMP thought this wasn't sufficient
> to protect *our* secrets, they'd have a stricter standard.

they do, complete destruction. that's what they do with secret stuff.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: secure delete?

[Tom Vier]

On Thu, Mar 25, 2004 at 12:18:08AM +0100, Enrique Perez-Terron wrote:
> So, even a fairly cheap and quick encryption system combined with a
> "secure delete" facility makes it many orders of magnitude more
> expensive to recover any information from the disk. While it is hardly
> the first priority, there might still be many customers that will one
> day be willing to pay for this.

i really like the idea of a per file key in the inode. the fs could wipe the
key field itself, using the gutmann method, without too much trouble (like
wiping the entire file from within the kernel; that could be gigs and take
hours).

could this be implimented using plugins?

also, it was mentioned that reiserfs doesn't reserve space. so all
structures (except the superblock and journal, of course) are dynamic and
regular files can overwrite old nodes? if so, then wipe could use a regular
file to wipe free space fairly effectively. if not, maybe i could use the
reiserfsprogs libs to figure out what blocks are free (before it's mounted
of course).

btw, anyone know what the block coherancy is in 2.6? if i write to a blkdev,
then mount it, will the fs driver see the writes? i know if the fs writes to
the blkdev, reading the blkdev from userspace can return stale cache. too
bad you can't do something like umount; bsync; (now safely read/write the
blkdev).

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: secure delete?

[Vladimir Saveliev]

Hello

On Thu, 2004-03-25 at 06:49, Tom Vier wrote:
> On Thu, Mar 25, 2004 at 12:18:08AM +0100, Enrique Perez-Terron wrote:
> > So, even a fairly cheap and quick encryption system combined with a
> > "secure delete" facility makes it many orders of magnitude more
> > expensive to recover any information from the disk. While it is hardly
> > the first priority, there might still be many customers that will one
> > day be willing to pay for this.
> 
> i really like the idea of a per file key in the inode. the fs could wipe the
> key field itself, using the gutmann method, without too much trouble (like
> wiping the entire file from within the kernel; that could be gigs and take
> hours).
> 
> could this be implimented using plugins?
> 
> also, it was mentioned that reiserfs doesn't reserve space. so all
> structures (except the superblock and journal, of course) are dynamic and
> regular files can overwrite old nodes? if so, then wipe could use a regular
> file to wipe free space fairly effectively. if not, maybe i could use the
> reiserfsprogs libs to figure out what blocks are free (before it's mounted
> of course).
> 
> btw, anyone know what the block coherancy is in 2.6? if i write to a blkdev,
> then mount it, will the fs driver see the writes?

No, it will not. Until blkdev flushes its changes.

> i know if the fs writes to
> the blkdev, reading the blkdev from userspace can return stale cache. too
> bad you can't do something like umount; bsync; (now safely read/write the
> blkdev).

Re: secure delete?

[Hans Reiser]

Jason Holt wrote:

>On Wed, 24 Mar 2004, Hans Reiser wrote:
>  
>
>>I  liked Jason's script.  Maybe we should consider putting it in 
>>reiserfsprogs.  Haven't yet looked at Tom's tool.....
>>    
>>
>
>You might have misunderstood the script.  It doesn't do secure delete.  It
>just demonstrates how shred is ineffective on journalling filesystems.
>
>						-J
>
>
>
>  
>
Well, actually now that I think about it, even if your script did what I 
had thought it did, it still wouldn't clear out the journal area if data 
logging was on.

If someone wants to fix this issue, they are welcome to do so and send 
us a patch.  Tom, can you resend your link to me in private email (I 
left it in russia....).

-- 
Hans

Re: secure delete?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Wed, 24 Mar 2004 22:16:16 EST, Tom Vier <tmv@comcast.net>  said:
> On Wed, Mar 24, 2004 at 01:20:47PM -0500, Valdis.Kletnieks@vt.edu wrote:
> > That's our official government recommendation for what's sufficient when
> > we're throwing away stuff that the Other Guys might actually do this to.
> > I have to assume that if the DoD or RCMP thought this wasn't sufficient
> > to protect *our* secrets, they'd have a stricter standard.
> 
> they do, complete destruction. that's what they do with secret stuff.

http://www.irwin.army.mil/ac/LSS/DoD_Publications.html

http://www.irwin.army.mil/ac/Electronic_Publications/DoD_Pubs/DoD%205220-22-M/cp8.pdf

Pages 14 and 15 note methods "a, b, d, and m" sanitizing fixed drives,
and continues:

d. Overwrite all addressable locations with a character, its complement, then a random character and verify. THIS
   METHOD IS NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMA-
   TION.

Implying that it is acceptable at lower classification levels.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: secure delete?

[Burnes, James]

As sad as it may be, physical destruction is the gold standard of data
security for retired media.

In my current job they have a small lottery.  The IT admin that wins get
to use a ball-peen hammer on several drives.

In my old job from 10 years ago (of which I can say little), the
standard was to take the drive into a sound insulated room with a 12
guage shotgun.  Several point-blank bursts from a Mossberg 500 has a way
of reducing the carrier media to slag.  Remember, "Mossberg: Proven
Performance and Peace of Mind."

Something to think about when you lie awake at night worrying about the
very technical dumpster divers who might want your latest F18 Mod
blueprints. ;-)

jim burnes
security engineer
great-west, denver
 

> -----Original Message-----
> From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
> Sent: Monday, March 29, 2004 6:10 PM
> To: Tom Vier
> Cc: reiserfs-list@namesys.com
> Subject: Re: secure delete?
> 
> On Wed, 24 Mar 2004 22:16:16 EST, Tom Vier <tmv@comcast.net>  said:
> > On Wed, Mar 24, 2004 at 01:20:47PM -0500, Valdis.Kletnieks@vt.edu
wrote:
> > > That's our official government recommendation for what's
sufficient
> when
> > > we're throwing away stuff that the Other Guys might actually do
this
> to.
> > > I have to assume that if the DoD or RCMP thought this wasn't
> sufficient
> > > to protect *our* secrets, they'd have a stricter standard.
> >
> > they do, complete destruction. that's what they do with secret
stuff.
> 
> http://www.irwin.army.mil/ac/LSS/DoD_Publications.html
> 
>
http://www.irwin.army.mil/ac/Electronic_Publications/DoD_Pubs/DoD%205220
-
> 22-M/cp8.pdf
> 
> Pages 14 and 15 note methods "a, b, d, and m" sanitizing fixed drives,
> and continues:
> 
> d. Overwrite all addressable locations with a character, its
complement,
> then a random character and verify. THIS
>    METHOD IS NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP
SECRET
> INFORMA-
>    TION.
> 
> Implying that it is acceptable at lower classification levels.....