1995-07-21 - Superwipe

Header Data

From: gjeffers@socketis.net (Gary Jeffers)
To: cypherpunks@toad.com
Message Hash: e978cb4868c7bc5f0537acc323952497e60d150f4661e817bdf384eb65a31c55
Message ID: <199507210601.BAA25559@mail.socketis.net>
Reply To: N/A
UTC Datetime: 1995-07-21 04:07:15 UTC
Raw Date: Thu, 20 Jul 95 21:07:15 PDT

Raw message

From: gjeffers@socketis.net (Gary Jeffers)
Date: Thu, 20 Jul 95 21:07:15 PDT
To: cypherpunks@toad.com
Subject: Superwipe
Message-ID: <199507210601.BAA25559@mail.socketis.net>
MIME-Version: 1.0
Content-Type: text/plain


Dear Cypherpunks,

   This is mostly an old post that Monty Harder sent me
concerning my
program Superwipe. I got his ok to post it to Cypherpunks so
that it
would stimulate debate on my program.

   In addition to the original problem of wiping compressed
sectors, I
have found a second problem: with cacheing software and the
now
ubiquitous several hundred k hardware ram caches, it is
about impossi-
ble to do multiple wipes on sectors. Anyone else got any
ideas?

GJ>    A number of problems have cropped up though. It will
not handle
GJ> compressed disks yet. SUPERWIPE writes all 0's or all
1's & you know
GJ> what a compressed disk driver will do with them. The
driver would

>  Since most hard drives use a form of RLL encoding at the
hardware
>level, the bits don't all go in the same places every time.
For maximum
>security, you would need to write 00h through FFh, but a
fair compromise
>would be five passes: 00,55,AA,FF, and finally the string

>               'SUPERWIPEd for your protection.',BEL,CR,LF

>(gotta get in that plug) followed by random garbage.

GJ> crush them down to a few bytes at the beginning of the
file & the rest
GJ> of the file would not be touched.
GJ>
GJ>    I have decided that I can solve that problem by
writing a random
GJ> number generator function and filling the file with non-
compressable
GJ> random numbers.

>  Nope. Won't work. Suppose FUBAR.DAT is currently
compressed at 7:16
>(DoubleSpace, Stacker, et.al. typically use 16 sectors per
cluster).
>When the request to write the random cluster, now
noncompressible, comes
>along, the driver will find =another= run of 16 contiguous
sectors to
>hold the data, and free the old one (DS has no choice about
this, but
>Stacker can split clusters into noncontiguous areas if
necessary. I
>believe it "prefers" contiguous blocks, however.  IANASU.)

>  Your best bet is to put right in your docs a warning that
compressed
>drives make reliable operation of SUPERWIPE impossible to
assure, and
>that sensitive data are best kept on uncompressed drives.


GJ>    Also, I am thinking of putting SUPERWIPE into the
public domain.
GJ> I would use the privacy functions presently in it and
also include a
GJ> few more privacy functions. If I put it into the public
domain, then
GJ> I will have to distribute source code. This could make
me more vunerable

>  Why? Distribute executables, assert your copyright, and
include a
>GNU-type freeware license or whatever your heart desires.
That would be
>the international release. If you want, put up your source
code with the
>usual export controls, separately.







Thread