Cryptography-Digest Digest #855, Volume #13 Sat, 10 Mar 01 17:13:00 EST
Contents:
Re: Hash value repetion ("Scott Fluhrer")
Re: Noninvertible encryption (John R Ramsden)
Re: Using SHA as a checksum... ("Scott Fluhrer")
Re: Using SHA as a checksum... ("Scott Fluhrer")
Re: Noninvertible encryption ("Paul Lutus")
Re: Noninvertible encryption (John R Ramsden)
Re: DES Weak Keys (Albert P. Belle Isle)
Re: Voting ("Doom the Mostly Harmless")
Re: Dayton's Code Breakers ("Doom the Mostly Harmless")
Re: Digital enveloppes ("Tom St Denis")
Re: Hash value repetion ([EMAIL PROTECTED])
Question ("Dragon")
Re: Using SHA as a checksum... ("Moritz Voss")
Re: Using SHA as a checksum... ("Moritz Voss")
Re: Safe to use DSS key for DH? (DJohn37050)
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Hash value repetion
Date: Sat, 10 Mar 2001 10:11:41 -0800
<[EMAIL PROTECTED]> wrote in message news:98d09a$813$[EMAIL PROTECTED]...
>
> If all possible 160 bit values were hashed with SHA1, would there be any
hash
> results repeating? Or is it a 1 to 1 relation?
>
> What about MD5?
For SHA1, the answer is unknown, however, it appears to be quite likely that
there would be collisions.
For MD5, there will be collisions if you hash all 160 bit values. If you're
discussing 128 bit values here, then again, the answer is unknown, however,
it appears to be quite likely that there would be collisions.
>
> If neither are, are there hashes that are?
Can't think of any, off the top. One possible approach may be, for well
selected g, p, the hash function:
h(x) = g**x mod p
This hash a weakness that h(x) = h(x+p-1). However, it does not have any
collisions up to the size of the output of the hash function (which is a
number between 1 and p-1), and so may be the sort of thing you're looking
for.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John R Ramsden)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 18:26:05 GMT
Paul Lutus <[EMAIL PROTECTED]> wrote:
>
> "John Thingstad" <[EMAIL PROTECTED]> wrote:
> >
> > What is the properties that make a encrytion noninvertible.
>
> But you don't want to make the encryption noninvertible. That is not
> the goal of cryptography. If you make the encryption noninvertible,
> the recipient cannot read the message.
>
> The idea of modern cryptographic methods is to make it *impractical*
> to decode the message by direct, naive attack. It still must be
> possible for the intended recipient to decode the message.
Mind you, there's no reason why the sender of a text message couldn't
start by running a program to intersperse short sequences of random
letters all through the message such that the overall frequencies of
letters and letter groups would be made unpredictable, while at the
same time the recipient could still interpret the decrypted message
"semantically" and isolate the meaningful text from the extra noise.
I guess the main disadvantage of this would be to increase the message
length, and introduce the possibility of ambiguity or misinterpretation
especially if the original text itself included "random" letters such
as vehicle licence plates.
Simply plugging a long sequence of random letters at a fixed point in
the message (especially at the start or end) would probably be a fairly
bad idea, since it would give the plaintext a definite "profile" of,
for example, "random sequence followed by letter-frequency sequence",
which might assist a would-be decrypter even though the exact length
of each section in any given message would be unknown.
(As you may have guessed though, I'm not an expert at encryption
techniques. So forgive me if this is all covered in "Lesson 1" ;-)
Cheers
===========================================================================
John R Ramsden ([EMAIL PROTECTED])
===========================================================================
The new is in the old concealed, the old is in the new revealed.
St Augustine.
===========================================================================
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 10:20:21 -0800
Moritz Voss <[EMAIL PROTECTED]> wrote in message
news:98bv3l$6c3$05$[EMAIL PROTECTED]...
> Okay, I've been playing around with Python a little, and it has these
really
> easy-to-use cryptographic services.
>
> Apart from working out passwords, I wondered whether it's a good idea to
use
> SHA as a checksum for (small) text files... ? I'd say it certainly
> outperforms a 32bit CRC, doesn't it?
I wouldn't expect it to. I'd expect a well written CRC to run considerably
faster than SHA (although CRC would not be applicable if the below is the
problem you need to solve).
>
> In fact, this is for a security issue, I'll have a small script or data
> block, and need to see whether it is the same, or has been tampered with,
> and in that case, it will be updated with the original.... instead of
> sending some thousand bytes in vain, I'd just prefer to send the digest
of
> the python sha object....compare that, and move on.
>
> Or is this a taboo thing to do?
Do you have a secure place to hold the checksum (such as on a trusted remote
server)? If so, then it's perfectly valid. If not, then obviously the
attacker can modify both the file and the checksum.
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 10:24:52 -0800
Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
news:98drp5$avd$[EMAIL PROTECTED]...
>
> Moritz Voss <[EMAIL PROTECTED]> wrote in message
> news:98bv3l$6c3$05$[EMAIL PROTECTED]...
> > Okay, I've been playing around with Python a little, and it has these
> really
> > easy-to-use cryptographic services.
> >
> > Apart from working out passwords, I wondered whether it's a good idea to
> use
> > SHA as a checksum for (small) text files... ? I'd say it certainly
> > outperforms a 32bit CRC, doesn't it?
> I wouldn't expect it to. I'd expect a well written CRC to run
considerably
> faster than SHA (although CRC would not be applicable if the below is the
> problem you need to solve).
>
> >
> > In fact, this is for a security issue, I'll have a small script or data
> > block, and need to see whether it is the same, or has been tampered
with,
> > and in that case, it will be updated with the original.... instead of
> > sending some thousand bytes in vain, I'd just prefer to send the digest
> of
> > the python sha object....compare that, and move on.
> >
> > Or is this a taboo thing to do?
> Do you have a secure place to hold the checksum (such as on a trusted
remote
> server)? If so, then it's perfectly valid. If not, then obviously the
> attacker can modify both the file and the checksum.
Oops, I also remembered that, to do this, that the routine to compute the
SHA hash and compare it must also be secure, otherwise you haven't gained
much.
--
poncho
------------------------------
From: "Paul Lutus" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 10:45:21 -0800
"John R Ramsden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > The idea of modern cryptographic methods is to make it *impractical*
> > to decode the message by direct, naive attack. It still must be
> > possible for the intended recipient to decode the message.
>
> Mind you, there's no reason why the sender of a text message couldn't
> start by running a program to intersperse short sequences of random
> letters all through the message such that the overall frequencies of
> letters and letter groups would be made unpredictable, while at the
> same time the recipient could still interpret the decrypted message
> "semantically" and isolate the meaningful text from the extra noise.
The problem with this approach is that anyone could extract the message by
looking for the words immersed in the random letter sequences (or using a
computer program to locate identifiable dictionary words). In other words,
the role played by a password would not be present.
Even Julius Caesar had a better method than this -- across-the-board letter
substitution, more effective against casual browsing than interspersed
random letters, but still quite primitive by modern standards.
--
Paul Lutus
www.arachnoid.com
------------------------------
From: [EMAIL PROTECTED] (John R Ramsden)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Sat, 10 Mar 2001 19:05:44 GMT
"Paul Lutus" <[EMAIL PROTECTED]> wrote:
>
>"John R Ramsden" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>
>> > The idea of modern cryptographic methods is to make it *impractical*
>> > to decode the message by direct, naive attack. It still must be
>> > possible for the intended recipient to decode the message.
>>
>> Mind you, there's no reason why the sender of a text message couldn't
>> start by running a program to intersperse short sequences of random
>> letters all through the message such that the overall frequencies of
>> letters and letter groups would be made unpredictable, while at the
>> same time the recipient could still interpret the decrypted message
>> "semantically" and isolate the meaningful text from the extra noise.
>
> The problem with this approach is that anyone could extract the message by
> looking for the words immersed in the random letter sequences (or using a
> computer program to locate identifiable dictionary words). In other words,
> the role played by a password would not be present.
Good grief, I wasn't proposing that indispersing random letters was the
encryption itself. The result would be legible to a five year old! The
idea was to do this as a preprocessing step, and then apply the _real_
encryption to the "padded out" plaintext.
It goes without saying that this technique would only be suitable if the
recipient was a person, who could use their mental faculties to pick out
the meaningful text between the random letters, and the method couldn't
be used for encrypting, say, financial data being sent between computers
at financial institutions.
> Even Julius Caesar had a better method than this -- across-the-board letter
> substitution, more effective against casual browsing than interspersed
> random letters, but still quite primitive by modern standards.
Didn't they also use sticks or cones, around which a strip of parchment
were wrapped before messages were written on it, and then those messages
could later only be read back after wrapping the parchment on a shape of
the same size?
Cheers
===========================================================================
John R Ramsden ([EMAIL PROTECTED])
===========================================================================
The new is in the old concealed, the old is in the new revealed.
St Augustine.
===========================================================================
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: DES Weak Keys
Date: Sat, 10 Mar 2001 14:17:53 -0500
Reply-To: [EMAIL PROTECTED]
On Fri, 09 Mar 2001 23:27:43 -0500, Dan Seur <[EMAIL PROTECTED]> wrote:
>Does anyone know if the list of weak DES keys is in the public domain?
FIPS Pub 74, GUIDELINES FOR IMPLEMENTING AND USING THE NBS DATA
ENCRYPTION STANDARD, section 3.6 Characteristics of the DES Algorithm:
================================= snip ==========================
KEY DUAL
1. E001E00lFl0lFl0l 01E001E00lFl0lFl
2. FElFFElFFEOEFEOE 1FFElFFEOEFEOEFE
3. E01FE01FF10EF10E 1FE01FEOOEF10EF1
4. 01FE01FE01FE01FE FE01FE01FE01FE01
5. 011F011F0l0E010E 1F011F0l0E0l0E01
6. E0FEE0FEFlFEFlFE FEE0FEE0FEFlFEF1
7. 0101010101010101 0101010101010101
8. FEFEFEFEFEFEFEFE FEFEFEFEFEFEFEFE
9. E0E0E0E0FlFlFlFl E0E0E0E0FlFlFlFl
10. lFlFlFlF0E0E0E0E lFlFlFlF0E0E0E0E
The first 6 keys have duals different than themselves, hence each is
both a key and a dual giving 12 keys with duals. The last four keys
equal their duals, and are called self-dual keys. These are the four
previously discussed keys for which double encryption equals no
encryption, i.e., the identity mapping. The dual of a key (which has a
dual) is formed by dividing the key into two halves of eight
hexidecimal characters each and circular shifting each half by two
characters. No other keys are known to exist which have duals.
=========================================================================
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: "Doom the Mostly Harmless" <[EMAIL PROTECTED]>
Subject: Re: Voting
Date: Sat, 10 Mar 2001 19:22:05 GMT
<snip>
> As we saw in the newspaper practically every day last December,
> machine counting is generally less accurate than hand counting.
Do we really know that? It seems to me that, assuming that the hand count
/was/ more accurate, we only know that hand counting is more accurate than
that particular type or implementation of machine count. And that seems to
me to be a big assumption -- I mean, given that the hand counts often varied
as much from each other as from the machine counts, and the wide variety of
rules set for how things got hand counted (as opposed to one mechanical
rule, varying minutely from machine to machine from wear, etc.), how do I
know that the hand count(s) was(were) more accurate?
Hmm. Maybe we should just make me dictator for life and be done with it.
:-)
On second thought, that term might be unpleasantly short.......
--
To air is human....
--Doom.
------------------------------
From: "Doom the Mostly Harmless" <[EMAIL PROTECTED]>
Subject: Re: Dayton's Code Breakers
Date: Sat, 10 Mar 2001 19:22:12 GMT
> It is a fascinating story but hard to read in the column format on the web
> site. I transferred all the text to a MS Word file and attached it to this
> message.
In the future, please put a link, or take requests for it to be emailed, or
something. Some of us have small pipes from lousy ISP's that sometimes
(like today) choke on things like this, especially off their NNTP server.
Thanx.
--
To air is human....
--Doom.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppes
Date: Sat, 10 Mar 2001 19:58:14 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> "John A. Malley" wrote:
> >
> [snip]
> > General information on US patents may be found at
> >
> > http://www.uspto.gov/web/offices/pac/doc/general/
> >
> > For Canada I located this URL:
> >
> > http://strategis.ic.gc.ca/sc_mrksv/cipo/patents/pt_main-e.html
> >
> > The info I've provided is broad and sketchy, but it's a start.
>
> For European patents:
>
> http://www.european-patent-office.org
>
> One may get European patents with different coverages
> (i.e. countries where the patents are effective), at
> different fees to be paid to the patent office, of course.
>
> BTW, I happened to read these days the book P. Beckmann,
> A History of Pi. Golem Press, Boulder, 1977. There is on
> p. 173 a quote about a weird patent which I reproduce below
> for amusements/relaxations of those who are getting tired
> reading too much scientific stuffs about crypto in the
> postings of the group at the current moment:
>
> This invention relates to a device which renders it
> impossible for the user to stand upon the privy-seat;
> and consists in the provision of rollers on top of
> the seat, which, although affording a secure and
> convenient seat, yet, in the event of an attempt to
> stand upon them, will revolve, and precipitate the
> user on to the floor.
>
> U.S. Patent No. 90,298 (1869)
Hehehe that would have a market!
Tom
------------------------------
Subject: Re: Hash value repetion
From: [EMAIL PROTECTED]
Date: 10 Mar 2001 12:39:18 -0800
[EMAIL PROTECTED] writes:
> If all possible 160 bit values were hashed with SHA1, would there be any hash
> results repeating? Or is it a 1 to 1 relation?
Assuming that SHA-1 behaves like a random function, as it is designed
to and certainly appears to, about 1/e of the possible output values
would be skipped, meaning that there would be repetitions among the
others.
For SHA-1 to be a 1-to-1 function, i.e. a permutation of 160 bit
values, be a fantastic, incredible, unbelievable coincidence. It
would mean that there is hidden and unsuspected structure in the
computational universe. One might even consider it tantamount to
proof of the existence of God.
> What about MD5?
Same, for 128 bit values.
> If neither are, are there hashes that are?
Hashes are usually by definition intended to be pseudo-random
functions rather than pseudo-random permutations. One problem is that
you usually want the function to be one-way. For an example of a PRP
you can consider RSA encryption using a modulus with an unknown
factorization.
Alpha
------------------------------
From: "Dragon" <[EMAIL PROTECTED]>
Subject: Question
Date: Sat, 10 Mar 2001 20:48:19 GMT
First of all, I am sorry if I am in the wrong group.
Now that I have cleared that, I was wondering if someone can guide me to any
decrypting program. I have this encrypted file which I need to decrypt. I
know some of the exact contents of the file. It was encrypted with a program
I no longer have. As a matter of fact, I don't even remember the program
name any more. One thing I do remember is that I did not have to enter any
password or keys to encrypt the file.
Thank you.
------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Re: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 22:38:01 +0100
> Well I wouldn't truncate the result to 32-bits though.
No, I'd use it as a 160 bit CRC, /along/ with other purposes, so essentially
the data is also the 'key'...
> You can't authenticate it unless the original is private.
Hmm? What do you mean by this?
> Tom
--
--
Moritz "Thygrrr" Voss
http://www.thygrrr.com
------------------------------
From: "Moritz Voss" <[EMAIL PROTECTED]>
Subject: Re: Using SHA as a checksum...
Date: Sat, 10 Mar 2001 22:41:00 +0100
"Scott Fluhrer" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:98ds1a$i6j$[EMAIL PROTECTED]...
> > > In fact, this is for a security issue, I'll have a small script or
data
> > > block, and need to see whether it is the same, or has been tampered
> with,
> > > and in that case, it will be updated with the original.... instead of
> > > sending some thousand bytes in vain, I'd just prefer to send the
digest
> > of
> > > the python sha object....compare that, and move on.
> > >
> > > Or is this a taboo thing to do?
> > Do you have a secure place to hold the checksum (such as on a trusted
> remote
> > server)? If so, then it's perfectly valid. If not, then obviously the
> > attacker can modify both the file and the checksum.
The checksum is held on a remote server, and yeah, it'S trusted, because I
want the client side to be tamper proof and am considering server issues :)
> Oops, I also remembered that, to do this, that the routine to compute the
> SHA hash and compare it must also be secure, otherwise you haven't gained
> much.
Yeah, I realized the security isn't at all present, so essentially I'm
looking for a voluntary checksum thing, and SHA is kinda "overpowered" for
this purpose, a CRC will do just fine :)
Thanks for clearing this up...
> --
> poncho
>
>
--
--
Moritz "Thygrrr" Voss
http://www.thygrrr.com
>
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 10 Mar 2001 21:55:45 GMT
Subject: Re: Safe to use DSS key for DH?
Bleichenbacher recently had an attack on DSA, this shows something good for one
thing is not necessarily good for another.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 10 Mar 2001 16:01:50 -0600
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! ======
------------------------------
** 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
******************************
