Cryptography-Digest Digest #858, Volume #13 Sat, 10 Mar 01 23:13:01 EST
Contents:
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: OverWrite: best wipe software? ("Tom St Denis")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group ("Tom St Denis")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group ("Tom St Denis")
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 19:36:59 -0800
Eric Lee Green wrote:
>
> On Fri, 09 Mar 2001 14:39:04 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> m> wrote:
> >"A file can be written to one place on a hard drive then read into
> >cache. Processed then written to a completely different place on
> >the hard drive. And this process can continue I suppose until the
> >entire hard drive has been written over once and no bit locations
> >have been overwritten."
> >
> >File is opened in "r+b" mode.
>
> Means nothing. On any filesystem with a "true" journalling filesystem,
> "r+b" means nothing.
>
> >A block is loaded into cache not a sector. Block sizes vary.
>
> Not if we're talking about the on-drive cache in IDE and SCSI drives.
> They load physical sectors into their cache.
>
> You are correct, however, that "blocks" are what is in the OS's cache.
> Block sizes are an even multiple of sector size.
>
> >I believe that there are plenty of statistics available that prove
> >the accuracy, reliability and predictability of computer technology.
>
> You claim to be a programmer? Forgive me while I laugh my head off!
> ("Accuracy", "reliability", "predictability", and "computer technology"
> all in the same sentence, whoa!).
>
> >I don't believe that the entire block (not sector) from cache is
> >rewritten back to the hard drive. This would be inefficient. I am
>
> But that is what happens. Live with it.
>
> >quite sure that at most only the updated file is rewritten to the
>
> Uh, the block is one little piece of the updated file. It would be
> very inefficient to write a whole file out to disk whenever a few
> bytes were changed in one block.
>
> >Most likely when the overwrite program is the only program running
> >and the only program accessing the hard drive that the drive heads
> >will remain where they last read / wrote from / to the hard drive.
>
> Not exactly. It is very OS dependent. In DOS 6, for example, your
> next fopen() would cause the floppy drive or hard drive to gronk down
> to the root entry, then down to the directory entry, and only then
> back to your drive.
>
> >The OS and hardware cannot ignore a coded instruction indefinitely.
>
> No, but what it does is not what you think it does. The coded
> instruction says "Send some bytes to the operating system." It does
> not define what the operating system does with those bytes, other than
> that whatever the operating system does, you must be able to get those
> bytes back later if desired. The operating system may store those
> bytes in a buffer. It may store them back to the place on the hard
> drive where you think they are to be stored. It may calculate ECC sums
> and store those bytes in several different places on one or more hard
> drives. What you think the instruction is, and what the instruction
> really is, are two different things. Now, on some operating systems,
> the instruction "SEND_BYTES_TO_OS_FILE" does what you think it
> does. But that is a happy coincidence, rather than anything guaranteed
> in the fopen()/write()/fclose() sequence.
>
> >This is the reasoning behind my updating the OverWrite program. If
> >the OS and hardware is given enough time it will carry out the write
> >operation.
>
> It is a good plan on an OS that does not support a journalling
> filesystem. The question of "enough time", though, is troubling. How
> do we detirmine what is "enough time"? Is 1 second "enough time"? Is 5
> seconds "enough time"? Is 30 seconds "enough time"? I would suggest that
> you would be better off to bypass fopen() and fclose() and go straight
> to the Win32 OS layer and write raw Windows operations. There are even
> some raw Windows operations that will allow you to write directly to an
> IDE or SCSI device, totally bypassing the OS layer. Yes, I know this is
> work, but it's sometimes necessary. I had to do this on Solaris to
> bypass a brain-dead tape driver that lacked some modern functionality
> that I needed and it was a pain. But you do what must be done. Half-assed
> work-arounds may work sometimes, but will never be capable of always,
> 100% guaranteed, doing what you want.
>
> >Compressed files: This was another point raised. Wouldn't you agree
> >that the user is intending to overwrite the file as it exists. How
> >it got to be the file it is is not the concern of the OverWrite
> >program. This may be a concern of the user.
>
> The point was that compression changes the file. You may think you're
> writing 1,000,000 bytes of data to the file. But the user's actual
> file may have been 865,000 bytes of data, and your actual file that
> you are trying to overwrite the first file with may be 665,000 bytes
> of data once the OS finishes compressing it. What happens to the
> remaining 250,000 bytes of data? Well, it's still lying around on the
> disk until it is overwritten by some other operation.
>
> >winning at all costs. I believe it is about getting to the truth of
> >an issue. When a person lies or tries to deceive then the debate has
> >gone off topic but not necessarily void of enlightenment.
>
> That is what I am saying. The truth of the issue is that OverWrite is
> useful only in very limited circumstances. Those circumstances should
> be well documented and available for the end user's perusal so that he
> can easily decide whether the product will do what he needs it to do. It
> is very discouraging when the author of the product does not appear to
> know how operating systems actually store data on disk drives. It does
> not give people confidence that the author has properly stated the
> limiting circumstances.
>
> >It sounds like what you are proposing is that I upgrade the OverWrite
> >program to also scan your entire hard drive byte by byte for any
> >partial strings that are sub strings of the file you are intending to
> >overwrite as well and over write these as well. Good idea. I'll
> >keep it in mind.
>
> What I propose is that you give OverWrite the ability to do two things:
>
> 1) Be able to find the actual physical blocks on disk that correspond to
> a file (i.e., make it able to understand the common Windows file
> systems),
> 2) Make it read and write raw blocks directly to hard drives and
> disk controllers, totally bypassing the operating system. This way
> you can even tell the disk drive to flush its own internal buffers
> between operations.
>
> Then you will not be at the mercy of the operating system. Yes, this
> is difficult. But the Linux team taught Linux how to read and write
> the common Windows filesystems. It seems to me that some random group
> of guys doing work for fun in their spare time surely can't do it
> better than a dedicated computer professional (grin). And yes, you can
> do this in a safe way. When you open a file for r+ access, Windows
> "locks" the file. You can virtually guarantee that the blocks on disk
> that correspond to that file is not going to move.
>
> This is not an easy profession. Sometimes you must do what you must
> do. I had to bypass the Solaris operating system in order to directly
> read and write tape drives because the Solaris operating system's tape
> driver did not possess modern functionality and could not do things
> that I needed to do with the tape drives. I basically wrote a tape
> driver that talked raw SCSI commands to the tape drive. Did I want to
> write a tape driver? No. Did I have to, in order to make my program
> do what I believed it should do? Yes. So I did it. So should you, if
> you want your program to truly do what you believe it should do.
>
> >But for now, the OverWrite program is a simple overwrite utility.
> >Tell it to overwrite one file and I believe it does it and I have
> >told you why.
>
> And I have told you why I think that, as you currently state the
> function of the OverWrite program, it is not reliable at doing what it
> does. Under certain limited circumstances it will work as you
> believe. But you need to do far, far more to make it reliable under
> virtually all circumstances. (There will be a few issues -- like with
> RAID controllers -- where it is impossible to assure reliable
> operation, but for the most part those are easily documentable and
> don't affect the fundamental operation of such a product).
>
> --
> Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
> AVOID EVIDENCE ELIMINATOR -- for details, see
> http://badtux.org/eric/editorial/scumbags.html
>
> -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
> http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
> -----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Again, I would like to thank all of you. See my post: OverWrite:
best...
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 19:38:51 -0800
"Trevor L. Jackson, III" wrote:
>
> Eric Lee Green wrote:
>
> > On Fri, 09 Mar 2001 14:39:04 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> > m> wrote:
> > >Compressed files: This was another point raised. Wouldn't you agree
> > >that the user is intending to overwrite the file as it exists. How
> > >it got to be the file it is is not the concern of the OverWrite
> > >program. This may be a concern of the user.
> >
> > The point was that compression changes the file. You may think you're
> > writing 1,000,000 bytes of data to the file. But the user's actual
> > file may have been 865,000 bytes of data, and your actual file that
> > you are trying to overwrite the first file with may be 665,000 bytes
> > of data once the OS finishes compressing it. What happens to the
> > remaining 250,000 bytes of data? Well, it's still lying around on the
> > disk until it is overwritten by some other operation.
>
> This vastly understates the problem. He has already stated that he writes a
> constant to every byte. I believe the example was 222. Even a simple RLE will
> compress that megabyte by a hundred or so, thus leaving 99% of the original image
> unmodified.
>
> Can you take this to some other group?
It is just about all over with. See my post OverWrite: best...
if you care to. I think it will solve just about all concerns.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Sun, 11 Mar 2001 03:41:16 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> OverWrite: best wipe software?
>
> I think I have made Ciphile Software's OverWrite Security Utility
> Version 1.2 perhaps the best wipe utility available for Windows.
>
Why do you think that?
> Read below and you tell me. Now available for direct download at
> www.ciphile.com
>
> In addition to the prior instructions here are the new
> recommendations and facilities. What have I forgotten?
Download binaries from you? Not likely.
> "NOTE: For best results this program should be used only with
> Windows OSs and there should be no other programs running while this
> program is running. Maximum security from using this software
> results when overwriting files that are stored on 1.44MB floppy disks.
> Therefore, your most sensitive files should be written directly to
> 1.44MB floppy disks if you must be as absolutely sure as possible
> that this data is as nearly impossible as possible to recover once
> overwritten using this software. SCSI hard drives are not
> recommended. Nor are compressed drives. I use this software to
> overwrite files on my own IDE hard drives.
Hmm 1.44MB floppies only? What about 720kb diskes? Why would I want to
wipe a 1.44mb disk anyways?
> RECOMMENDATIONS: You are probably familiar with MS Word. Start a
> new composition then save it. Then close the file. Now open it
> again. You will notice that a swap file has been created:
> ~$Doc1.doc if you saved the file as Doc1.doc. When you are through
> and close this file the swap file ~$Doc1.doc is deleted. But the
> ~$Doc1.doc data is still on your hard drive. So if you decide later
> to overwrite the Doc1.doc file you will not be overwriting previously
> removed ~$Doc1.doc data that is still on your hard drive. But take
> notice that even MS Word creates this swap file in the directory
> where the current document is stored.
What's "MS Word" I have never heard of that before? Does your program only
work with that? Can I download it off your website?
> If you are serious about making sure that any data that has been
> saved to your hard drive is removed when you overwrite it using
> Ciphile Software's OverWrite Security Utility program then you
> should follow these specific recommendations.
>
> You should create a hard drive partition dedicated to storing and
> processing sensitive data. All sensitive data that you create or
> save or process with your computer should be done only in this
> dedicated hard drive partition.
So I should delete all my work and split my 45gb disk into two partitions so
I can securely wipe data with your software? Right... why don't I just
format my 45gb partition twice daily and reinstall windows? It's probably
easier.
> As you may have noticed much of this discussion has been making an
> underlying assumption that because of OS and hardware optimization
> that sometimes and in some circumstances the actual overwrite may not
> be taking place exactly as thought and intended. You have noticed
> that I have described a procedure that will make sure that the
> overwrite does take place as desired. But there have been some
> additional improvements to Version 1.2 of OverWrite.
>
> Here they are in a nutshell fast and furious: in each of the 27
> passes of the overwrite process there is an fopen, overwrite,
> fflush, fclose, and ProcessMessages command. Each time, these are
> followed by a sleep command that suspends program operation for a
> specified number of seconds and this allows the OS to take over.
> This amount of time can be anywhere from 2 to 120 seconds and is
> user determined. This should provide the OS and hardware with more
> than enough time to commit and effect an overwrite. On my two
> systems a sleep(4) seems like enough. This is your decision to
> make. I look at the hard drive indicator light and listen to the
> hard drive and even feel the hard drive bay for indications that
> the write is physically taking place.
You still don't get it do ya? The OS doesn't have to write the data AT ALL
until the buffers are filled. It could be 3 years until you get bored and
move the mouse and windows has to swap 100mb to redraw the mouse.
> Where do you get the TFiles and MixFile.otp? You can generate these
> using Ciphile Software's OAP-L3 or OAR-L3 software available from
> www.ciphile.com from the Downloads Currently Available web page.
> Also, you can generate files of any length by being creative with
> the Utility files included with these two software programs.
Download more crappy binaries?
> If you follow the above recommendations it leaves very little if
> any wiggle room for the OS or hardware to forestall any overwrite
> operation or not to overwrite your intended file.
Do you have any physical analysis of a common HD platter after your wipe
process? I want to know the bounds on the likelyhood of recovering data
before I contact my boss about making a deal.
> Here is how you input the sleep parameter in seconds: Use NotePad
> or WordPad and create a file called VarDur.txt and place it into your
> H:\ drive or into the drive / folder / directory where the file is
> you want to overwrite. Write no more than three digit characters
> into this file. This will be how many seconds you want the program
> to suspend using the sleep function between each of the 27 overwrite
> passes. The default is 2 seconds. 2 seconds will be used if the
> number you enter in VarDur.txt is less than 2 or if the file does
> not exist. The maximum three digit value is 120 seconds. If you
> enter three digits greater than 120 then 120 will be used. Only
> three characters will be read from the VarDur.txt file and only
> digits will be accepted. All other characters will be ignored.
>
> You will see improvements in the program user interface with
> OverWrite Version 1.2. There is a progressbar, a percentage label,
> a pass label and a sleep duration label all to indicate to the user
> the parameters and progress of the overwrite process. See below
> for other instructions.
Oooh a progress bar, that's technology.
> I know that I could have made a better interface and written better
> instructions but this is freeware and I have limited time. But I
> think you all now have maybe the best overwrite program available
> if used properly.
Write good software or none at all. Simple rule to follow.
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 19:43:35 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Richard Herring wrote:
> > >
> > > In article <[EMAIL PROTECTED]>, Crypto
> > > Neophyte ([EMAIL PROTECTED]) wrote:
> > > > On Sun, 4 Mar 2001 17:22:02 -0600, Anne & Lynn Wheeler wrote
> > > > (in message <[EMAIL PROTECTED]>):
> > >
> > > > > however, overwriting 27 times is a little harder since
> > > > > straightforward overwrite is likely to just be updating buffer
> > > > > records. frequently multiple overwriting passes consists of
> > > > > different combinations of ones & zeros with the intent of
> > > > > exercising the magnetic flux in different ways on the disk
> > > > > surface.
> > >
> > > > Ok, please help out a neophyte. I have a program called MACWASHER.
> > > > The box states that it overwrites files according to the DoD
> > > > directive 5220.22-M.
> > >
> > > If the program does what it claims to (and I have no knowledge of
> > > that) it will be accessing the hardware at a lower level than
> > > Szopa's calls of the C library functions fopen()/fclose().
> > >
> > > > It looks like from what I have read on this discussion that the
> > > > above DoD directive doesn't actually do what the DoD thinks it
> > > > does.
> > >
> > > If that's what you think, you have severely misread something.
> > > The DOD directive presumably states that the program *shall* do
> > > something. If the program doesn't do what the DoD requires, it
> > > means that the program fails the directive, not that the
> > > directive is wrong.
> > >
> > > > In other words I am not actually deleting the files and making
> > > > them unrecoverable? When I say unrecoverable I mean to a software
> > > > based attack and not SEM data.
> > >
> > > No. The point here is not that it is impossible to do
> > > what you want, but it can't be done using high-level
> > > platform-independent library functions.
> > >
> > > --
> > > Richard Herring | <[EMAIL PROTECTED]>
> >
> > here are the calls:
> >
> > fopen in r+b mode
> > fprintf character by character
> > fclose that flushes all OS buffers associated with the stream. You
> > would think this would be enough to force a write.
>
> How many times does this need to be pounded into your head? fclose
> flushes the C library buffers, not the OS buffers.
>
> > Just to make sure I added one of ...
> >
> > ...the Colonel's secret spice codes of 8 characters in length in
> > each pass
> >
> > Down load the UPDATE. You will see the hard drive accesses after
> > each pass. Larger file size makes for more hard drive accesses.
> >
> > There can only be one reason for these hard drive accesses with the
> > code as described: a write to the hard drive.
>
> That's ignoring the hdd buffers. The drive light goes on for a bus
> transfer of data to the drive, not for actual writing.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
I am not convinced this is so. The documentation says specifically
"system-allocated" buffers are flushed.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 11 Mar 2001 03:46:52 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > That's ignoring the hdd buffers. The drive light goes on for a bus
> > transfer of data to the drive, not for actual writing.
> >
> > --
> > The difference between theory and practice is that in theory, theory and
> > practice are identical, but in practice, they are not.
>
>
> I am not convinced this is so. The documentation says specifically
> "system-allocated" buffers are flushed.
Who cares what you think? There is lots of buffering between cpu and
physical disk. It's hard to actually force writes in a portable fashion.
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sat, 10 Mar 2001 19:54:50 -0800
Benjamin Goldberg wrote:
>
> Anthony Stephen Szopa wrote:
> [snip]
> > Here is a test that I just carried out.
> >> <snip>
>
>
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
(Here's a good one. The cat in the box.)
Are you saying that the file is not on the disk?
You can reach resolution and closure by reading probably the coup
de grace solution to all of this concern in this single post
"OverWrite: best wipe software?" that I just posted.
Thanks for your help spurring me on to achieve this.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 11 Mar 2001 03:56:43 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Benjamin Goldberg wrote:
> >
> > Anthony Stephen Szopa wrote:
> > [snip]
> > > Here is a test that I just carried out.
> > >> <snip>
> >
> >
> > The difference between theory and practice is that in theory, theory and
> > practice are identical, but in practice, they are not.
>
>
> (Here's a good one. The cat in the box.)
>
> Are you saying that the file is not on the disk?
>
> You can reach resolution and closure by reading probably the coup
> de grace solution to all of this concern in this single post
> "OverWrite: best wipe software?" that I just posted.
>
> Thanks for your help spurring me on to achieve this.
You have yet to really fix the problem. Windows DEFRAG can force writes
(well duh it has to).
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
