fwipe0(1) fwipe0(1) NNAAMMEE fwipe0 - securely overwrite and delete files SSYYNNOOPPSSIISS ffwwiippee00 [ --nn ] [ --tt_t_i_m_e_s ] [ --ss_S_l_o_w_n_e_s_s ] DDEESSCCRRIIPPTTIIOONN ffwwiippee00 reads a list of filenames on standard input, each one followed by a 0-byte. If a filename refers to a regular file, then ffwwiippee00 attempts to overwrite the file _t_i_m_e_s times with 0's and 1's. If suc- cessful, ffwwiippee00 attempts to delete the file. For each file, ffwwiippee00 prints a response to stdout consisting of the filename, followed by a 0-byte, a status byte, a human-readable message and a newline. The status byte is 'Z' for temporary failure, 'D' for permanent failure, and 'K' for success. The output of ffwwiippee00 is suitable for secure parsing by other programs. One program which already understands this message format is Dan Bern- stein's mmaaiillddiirrsseerriiaall program, distributed as part of his sseerriiaallmmaaiill package. After each pass overwriting a file, ffwwiippee00 syncs the data to disk. That makes sure that your data is really overwritten on disk, not just in some memory buffer. This should even work if your files are mounted over NFS. However, some disks may have their own internal buffers, which would defeat ffwwiippee00. If you are _r_e_a_l_l_y concerned about the con- sequences of a privacy breach, then you should throw your hard drive in a vat of molten steel. If ffwwiippee00 encounters any error while erasing a file, then it refuses to delete the file. That way, data which was not overwritten is still where you can find it to deal with in some other way. Deleting files which weren't overwritten is, of course, a privacy leak. If a file grows while ffwwiippee00 is overwriting it, then ffwwiippee00 will not delete it. That way, if somebody is still appending data to the file, the data will not disappear where you can't easily find and deal with it. OOPPTTIIOONNSS --nn Erase the file, but do not delete it. This is provided for the sake of embedding applications which want to do deletions them- selves. For example, Dan Bernstein's _s_e_r_i_a_l_m_a_i_l package is compat- ible with ffwwiippee00. You can use it to erase the contents of a maildir with the command mmaaiillddiirrsseerriiaall _d_i_r _p_r_e_f_i_x _f_w_i_p_e_0 _-_n. --tt_t_i_m_e_s Overwrite the file _t_i_m_e_s times. Default is 5. --ss_S_l_o_w_n_e_s_s Experimental: introduce a delay factor out of niceness to other users. Since overwriting a file is very I/O intensive, fwipe can make the system fairly unresponsive to interactive users. Lowering the priority using _n_i_c_e is a good idea, but it doesn't help responsiveness much--most of the work is being done by the _b_d_f_l_u_s_h daemon, which runs at kernel priority. The --ss_S_l_o_w_n_e_s_s option adds a periodic pause during operation, which allows lowered priority to actually kick in and schedule other tasks. The argument can be any number between 1 and 32, with 1 giving the largest slowdown. When "slowness" is turned on, fwipe0 sleeps after writing 22^^_s_l_o_w_- _n_e_s_s blocks. This is an embarrassment of variety, I realize: using a _s_l_o_w_n_e_s_s below 11 or 12 results in ridiculously long execution times, and values above 16 or 17 seem to eliminate most of the benefit of the feature (but might still be useful in conjunction with higher _n_i_c_e values). Note that _f_w_i_p_e_0 does not monkey with its own priority; you still have to use _n_i_c_e to lower the priority of _f_w_i_p_e_0. Please experi- ment with different slowness settings and different _n_i_c_e values, and let the author know how well this feature is working for you. Something around _n_i_c_e _-_1_0 _f_w_i_p_e_0 _-_s_1_5 is recommended as a starting point. The duration of the sleep starts at 1 second, and then gradually increases using the same "quadratic backoff" scheme as _q_m_a_i_l_-_s_e_n_d. The rationale is that small file wipes are not affected much by this backoff, but large files on the other hand take a long time to wipe anyway--so who cares if a 1GB wipe takes 2 hours or 4 hours? The wait is determined by counting the number of times _f_w_i_p_e_0 invokes _s_l_e_e_p_(_). The sleep duration is the largest perfect square <= that count. So the first three sleeps are 1 second long; the next five are 4 seconds long; the next seven are 9 sec- onds long, etc. The number of blocks written between sleeps is constant and is determined by the _-_s_s_l_o_w_n_e_s_s argument as explained above. BBUUGGSS At the moment, ffwwiippee00 always returns a "temporary error" status on failure. That may change, if I ever decide which errors are temporary, and which are permanent. The "slowness" feature is highly experimental--it has no impact on the security or reliability of _f_w_i_p_e, but I haven't the foggiest what set- tings are to be recommended for various uses. Please give me your feed- back! Also, there is a race condition when ffwwiippee00 decides whether a file has grown before deleting it. It is possible for someone to append data to a file after ffwwiippee00 has decided to delete it, and before it is deleted. This might result in some information leaking to disk without being wiped. Users of ffwwiippee00 should generally make sure that they control the files they are wiping, and that they aren't running anything which might keep appending to the file. Admins might want to occasionally fill the disk with data, and then run ffwwiippee00, to erase information which was insecurely deleted (either by rrmm or through the ffwwiippee00 weaknesses already mentioned). Also, don't forget degaussing, and vats of molten steel. CCOOPPYYRRIIGGHHTT Copyright (c) 2000, Len Budney. All rights reserved. fwipe0 is made available under the terms of the BSD license. SSEEEE AALLSSOO maildirserial(1), echo0(1) fwipe0(1)