Cryptography-Digest Digest #806, Volume #13       Mon, 5 Mar 01 13:13:01 EST

Contents:
  Re: Why do people continue to reply to Szopa? (John Savard)
  passphrase question (Anonymous)
  Re: Monty Hall problem (was Re: philosophical question?) (Joe H. Acker)
  passphrase question (Anonymous)
  Re: The Foolish Dozen or so in This News Group (Richard Herring)
  Re: Text of Applied Cryptography (Arturo)
  Re: "RSA vs. One-time-pad" or "the perfect enryption" (Steve Meyer)
  Avalanche in round keys. ("Simon Johnson")
  Re: won't you tell me something about my encryption scheme ? ("Simon Johnson")
  Re: OverWrite freeware completely removes unwanted files fromharddrive (Darren New)
  Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Simon Johnson")
  Re: Monty Hall problem (was Re: philosophical question?) (Darren New)
  Re: Monty Hall problem (was Re: philosophical question?) (Ken Cox)
  Re: Monty Hall problem (was Re: philosophical question?) (Ken Cox)
  Re: Monty Hall problem (was Re: philosophical question?) (Ken Cox)
  Re: Avalanche in round keys. ("Tom St Denis")
  Re: The Foolish Dozen or so in This News Group (Darren New)
  Re: The Foolish Dozen or so in This News Group (Darren New)
  Re: => FBI easily cracks encryption ...? (Free-man)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.hacker
Subject: Re: Why do people continue to reply to Szopa?
Date: Mon, 05 Mar 2001 13:19:19 GMT

On Mon, 05 Mar 2001 01:54:54 GMT, Paul Crowley
<[EMAIL PROTECTED]> wrote, in part:

>The only reason to post a followup to
>something he's written is to warn off newcomers who might otherwise
>believe some outlandish claim or other.

Precisely. Unfortunately, that's sufficient reason to post quite a few
replies to him.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

Date: Mon, 5 Mar 2001 15:00:02 +0100
From: Anonymous <[EMAIL PROTECTED]>
Subject: passphrase question
Crossposted-To: alt.security.pgp

I was thinking about using a decryption passphrase for software like PGP
and the like that would consist of a very long string of characters like:

......aaaaaaaaaa$$$$$$$$$$$fffffffffffDDDDDDD5555


I would remember the passphrase by just remembering there are 7 periods, 10
a's, 11 $'s, 11f's, and 7 D's, and 4 5's.
So, the only thing in my mind would be 7 10 11 7 4 and the
characters/numbers used.  I know the security in public key encryption lies
in the protection of the private key, and that long private key passphrases
would make for a more secure system.  Not taking into account things like
keyloggers, remote electronic monitoring i.e TEMPEST, etc, just how secure
is this method choosing a long passphrase?

Just using the above letters once, the pass would be:
.a$fD5 which is 6 characters in length.

But I'm multiplying each character a number of times to get the pass.
7(.)11($)11(f)7(D)4(5)

My final passphrase length is 7 + 11 + 11 + 7 + 4 + 5 = 45, which satisfies
the long passphrase requirement, and brute forcing something of that length
would be difficult from what I've read on the subject.  But is the way I'm
choosing that long passphrase weak?  Is it any different that the original
7 character .a$fD5 passphrase when put up to a brute force?
Comments/answers much appreciated, and please reply to the newsgroup only.

Thanks,
gerry







--Part_Boundary-26781F--




------------------------------

From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Mon, 5 Mar 2001 14:53:45 +0100

> "Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> 
> > Here's a problem I have with this explanation: Why can't I say that
> when
> > Monty opens door 3, there's new evidence: the car is not behind door
> 3.
> > Thus, the probability that the car is behind door 1 is 1/2, and the
> > probability that it's behind door 2 is also 1/2.
> 
> That would be true if you picked a door _after_ Monty revealed one of
> the doors.  It is not true if you have already picked a door.

Thanks for taking so much time for drawing the truth table. (I've
printed it out for later reference.)

However, I do not believe that the truth table is correct. I do believe
that the probability to win in this special case does *not* depend on my
knowledge regarding Monty's choice---wether or not I *know* which goat
door Monty will open. The probability to win is determined by the fact
that Monty will *always* open a door that does not contain the car. I
think that the truth-table may not contain the goat door Monty will
always open. It does only contain the door I have picked out and the
door that will *always* remain after Monty has opened the goat door.

Why do I think so? Because the algorithm Monty implements does *never*
leave me the choice to pick out the door Monty actually opens. But if I
never have the choice to pick out the door Monty actually opens, the
initial chances of winning are 50:50.

Interestingly, Monty's algorithm is required to be deterministic in the
cases where I have initially picked out a goat door. It may be
deterministic or not, in the case when I initially have picked out the
car door. If he would implement a completely non-deterministic algorithm
and choose a door randomly, his chance of picking out the car would be
1/3, and my chance of winning would be 1/3 as well.

What do you think of that opinion?

Regards,

Erich

------------------------------

Date: Mon, 5 Mar 2001 15:15:01 +0100
From: Anonymous <[EMAIL PROTECTED]>
Subject: passphrase question
Crossposted-To: alt.security.pgp

I was thinking about using a decryption passphrase for software like PGP
and the like that would consist of a very long string of characters like:

......aaaaaaaaaa$$$$$$$$$$$fffffffffffDDDDDDD5555


I would remember the passphrase by just remembering there are 7 periods, 10
a's, 11 $'s, 11f's, and 7 D's, and 4 5's.
So, the only thing in my mind would be 7 10 11 7 4 and the
characters/numbers used.  I know the security in public key encryption lies
in the protection of the private key, and that long private key passphrases
would make for a more secure system.  Not taking into account things like
keyloggers, remote electronic monitoring i.e TEMPEST, etc, just how secure
is this method choosing a long passphrase?

Just using the above letters once, the pass would be:
.a$fD5 which is 6 characters in length.

But I'm multiplying each character a number of times to get the pass.
7(.)11($)11(f)7(D)4(5)

My final passphrase length is 7 + 11 + 11 + 7 + 4 + 5 = 45, which satisfies
the long passphrase requirement, and brute forcing something of that length
would be difficult from what I've read on the subject.  But is the way I'm
choosing that long passphrase weak?  Is it any different that the original
7 character .a$fD5 passphrase when put up to a brute force?
Comments/answers much appreciated, and please reply to the newsgroup only.

Thanks,
gerry





--Part_Boundary-2678A6--




------------------------------

From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: 5 Mar 2001 15:12:25 GMT
Reply-To: [EMAIL PROTECTED]

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]>

------------------------------

From: Arturo <aquiranNO$[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography
Date: Mon, 05 Mar 2001 16:48:06 +0100

On Sun, 4 Mar 2001 17:07:48 +0100, "Henrick Hellström" <[EMAIL PROTECTED]>
wrote:

>"John Savard" <[EMAIL PROTECTED]> skrev i meddelandet
>news:[EMAIL PROTECTED]...
>> On Fri, 2 Mar 2001 18:43:52 -0500, "Ryan M. McConahy"
>> <[EMAIL PROTECTED]> wrote, in part:
>>
>> >http://www.cacr.math.uwaterloo.ca/hac/
>>
>> Wrong book....
>
>What's wrong about it? It is a book on applied cryptography, isn't it?
>
        He means it´s not the book you´re talking about.  That url is not to
Schneier´s AC but to the Handbook of Applied Cryptography, a good book, too.

------------------------------

From: [EMAIL PROTECTED] (Steve Meyer)
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Reply-To: [EMAIL PROTECTED]
Date: 5 Mar 2001 16:27:43 GMT

Sorry to need to follow up my own post but current Stanford Professor
V. Pratt not R. Rivest was the person who took J.H. Morris' linear time
pattern matching algorithm to Stanford.  I made the mistake because
Professor Rivest was a co-author in many of the linear time algorithms
(median finding comes to mind) and was a graduate student at
Stanford at the time.  Also, I believe his behavior in not
giving fair refereeing to my paper that falsified object oriented
programming shows the same pattern.  My related story but in
an different area of Computer Science is documented in paper
structprog.ps at URL ftp://ftp.pragmatic-c.com/papers/intended_thesis.dir.
R. Rivest is second editor.
/Steve

On 5 Mar 2001 04:02:54 GMT, Steve Meyer <[EMAIL PROTECTED]> wrote:
>I think the algorithm and analysis were described in a Stanford CS
>Department technical report from 1970.  I think Stanford CS technical 
>reports are on line, but I do not know if on line data base goes
>back that far.  I think you will also be able to find it in CS Library
>of any of the Universities that had early CS Departments, CMU, MIT,
>U of Wisconsin, etc. 
>/Steve
>
>On Fri, 02 Mar 2001 03:56:38 -0500, Nicol So <[EMAIL PROTECTED]> wrote:
>>Steve Meyer wrote:
>>> 
>>> Also, in 1969 there had been a different priority of discovery problem
>>> involving then assistant professor J.H. Morris' (now at CMU) involving
>>> Morris' discovery of linear string matching algorithm.  UC Berkeley
>>> computer science student R. Rivest (coincidentally later involved in
>>> RSA discovery?).  Graduate student Rivest transfered from UC Berkeley
>>> to Stanford and published the linear string matching algorithm with D. Knuth
>>> without giving priority of discovery (or even technical report authorship
>>> to J.H. Morris).  Morris complained and was added as an author although I
>>> believe at the time D. Knuth and R. Rivest claimed it was their discovery
>>> because they had performed the algorithm analysis.
>>
>>Do you have a reference to the paper? The Knuth-Morris-Pratt string
>>matching algorithm is well known and linear time, but I couldn't find
>>any reference to a paper jointly authored by Knuth, Rivest, and Morris.
>>According to Rivest's publication list at his website, the only paper he
>>has coauthored with Knuth seems to be one on string matching.
>>
>>-- 
>>Nicol So, CISSP // paranoid 'at' engineer 'dot' com
>>Disclaimer: Views expressed here are casual comments and should
>>not be relied upon as the basis for decisions of consequence.
>
>
>-- 
>Steve Meyer                             Phone: (415) 296-7017
>Pragmatic C Software Corp.             Fax:   (415) 296-0946
>220 Montgomery St., Suite 925          email: [EMAIL PROTECTED]
>San Francisco, CA 94104


-- 
Steve Meyer                             Phone: (415) 296-7017
Pragmatic C Software Corp.              Fax:   (415) 296-0946
220 Montgomery St., Suite 925           email: [EMAIL PROTECTED]
San Francisco, CA 94104

------------------------------

From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Avalanche in round keys.
Date: Mon, 5 Mar 2001 17:07:13 -0800

It would seem to me that a useful property of a round key generation
algorithm would be that for a single-bit change a large number of bits in
the round-keys are changed.... are there any papers discussing this?

Simon.



------------------------------

From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: won't you tell me something about my encryption scheme ?
Date: Mon, 5 Mar 2001 17:21:34 -0800


yomgui <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Simon Johnson wrote:
> >
> > > we generate one two-byte pseudo random number: aTwoByteRandNumber
> > > we xor them together: val1 = val0 XOR aTwoByteRandNumber
> > > we take the corresponding value in the grid: val2 = grid[val1]
> > > we xor with the same random number: val3 = val2 XOR aTwoByteRandNumber
> >
> > grid[x] must be 16-bit (and probably static s-box), aTwoByteRandNumber
is
> > 16-bit. What stops us from brute-forcing grid[x]?
> >
> > There are probably attacks much faster than this, we could probably get
a
> > differential through val3 = grid[(v0 xor aTwobyte..)] xor aTwobyte, and
> > recover grid[x] this way.
> >
>
> but before force bruting the grid, you need to find out the random
> series
> used to xor the stream.
>
> I would say, the grid is just their to modifie val1 into val2,
> which allow the main of the encryption to be performed in the two xor.
> from val0 to val1 and then from val2 to val3.
>
> you can certainly brut force on the password side, but there,
> a decent sized password (up to 256*256 bytes) should keep your
> encryption safe.

Yes, but consider this approach.... if aTwoRandomByteNumber = 0 then v0 goes
through grid[x], unchanged,  to give v3..... So we can get a large amount of
key-stream from this algorithm, we can simply guess the transformation
grid[x] and see if it matches what we get.

This should be faster than brute-force since we can also check guesses by
looking at when v0 = 0. When v0 = 0 we know that the PRNG has been
transformed by grid[x], exactly how to use this information i'm not sure;
this is probably where the diffential attack comes, either way this helps us
enhance our guess work.

Moreover, if we get two 0 stream outputs after another than we know that:

v0 for the last second stream output = 0
and that the output of the second stream-input:

grid[aRandomTwobyteNumber] xor aRandomTwobyteNumber =0

This can enhance our trial and error approach to a solution much faster than
brute-forcing grid[x], i think :).

Simon.
> --
> ¥øµgüí
> oim 3d - surface viewer - http://bigfoot.com/~oim



------------------------------

From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 17:19:21 GMT

Anthony Stephen Szopa wrote:
> No one ever said that the fclose() function writes anything to disk.

So why do you think the file is getting overwritten? Earlier you said
> "Closing a file does not mean that the cache has been written to 
> disk."  Is this your profound penultimate position upon which your 
> world rests?  FUD!
which would certainly imply that you think a successful return from fclose()
implies that the buffers have been written.

> Now let me get this straight.  You just post the documentation from
> UNIX of what the fclose() function does then you tell us that we
> (meaning you) don't know what the fclose() function does.

You don't know what the fclose() function does. All you know is what the
documentation does. That doesn't tell you everything the function does,
unless you also look at the documentation for close(), whatever close() maps
to in kernel32.dll, the device driver for the disk controller, and what the
firmware instructions on the hard disk controller do.

> If you are so knowledgeable then it should be absolutely no problem 
> to give us a few references from expert computer engineers /
> manufacturers supporting your exact position.

We've given you references. (And yes, I *am* an expert computer engineer.)
I've even given you simple proof. Let your drive spin down, then save a
small file from notepad. You can exit the program before the drive finishes
spinning up. 

Of course, you won't try this, since it would mean you're wrong. But you
already know you're  wrong, or you wouldn't have gone from claiming your
fwrite() worked to claming your fclose() worked to claiming your "if"
statement worked.

You are not interested in learning. You're only interested in being right.
Since you're *not* right, you have to resort to such stunningly logical
arguments as "you're a numbskull", something I haven't been called since
gradeschool. 

Fortunately, since I have no respect for you, your insults are meaningless
to me. Since you refuse to engage in any meaningful communication, I'll stop
wasting my time. Feel free to congratulate yourself for "winning" this
round, as I'm sure you will, and as I'm equally sure anyone else who looks
at this will understand.

The only thing I can't figure out is whether you're really fooling yourself,
or whether you really think you're fooling someone here.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.

------------------------------

From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Mon, 5 Mar 2001 17:38:08 -0800


Steve Meyer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 19 Feb 2001 05:03:43 GMT, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> >Steve Meyer wrote:
> >> I am not sure but there may be another class.  Namely, cryptography
> >> in which the encryption and decryption methods are kept secret.
> >
> >We don't worry much about those, because often enough in practice
> >there will be ways of finding out which system was used.  Thus
> >Kerckhoff's dictum: the secrecy of an encryption system must not
> >depend on lack of knowledge of the general system, but resides in
> >the lack of knowledge of the specific key.  (We could add that it
> >should also not depend on lack of knowledge about the plaintext
> >characteristics.)  By the way, the general process of figuring out
> >what system was used via analysis of message properties is called
> >"cryptodiagnosis".
>
> <snip - I am working on reply.  I am not sure how Rabin's provably
> secure random stream method effects my argument.
>
> >It will be interesting to see your argument.  I know of no
> >evidence that this was a factor.  If you turn the question
> >around and ask, why did workers for government cryptologic
> >organizations get there first, an obvious answer would be:
> >They had more experience, more support, and more at stake.
>
> I do not think they did, i.e. only evidence seems to be popular book
> (see my rump talk).
>
> >
> >Note that I've been arguing that P?=NP is not very important
> >in practical cryptology.
>
> If p==np, how can there be two way trap door functions?

p!= Exptime

So it should be possible to build a trapdoor function based on exptime
problems, but i'm not sure if one can check there guess in p-time for
exptime problems?

Even if you can't, it should still be possible to make a trapdoor function,
just its infeasible to use.

> I just uploaded my rump talk submission and slide to IACR E archive.
> Paper title is: 'Argument for "secret encryption method" cryptography.'
> Name of file is secret-encrypt-method.ps.  Postscript file is also
> avoilable at ftp://ftp.pragmatic-c.com in directory papers.  File
> name is same.
>
> --
> Steve Meyer
> Pragmatic C Software Corp.
> Email: [EMAIL PROTECTED]



------------------------------

From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Mon, 05 Mar 2001 17:39:09 GMT

Mxsmanic wrote:
> And Monty
> always shows a door with a goat behind it, never a door with a car
> behind it, so this shift in odds always works in favor of the unchosen,
> unshown door.  Therefore, if you switch choices, you double your chances
> of getting the car.

Which is, incidentally, why this isn't the way the game worked. After Monty
showed you the goat, you had your choice of sticking with your choice or
taking $100. You never got the chance to switch doors after Monty opened
one.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.

------------------------------

From: Ken Cox <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Mon, 05 Mar 2001 11:34:49 -0600

Fred Galvin wrote: 
> [...] I may as well assume that there's a goat
> behind door #3. Now, how does the decision I make, on the assumption
> that there's a goat behind door #3, differ from the decision I'd make
> if Monty opened door #3 and showed me a goat?

Your assumption may be wrong.  There may not be a goat
behind door #3.

As often happens with the Monty problems, you need an
*exact* statement of Monty's behavior.

-- 
Ken Cox                  [EMAIL PROTECTED]

------------------------------

From: Ken Cox <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Mon, 05 Mar 2001 11:38:21 -0600

"Joe H. Acker" wrote: 
> Why do I think so? Because the algorithm Monty implements does *never*
> leave me the choice to pick out the door Monty actually opens. But if I
> never have the choice to pick out the door Monty actually opens, the
> initial chances of winning are 50:50.

Monty also can't open the door that you initially picked,
nor can he open the door with the car.  Work it out.

-- 
Ken Cox                  [EMAIL PROTECTED]

------------------------------

From: Ken Cox <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Mon, 05 Mar 2001 11:36:51 -0600

"Joe H. Acker" wrote: 
> If Monty knows where the car is, and never opens the door with the car
> behind (as has been assumed), then the probability to win has to be 1/2.
> From the beginning, my chances to win were 1/2, because Monty always
> opens a door that doesn't contain the car.

Are you saying above that from the beginning, when you
initially chose among three doors, your chance of picking
the right door was always 1/2?

-- 
Ken Cox                  [EMAIL PROTECTED]

------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Avalanche in round keys.
Date: Mon, 05 Mar 2001 17:42:45 GMT


"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:980gs9$4nr$[EMAIL PROTECTED]...
> It would seem to me that a useful property of a round key generation
> algorithm would be that for a single-bit change a large number of bits in
> the round-keys are changed.... are there any papers discussing this?

Yup, look for papers on related key attacks and differential related keys.

Tom



------------------------------

From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 17:43:48 GMT

> > I would think it depends on your file system, too. For example, on a CD-R
> > file system, you can only write to each location once, so you obviously
> > *cannot* overwrite 27 times.

...

> You have just given us an alternate way of judging YOUR competence.
> Read my reply to the post you just replied to.

I didn't reply to you. I replied to Doug Gwyn. Duh. I was pointing out to Mr
Gwyn that even opening a file in r+w mode on a system other than UNIX
doesn't insure that the same blocks get overwritten. At least, not based on
the semantics of write() and close() or fwrite() and fclose().

*I* have a CD-R file system on my Windows machine. I'm pretty sure I'm not
overwriting the same sector 27 times on a CD-R.
 
> Where am I wrong?

I've explained that in other posts.
 
> Defend yourself.

I don't need to, since you're the one that's wrong and I don't care that
you're wrong.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.

------------------------------

From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 17:55:59 GMT

David Hopwood wrote:
> And yes, this does mean that if power is lost suddenly or the OS crashes,
> some changes may not be written, even though fclose succeeded.

Actually, I just loaded a "Windows Update" on my machine that added a
2-second delay after the OS flushes the disks before it actually removes
power from the drives during shutdown, to give the hard disk a chance to
actually finish the write. The behavior is well-documented on MS's update
web pages.

Now, maybe Mr Szopa would care to explain why, if fclose() makes sure all
the sectors are written, the OS has to wait two seconds for the write to
finish after all your programs have exitted.
 
-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.

------------------------------

From: [EMAIL PROTECTED]  (Free-man)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Mon, 05 Mar 2001 18:01:02 GMT

On Mon, 5 Mar 2001 12:07:00 +0100, "kroesjnov" <[EMAIL PROTECTED]>
wrote:

>> > I am willing to trade some privacy for safety.
>>
>> I'm not.
>
>Well, we don`t have to agree thank god :) (Or whoever you believe in...)
>
>> > All the points above, and afcourse more off them,
>> > carry less weight for me then a terrorist bombing
>> > my school, or some luny invasing my country.
>>
>> Unfortunately, all of them are also more likely than a terrorist bombing
>> your school or a nut invading your country.
>
>How many razi`s have taken place in your country in the last couple off
>years?

In my country (US), there are more government goons kicking down doors
and invading homes than there were in Nazi Germany. 

>When was the last time they purged your country from all the black
>people?

In my country, it is not fashionable to persecute people for the color
of their skin.  The current fashion is purge people with the wrong
color urine.  In fact, the self-proclaimed, drug-free supremists in my
country have  illegalized more humans than any other supremist 
group in history.    

>And when is the last time they bombed a building in your country? 

My country bombs buildings all the time in many countries.

>> > So call me young foolisch boy, who doesn`t understand
>> > these things, but my opinion stands.

I say that you are a person who has not yet begun to question 
the bullshit that is taught at government indoctrination centers
(government schools) and government-controled media.

Rich Eramian aka freeman at shore dot net 

------------------------------


** 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
******************************

Reply via email to