*** Source imported to git from http://www.thc.org/ ***


                          S E C U R E   D E L E T E


           (c) 1997-2003 by van Hauser / THC  <vh@thc.org>

			 http://www.thc.org





          " Does the average person really need this kind of security?
            I say yes. [...] He may be living in a country that does not
            respect the rights of privacy of it's citizens. He may be
            doing something that he feels shouldn't be illegal, but is.
            Whatever his reasons, his data and communications are
            personal, private, and nobody's business but his own. "

          Bruce Schneier in the Preface of his book "Applied Cryptography"



	  " A Puritan is someone who is deathly afraid that someone,
	    somewhere, is having fun. "

          Unknown





                            1. INTRODUCTION
                            2. HOW THESE PROGRAMS WORK
                            3. COMMAND LINE OPTIONS
                            4. LIMITATIONS
			    5. COMPARISON
                            6. LAST WORDS
                         





     1. INTRODUCTION

     Years ago, people using the old msdos, simply deleted a file by
     doing "del filename" and thought the the erase was forever.
     Then Norton's undelete was released and everyone could get
     back the files most of the time. After that people who wanted to
     keep people of their deleted files erased them by overwriting the
     file with random or 0x00 bytes and felt secure.

     In 1996 Peter Gutmann published a paper called "Secure Deletion of Data
     from Magnetic and Solid-State Memory" at the 6th Usenix Security
     Symposium, where he pointed out that the data could even be recovered
     if you overwrote them triple times and more - using cheap equipment
     for about 1000-2500$.
     The three utilities presented here try to cover this new area of secure
     deletion and prevent file recovery.
     This release includes the full paper of Peter Gutmann from the
     6th Usenix Security Proceeding (usenix6-gutmann.doc).

     The four utilities do the following :

     srm does secure deletion of files.
     sfill does a secure overwriting of the unused disk space on the hard disk.
     sswap does a secure overwriting and cleaning of the swap filesystem.
	(note that sswap was only tested on linux so far.
         you must unmount your swap first!)
     smem does a secure overwriting of unused memory (RAM)

     For Linux, there's a diff (rm.diff) patch for rm.c which puts the
     overwriting feature into it. (You need the fileutil sources)




     2. HOW THESE PROGRAMS WORK

     The deletion process is as follows:

     1. The overwriting procedure (in the secure mode) does a 38 times
        overwriting. After each pass, the disk cache is flushed.
     2. truncating the file, so that an attacker don't know which
        diskblocks belonged to the file.
     3. renaming of the file, so that an attacker can't draw any conclusion
        from the filename on the contents of the deleted file.
     4. finally deleting the file (unlink).

    Note that with v2.0 all secure_delete utilities work in secure mode
    (38 special passes). To lower the security and make it faster, you
    may add -l (one 0xff pass, one random pass) or -ll (one random pass) to
    the parameters. 
     
     The secure overwrite mode works that way:

      1x overwrite with 0xff
      5x random passes
     27x overwriting with special values to make the recovery from MFM and
         RLL encoded hard disks hard/impossible - see Gutmann's paper on that
         which is also included.
      5x random passes     



     Some statistics :

     in 1 second you can approx. overwrite 1 to 2 MB of data, depending
     on your hard disk performance.

     In totally insecure mode, a 100 MB file/free-disk-space takes
     approx. 15 seconds, and in the totally secure mode approx. 60 minutes.





     3. COMMAND LINE OPTIONS

     Here are the command line options:

     srm    [-d] [-f] [-l] [-l] [-v] [-z] file [file] [another file] [etc.]
     sfill  [-i] [-I] [-f] [-l] [-l] [-v] [-z] target-directory
     sswap  [-f] [-l] [-l] [-v] [-z] /dev/of_swap_filesystem
     smem   [-f] [-l] [-l] [-v]

     The -s options are deprecated now, and will be ignored.

      -d   don't delete the dot special files "." and ".." on the
           command line (only srm)
      -i   wipe only free inode space, not free disk space on the filesystem
           (only sfill)
      -I   wipe only free disk space, not free inode space on the filesystem
           (only sfill)
      -f   fast writes without O_SYNC and sync() between writes. Much faster
           but less secure.
      -l   lessens the security. Only one random plus one pass with 0xff are
	   written.
      -l   a seconds time as parameter switches into the most insecure mode,
	   it overwrites the file only once with 0xff.
      -v   turn verbose mode on.
      -z   last wipe mode writes zeros instead of random data
     file  file to delete. Wildcards are of course allowed.
           For unix: you need write permissions. For msdos: It may be hidden,
           system, readonly etc. we don't care.
    target-directory  target is a directory in the filesystem to write to.
    swap_filesystem   your swap filesystem. Unmount it first!!
                      only tested on linux

     Options may be applied like "-lfv", "-l -f -v" or a mix.

     Note: If you use a GNU-compatible Linux, you can use the patch rm.diff
     included in the package to put the features from srm into your normal
     rm. Just enter your fileutils-3.16 directory, type "patch < rm.diff"
     and then "make". You need at least one -s switch to activate
     (1 overwrite). Note that -sss is needed for full security.


     NOTE:
     For the Linux kernel module, you just have to do "insmod sdel-mod"
     to load the module. After that, all files, which are deleted by any
     program are then wiped once before the space is marked as free.



     4. LIMITATIONS

     This section discusses limitations of the programs presented and general
     problems and threats of secure data deletion - and how to handle them.
     As you can see from the source code, these are very small and generic
     programs. That means that they aren't perfect and doesn't cover any
     aspect of secure data deletion. Please read this section carefully
     to learn against which problems it does NOT help.
     

          - Random Number Generation
	    Since v2.0, secure_deletion uses the /dev/urandom as a random
            source if available. This should fix this problem. However,
            for completeness, read on:
            The numbers which WERE generated by the programs were far away
            being "real" random. Standard random number generators are
            used and they are easy to predict.
            This is a major risk if you are using them for online crypting
            purpose, for the purpose of overwriting it is nearly enough.
            However, I added two extra random overwrites to be sure.
            A solution for paranoid people : change the random number generator
            in the programs to something you trust.
            Here's an extract from an answer Peter Gutmann wrote me as
            I asked him about that problem :

   > 1st to be compatible with all platforms, I didn't use a crypt-random
   > library, I use a simple  (256*rand()/(RAND_MAX+1.0)) seeded 1st time with
   > the pid. For every byte to overwrite the file I call that function.
   > I know that this random stuff is not "secure" for online crypting,
   > but is it enough for deletion?
   > I added 2 more random overwrite modes in the source to minimize that risk.
   > What do you think?
   A strong RNG isn't that essential, as long as you're not writing a constant 
   pattern.  I use RC4 in SFS because it's faster than most RNG's provided in 
   compiler libraries.

[/dev/urandom is used if available. This is a very good RNG]


          - Disk Caching
            Note that this is only important for FILE DELETION (srm) for free
            disk space wiping the data which will be overwritten is large
            enough.
            Imagine that you overwrite a file for 50 times, you feel secure,
            but only one - the last overwrite - is really made.
            This can be the case if you use smart software caches, hardware
            cache-controllers - or the cachebuffers which are present on
            all (E)IDE and SCSI hard disks.
            This programs uses fsync() - it depends on your unix and hardware
            if this is enough.
            If you use an hardware cache-controller you must remove it.
            For the cachebuffers of the hard disks you must overwrite a file
            which is greater in size than the diskbuffer. You can either
            add data to the file until it reaches that size or you define
            the BLOCKSIZE definition to a size big enough
            Here again is en extract of an answer Peter Gutmann wrote in
            regard of this threat :

   > 2nd is the caching problem. For msdos i flush smartdrive after every
   > write of a pattern, on unix I use sync. That makes it easy to compile
   > on all platforms, yes, but it won't flush the hard disks internal caches.
   > how big must be the file to force the internal cache to write to disk?
   > at the moment I do only full 16 kb writes to a) overwrite the whole block
   > and also to reach the limit of the internal cache.
   I don't think there's an easy answer to this.  Most cheap commercial drives 
   have tiny caches (typically 96KB or 128KB with 16KB (EIDE) or 32KB (SCSI)
   used by the firmware), but larger SCSI drives designed for servers and/or 
   controllers on servers can have considerable caches.  I'd say 16KB or 32KB 
   would be reasonably safe.

[secure_deletion uses 32kb, and since 2.2 enlarges this if the blocksize
 of the filesystem is larger]
            

          - Temporary files and disks
            Windows 3.x, Win95 and WinNT support virtuell memory which means
            that if more memory is needed, some space of the harddisk will
            be used. Unix does the same, using the swap space partition (and
            additionally swap files can be created). Some other programs do
            the same, especially databases.
            Other programs you use, f.e. a word processor etc. writes recovery
            and/or backup files. Those must be secure deleted too - which is
            a major problem if the programs delete them after the program exit.
            Solution, regardless of the operating system of your choice :
               - All disk partitions must be set write protected in some way
                 before you want to do something which shouldn't be saved
                 anywhere. MsDos tools are available, on unix they can be
                 mounted readonly, Win95/WinNT : don't know if that is possible.
               - Install a ramdisk from which you start all applications
                 (for Windows set the working directory on the ramdisk)
                 and ensure that all temporary stuff, etc. points to that disk.
                 If you can't afford ram, re-partition your disks so that you
                 get an 20+ MB diskspace either ensure a complete wiping of
                 that partition after every session (use "sfill -v")
                 or use an encrypted filesystem (see next step).
                 For unix you should set a ramdrive for the swap partition,
                 and use an additional ramdisk or encrypted partition for
                 /tmp and ensure that /usr/tmp and /var/tmp point to it.
		 If you can't afford buying ram so you don't need swap, you
		 can use the secure swap cleaner, included in this package.
		 With v1.8 of secure_deletion, you can also use sswap to
		 clean your swap space after you unmounted it.
               - If you really need the data you produced or analysed,
                 then create an encrypted filesystem on a disk partition.
                 For unix you can use CFS (newest version v1.4.x), for MsDos
                 and Windows 3.x there are SFS v1.7 and SecureDrive v1.4a
                 available. I don't know any for Win95 and WinNT - but these
                 have special problems anyway so see the next topic :


          - Windows 95 and WinNT
            As you can see, the programs were NOT programmed for any Windows
            environment and this has got the following reasons :
               - I don't know enough about these systems to make the programs
                 secure, also I know that they've got an internal function to
                 flush their caches without any problems.
               - Special problems like in the NTFS, the WinNT Filesystem, which
                 holds too much information on the files, so that real secure
                 data deletion is tricky.
               - Windows machines swap very often - and where and how to
                 control that - I don't know, in my opinion it would be too
                 difficult to make it a secure system (against data recovery).
                 So why writing a secure deletion programs when fragments of
                 the files are everywhere on the harddisk?

          - Networks
            Before we'll discuss further matters of that topic let me put it
            short and straight : YOU CAN'T ENSURE SECURE DATA DELETION WHEN
            WORKING OVER A NETWORK YOU DO NOT *COMPLETLY* CONTROL !
            Because :
               - The network servers and maybe even your local computer
                 caches the data to be written. See "Disk Caching" above
                 why this is a problem - and this one can't be solved.
               - How long are your files present on the server? Long enough
                 that they are written on a backup?
               - A hacker or law enforcement/spies could have trojaned the
                 server in a way that your files won't be overwritten and
                 removed but those files are written to a special place waiting
                 to be retrieved by them. Nearly all known network operating
                 systems and also some firewalls can be penetrated from remote,
                 no kidding. So don't think that you are not vulnerable.
                 Another possibility is that the memory of the server is
                 surveilled and all reading/writing processes own by you or
                 anyone copied.
               - Even if everything is ensured there might be still problems
                 on high-end systems, which use f.e. Raid5 or similar redundant
                 hard disk systems which prevent data loss by keeping copies
                 and checksums, and you must find a way to trash those
                 information too.
            The solution is easy: don't put any private and important stuff
            you don't want anybody to see on the network - crypt it before
            transfering it on a server.


          - Paranoia
            Finally two points which are for very paranoid guys.
            Imagine a temporary file was written by a program you used for
            your important files and they were deleted. You run "sfill"
            f.e. to clean all unused diskspace to trash all information.
            But another file, f.e. a config file, was written when exiting the
            program and parts of the temporary file are now owned and
            overwritten by the config file. sfill or any similar program won't
            trash that file area because it's used by a file. And the data on
            this area can be recovered with cheap hardware.
            Solution : see above, "temporary files and disks"
            If you really care about your files that they can't be recovered
            you should also ensure that the "others" can't get the data by
            other means, f.e. by either hacking your computer or analyzing
            the electromagnetic/sound/wave emissions from the monitor, printer,
            fax and cables.
            Solution : pull out your network/modem cable when working and
            try to shield your computer (search the inet for more info on that)

	  - But there is help
	    Watch out. Soon there will be a new release from THC which
	    shows how to make a Linux machine anonymous. When followed,
	    nothing will be recoverable for someone having your harddisks.
	    -> This was released looong ago now :-) Go the the THC website,
            enter the articles/papers section and look for "anonymizing unix
	    systems".


     5. COMPARISON

Program		   	secure_delete (srm)	wipe		   wipe
Version				2.1		0.2		   0.56-2a
Programmer	   	van Hauser / THC	Berke Durak	   Tom Vier
Email		   	vh@reptile.rug.ac.be	bedrettin@chez.com thomassr@erols.com

Standard Passes			38		35			35
More passes via cmd		no		no			yes
Fewer passes via cmd		yes		yes			yes
Good RNG			yes		yes			yes
Blocksize (larger is better)	32k		1k			0
Truncates file			yes		no			yes
Rename file/directory		yes		no			no

recursive mode			yes		yes			yes
secure recursive (link races)   yes		no			no
verbose mode			yes		yes			yes

additional wipe tools		yes		no			no

Time: 1 File, 1MB		25s		40s			26s
Time: 10 Files, 10kb		12s		6s			4s
(Parameters for tests)		<none>		-f			-fTe
						  		(needed for the
								 fastest mode)
						  [otherwise it needs x12 time]

Why is secure_delete that fast with big files but slower with many small
ones? It's fast, because it uses a big buffer for writing. It's slow because
the additional security features (rename, truncating, more passes, better
RNG [against wipe-0.2] and by far the biggest blocksize).
It's also the only one which comes with a free diskspace wiper and a special
cleaner for swap space and memory.
I think the choice is easy ,-)  I hope the other programmers will make their
programs better too, the more good & secure & fast programs, the better.
Competition helps us all.


     6. LAST WORDS

     I hope these little utilities help those who really need them.
     For any bugs, ideas or ongoing discussion feel free to email me at
     vh@reptile.rug.ac.be using the public pgp key below.

	http://www.thehackerschoice.com

     Have fun ...
                    van Hauser / [THC] - The Hacker's Choice


Type Bits/KeyID    Date       User ID
pub  2048/CDD6A571 1998/04/27 van Hauser / THC <vh@reptile.rug.ac.be>

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i

mQENAzVE0A4AAAEIAOzKPhKBDFDyeTvMKQ1xx6781tEdIYgrkrsUEL6VoJ8H8CIU
SeXDuCVu3JlMKITD6nPMFJ/DT0iKHgnHUZGdCQEk/b1YHUYOcig1DPGsg3WeTX7L
XL1M4DwqDvPz5QUQ+U+VHuNOUzgxfcjhHsjJj2qorVZ/T5x4k3U960CMJ11eOVNC
meD/+c6a2FfLZJG0sJ/kIZ9HUkY/dvXDInOJaalQc1mYjkvfcPsSzas4ddiXiDyc
QcKX+HAXIdmT7bjq5+JS6yspnBvIZC55tB7ci2axTjwpkdzJBZIkCoBlWsDXNwyq
s70Lo3H9dcaNt4ubz5OMVIvJHFMCEtIGS83WpXEABRG0J3ZhbiBIYXVzZXIgLyBU
SEMgPHZoQHJlcHRpbGUucnVnLmFjLmJlPokAlQMFEDVE0D7Kb9wCOxiMfQEBvpAD
/3UCDgJs1CNg/zpLhRuUBlYsZ1kimb9cbB/ufL1I4lYM5WMyw+YfGN0p02oY4pVn
CQN6ca5OsqeXHWfn7LxBT3lXEPCckd+vb9LPPCzuDPS/zYnOkUXgUQdPo69B04dl
C9C1YXcZjplYso2q3NYnuc0lu7WVD0qT52snNUDkd19ciQEVAwUQNUTQDhLSBkvN
1qVxAQGRTwgA05OmurXHVByFcvDaBRMhX6pKbTiVKh8HdJa8IdvuqHOcYFZ2L+xZ
PAQy2WCqeakvss9Xn9I28/PQZ+6TmqWUmG0qgxe5MwkaXWxszKwRsQ8hH+bcppsZ
2/Q3BxSfPege4PPwFWsajnymsnmhdVvvrt69grzJDm+iMK0WR33+RvtgjUj+i22X
lpt5hLHufDatQzukMu4R84M1tbGnUCNF0wICrU4U503yCA4DT/1eMoDXI0BQXmM/
Ygk9bO2Icy+lw1WPodrWmg4TJhdIgxuYlNLIu6TyqDYxjA/c525cBbdqwoE+YvUI
o7CN/bJN0bKg1Y/BMTHEK3mpRLLWxVMRYw==
=MdzX
-----END PGP PUBLIC KEY BLOCK-----