Cryptography-Digest Digest #795, Volume #13 Sun, 4 Mar 01 12:13:01 EST
Contents:
Re: won't you tell me something about my encryption scheme ? ("Simon Johnson")
Re: How good is the KeeLoq algorithm? (S�ren A.M�ller)
Re: HPRNG ("Simon Johnson")
OT: The Big Breach (book) available for download ("Sam Simpson")
Re: philosophical question? (Randy Poe)
Re: The Foolish Dozen or so in This News Group (Bob Harris)
Re: Was there ever a CRM-114 Discriminator? (John Savard)
Re: Text of Applied Cryptography ("Henrick Hellstr�m")
Re: The Foolish Dozen or so in This News Group (HiEv)
Re: super strong crypto, phase 3 (John Savard)
Dummy question about DES (Jan Panteltje)
Re: philosophical question? (SCOTT19U.ZIP_GUY)
Re: philosophical question? (Joe H. Acker)
Re: super strong crypto, phase 3 (Steve Portly)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Darren New)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Darren New)
----------------------------------------------------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: won't you tell me something about my encryption scheme ?
Date: Sun, 4 Mar 2001 14:21:17 -0800
yomgui <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> hello,
>
> I've developped my own, quite simple, encryption method.
> the source code is here http://bigfoot.com/~kryptyomic
> under the GNU Lesser General Public License.
>
> I describe here in few lines how it works.
> could you tell me what you think of it.
>
> I avoid the biggest mistakes, but you will probably
> find out some weakness that I missed.
>
> thanks, guillaume
>
>
> Kryptyomic encryption scheme:
>
> each letter of a password up to (256*256 bytes) is used as an unsigned
> byte integer value to seed a pseudo-random serie, a simple combo from
> the public domain: the period of the combo exceeds 2^60
>
> this combo can be replaced by any other pseudo random number generator.
In this case, this cipher will be slower than the secure pseudo-random
number generator that we use in your cipher... My point being, why not just
use the secure pseudo-random number generator instead?
> each random series is seeded with the password plus a pseudo random
> number from the previous serie.
>
> these series are used in random order to produce one new pseudo random
> number, and to determine the next series to use.
> then we use the next series to produce one number, and so on.
>
> the pseudo random series are used to generate an encryption grid
> this grid allows the replacement of a two-byte value by its
> corresponding unique two-byte value in the grid.
> a smaller grid of 256 bytes is used when single-byte encoding is
> necessary.
>
> the stream is considered as a succession of two-byte values.
>
> the value is obtained from the stream: val0
how big is val0, i assume 16-bits?
> 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.
>
> note: if we don't do the grid corresponding step, no encryption is
> performed. (ie. if val2 equals val1 then val3 equals val0).
> to perform decryption we follow the same method but before running the
> stream, we just reverse the grids once (such as val1 =
> reversegrid[val2])
------------------------------
From: S�ren A.M�ller <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Sun, 4 Mar 2001 15:21:48 +0100
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I'm not qualified to comment on the weak keys. Yes, they
> need to use lots of rounds because one round does so little.
> Every bit of the input block affects every other bit after 39
> rounds, and it takes 64 rounds to use every bit of the key.
> As you can guess from these numbers, they operate on one bit
> at a time. In terms of confusion and diffusion, they are
> heavy on the confusion and weak on the diffusion, which they
> make up for by using so many rounds.
I thought it was something like that.
Thanks again.
--
S�ren A.M�ller
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: HPRNG
Date: Sun, 4 Mar 2001 14:28:20 -0800
Frank Gerlach <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> > > Sorry to be nit-picky, but it aint a pseudo random number generator,
so
> > the
> > > name should be HRNG :)
> That there is randomness AT ALL, is a matter of religious belief, not
> science. Ironically, a lot of agnostics would most probably call quantum
> effects "truely random", but I can only call this a religious belief.
I agree that to some extent physics is a religion, however I think people
miss the point. Whether something is truly random or not makes no difference
to the security of the OTP and such other schemes. They pad should be just
be statistically unpredictable and non-reproducible.
On randomness in physics, it'd be hard to find a way to discredit random
number generation based in physics. Take something like the uncertainty
principle. As we know an objects position more and more accurately we know
less about its velocity. Now no matter what our theories are the
fundamentals of the universe do not change; uncertainty will exist whether
we like it or not and even in a completely deterministic universe there can
be uncertainty. Imagine we have an object which had an irrational velocity,
for example, we would always be uncertain to some degree to the velocity of
the object and this could be exploited. In this sense randomness is built
into mathematics, so its harder to refute.
I'm not saying physics isn't a religion (in many senses it is), what I'm
saying is that randomness as you mean it doesn't have to exist for the OTP
to be secure, but if it didn't at the quantum level, its intrinsic to any
number system used to describe our universe.
Yours,
Simon.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: OT: The Big Breach (book) available for download
Date: Sun, 4 Mar 2001 14:59:56 -0000
The book Big Breach (by R.Tomlinson, ex-MI6) is available for download at
the URLs below.....It's caused a lot of controversy in England, so is
probably worth a read ;)
Just so happens to have been released a week after I ordered my copy :(
--
Regards,
Sam
http://www.scramdisk.clara.net/
Acrobat PDF
Zipped - http://thebigbreach.com/download/bbpdf.zip
Unzipped - http://thebigbreach.com/download/bbpdf.pdf
MS Word
Zipped - http://thebigbreach.com/download/bbword.zip
Unzipped - http://thebigbreach.com/download/bbword.doc
Text
Zipped - http://thebigbreach.com/download/bbtxt.zip
------------------------------
From: [EMAIL PROTECTED] (Randy Poe)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: philosophical question?
Date: Sun, 04 Mar 2001 14:24:22 GMT
On Sun, 4 Mar 2001 11:54:38 +0100, [EMAIL PROTECTED] (Joe H. Acker)
wrote:
>So I would say that it's correct to claim that the possibility of the
>occurance of an all 1's sequence is inprobable compared to the occurance
>of *any* other sequence, but still the occurance of any *individual*
>sequence is as likely as that of any other *individual* sequence. That's
>trivial, and my confusion was based on a simple misconception. (Shame on
>me...)
OK. I think I follow what you're saying, and you've got it right.
So here's the extra-credit question to ponder: Suppose we have a
lottery consisting of 5 numbers from 1-9.
You pick a "random-looking" sequence like 5-1-8-3-4.
I pick 1-2-3-4-5.
Do you have a better chance of winning than I do?
- Randy
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 04 Mar 2001 10:30:40 -0500
Anthony Stephen Szopa recently wrote:
> ...
> As I have clearly stated above, the source code not only makes the
> fclose() command but it checks for the return value from this
> operation. If the return value is NULL then the fclose() has failed.
> And if the fclose() succeeds then the return value is zero. ...
>
> I do check pass / fail in the source code, as stated above.
> ...
I'm not going to get into the discussion of whether checking the return
value has relevance with respect to the file's disk sectors being written.
I'd just like to point out that, if you are checking pass/fail in the manner
you indicate, your check isn't checking what you think it is.
fclose returns EOF on failure, not NULL. In fact, in nearly every C or C++
implementation I've seen, there is little difference between NULL and zero
(they are different types, but have the same value otherwise). I'd be
interested to see what syntax you use to distinguish between NULL and zero.
and Sam Simpson wrote
> ...
>> His initials are Bill Gates.
> ...
>> What do you think?
> ...
>
> Let's hope your crypto software is better than your grasp of the English
> language, eh? ;)
Not that it much matters what I think, but I thought Anthony's use of
English, in the "initials" sentence, was quite clever and humorous. I've
heard that sort of line many times, and (to me) it's always funny. As in, "
I won't tell you who stole your lunch out of the company fridge, but his
initials are FRED SMITH". The other variant is "... his initials are F.
SMITH; no wait, that's too obvious ... his initials are Fred S.".
But Anthony, you really should give consideration to the other posts people
have made on this thread. I haven't seen the whole dicussion; I've only
seen the thread that started "Mar/3 at 20:50:32 -0800". From what I've
seen, they're factual posts, and they point out things which it would appear
that you haven't considered in your design.
To do the kind of thing you're trying to do, I think you have to have an
understanding of what is going on *below* your calls to fopen, fwrite, and
fclose, on every OS and architecture that your design is targeted for. In
other words, at a lower level, how are those calls implemented. You will
probably need to explore all the way into the disk controller firmware to be
able to be certain that you are overwriting the actual magnetic regions (on
the disk surface) that you are aiming at, 100% of the time. You're going to
need to consider how every component of this system works (the components
include your software, the OS, the disk driver, the firmware in the disk
controller, and perhaps other things), and what it does upon failure.
Hope this helps.
Bob
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Was there ever a CRM-114 Discriminator?
Date: Sun, 04 Mar 2001 15:31:53 GMT
On Sun, 04 Mar 2001 07:30:15 GMT, rob osattin <[EMAIL PROTECTED]> wrote, in
part:
>According to the Federation of American Scientists page on the B-52, one of
>its systems is a CRM-114 Discriminator. Here's the link:
>http://www.fas.org/nuke/guide/usa/bomber/b-52.htm
>This may be a joke by FAS, I can't tell.
It may simply be an error. Since they look far and wide for sources of
information, perhaps someone assumed the movie was correctly
researched in this particular.
Since CRM-114 occurs in other movies by Stanley Kubrick, I think it is
reasonable to suspect that it is something of personal significance to
him: my suspicion is that it may be the license plate number of his
first automobile. That is what makes the actual existence of such an
item as military hardware highly improbable.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Text of Applied Cryptography
Date: Sun, 4 Mar 2001 17:07:48 +0100
"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?
> But you can buy a copy of the .PDF of Bruce Schneier's
> book on the CD-ROM from Dr. Dobb's.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: HiEv <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Date: Sun, 04 Mar 2001 16:09:52 GMT
"Douglas A. Gwyn" wrote:
>
> I don't know to what you were responding, but here is the straight
> scoop on fclose etc.:
[snip]
For those wanting to see the beginning of this discussion, look for "Re:
OverWrite freeware completely removes unwanted files from harddrive".
If you do plan to respond to Mr. Szopa, you should be aware that he
often resorts to personal attacks instead of refuting the evidence.
For Mr. Szopa: this is not a personal attack, this is a statement of
fact. For an example see your reply to Scott Fluhrer below or the title
of this thread. You would fare better in this discussion if you did not
take the comments meant to help you so personally.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Sun, 04 Mar 2001 16:07:00 GMT
On Sun, 04 Mar 2001 04:49:40 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>First block's non-key plaintext (448 bits) shall be
>random bits, saved for use similar to an IV *for each subsequent
>block*.
I don't think that masking every block by a constant quantity can be
expected to improve security that much.
Before, when you suggested keeping some old key bits, and doing
partial updates of the key, I noted that this could be improved by
always (using another constant key) encrypting the mixed key before
use so that there would be no usable relation between keys. But using
a new key each time eliminates this issue.
I've noted also that I think the idea of sending a block encrypted
with one key with the key to encrypt the next block is a bit similar
to a scheme once called the "Aryabharata" cipher, and this new idea
sort of replaces having to solve two blocks together with having to
solve two Aryabharata problems together.
Instead of 448 + 64, then, we have to go to 384 + 128 to send a whole
key each time. Or maybe 896 + 128. But I think that it is necessary to
elaborate this kind of concept still further - and even then, there is
no 'provable security' here, just an extra layer that will make things
more difficult for the cryptanalyst.
Initial keys:
KA1 : initial block encrypting key
Ka : new key to block encryption key transformation key
KB1 : initial key encrypting key
Kb : new key to key encryption key transformation key
Kc : new key to mask encryption key transformation key
First block:
E(P1, KA1), where the first plaintext message P1 is composed of R,
random data 896 bits long, and K2, a 128-bit random vector.
Set:
M1 = R
KA2 = D( D( K2, KB1), Ka )
KB2 = D( K2, Kb )
Second block - and subsequent blocks follow the same pattern:
E(P2, KA2), where P2 is composed of 896 bits of plaintext sent in this
block, XOR M1, and K3, a 128-bit random vector.
Set:
KC2 = E(K3, Kc)
M2 = E(M1, KC2)
KA3 = D( D( K3, KB2), Ka )
KB3 = D( K3, Kb )
Thus: each block consists of 896 bits of plaintext and a 128-bit
random vector which is used as a source of keys.
First, the block is deciphered by the current regular key (KA2).
This obtains the plaintext XORed with the current mask (M1), and it
obtains the key source value.
The key source value (K3) is used to generate three keys.
The regular key for the next block (KA3) is obtained by decrypting the
key source value (K3) first with the current key decrypting key (KB2),
then with the permanent key to block encryption key transformation key
(Ka).
The key decrypting key for the next block (KB3) is obtained by
decrypting the key source value (K3) with the permanent key to key
encryption key transformation key (Kb).
Then, a key used to encrypt the mask value for use with the next block
(KC2) is obtained by decrypting the key source value (K3) with the
permanent key to mask encryption key transformation key (Kc).
This elaboration of your scheme achieves the following:
1) The mask is constantly changing,
2) There are keys which give a degree of independence to the channels
which convey the plaintext and the new keys, as well as to the
additional channel governing the changes to the mask.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Jan Panteltje)
Subject: Dummy question about DES
Date: Sun, 04 Mar 2001 16:34:47 GMT
If I have a des system with a secret key, is it in any way possible
to find out the key if I can send data (challenges) to that system
and read the reply?
So I know the algo used.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: philosophical question?
Date: 4 Mar 2001 16:43:35 GMT
[EMAIL PROTECTED] (Randy Poe) wrote in
<[EMAIL PROTECTED]>:
>On Sun, 4 Mar 2001 11:54:38 +0100, [EMAIL PROTECTED] (Joe H. Acker)
>wrote:
>
>>So I would say that it's correct to claim that the possibility of the
>>occurance of an all 1's sequence is inprobable compared to the occurance
>>of *any* other sequence, but still the occurance of any *individual*
>>sequence is as likely as that of any other *individual* sequence. That's
>>trivial, and my confusion was based on a simple misconception. (Shame on
>>me...)
>
>OK. I think I follow what you're saying, and you've got it right.
>
>So here's the extra-credit question to ponder: Suppose we have a
>lottery consisting of 5 numbers from 1-9.
>
>You pick a "random-looking" sequence like 5-1-8-3-4.
>
>I pick 1-2-3-4-5.
>
>Do you have a better chance of winning than I do?
>
> - Randy
>
>
Yes the guy with the random pick stands to win more money
than you. Here is the reason why. I use to watch idiots as I
played poker in California play the live california keno game.
I know some idots play a set of numbers very much like yours.
Well a lady hit most her numbers one time and started dancing
around the room. SHe was sure she had won thousands of dollars since
so many of her numbers came in.
Well she got less that 10 bucks. Since a lot of other brainless
idots picked the same set of numbers.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: philosophical question?
Date: Sun, 4 Mar 2001 17:46:31 +0100
> So here's the extra-credit question to ponder: Suppose we have a
> lottery consisting of 5 numbers from 1-9.
>
> You pick a "random-looking" sequence like 5-1-8-3-4.
>
> I pick 1-2-3-4-5.
>
> Do you have a better chance of winning than I do?
Certainly not. But if other people play as well, and wins are shared,
and more people bet on patterns like 1-2-3-4-5, you're likely to win
less than I would---in case any of us wins ;)
Here's my question to you, which is only interesting if you haven't yet
heard about it:
You participate in a TV-show and can win a car. The car is behind one of
three doors, behind the two other doors are goats. You have to choose
one door and choose door number 1. It is kept close. Now the moderator
knows behind which door the car is, and says: "I'll show you something."
He opens door three and behind the door is a goat. Then he asks: "Would
you like to stay with door number 1 or do you want to choose door number
2?"
Are there better chances to win if you choose door number 2?
Well, that's a rather old one, but I still find it very interesting. :)
Greetings,
Erich
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Sun, 04 Mar 2001 11:58:00 -0500
"Douglas A. Gwyn" wrote:
> Recapitulating the development so far:
> Any reasonable symmetric encryption using a shared initial key, say
> 128 bits. One-way channel monitored by the world's greatest
> cryptanalytic team. Replacement random key sent every so often,
> embedded in the plaintext, say at the end of each block of 512 bits.
> I suggested that only half the new key be sent and be shifted into the
> previous one, so 64 bits of new key would be sent, for 12.5% overhead.
>
> So far it is clear that a known-plaintext attack is infeasible.
> That leaves open some possible avenues of attack, which phase 3
> addresses: First block's non-key plaintext (448 bits) shall be
> random bits, saved for use similar to an IV *for each subsequent
> block*. I.e. to send block N > 0, build the key by shifting key
> N-1 and adding in the key bits from block N-1; XOR the next 448
> message bits with the saved 448-bit "IV" from block 0, append 64
> more random bits for use in the next key, and encrypt using the
> latest built key. Note that this completely foils *any* single-
> block attack, in addition to addressing the issues that IVs are
> usually used for. The only remaining possibility for cryptanalysis
> would have to involve simultaneous analysis of multiple blocks,
> which offers some hope for the analyst since the "IV" remains
> constant across blocks. However, with a different key for each
> block it is hard to see how any differential attack could be
> mounted. (The use, in a different role, of half the key bits
> between adjacent blocks can be eliminated; I only suggested that
> to cut down on rekeying overhead.) One could consider some more
> complicated use of the "IV" than mere XOR, but as a starting
> place we might as well keep it simple.
In a realistic situation where a terrorist develops a "super strong"
cipher the algorithm might be expected to be kept secret. Simultaneous
analysis of multiple blocks would be difficult or impossible due to the
near infinite number of algorithms that may have been used to produce the
cipher text. This is assuming the cipher text is unbiased and
statistically random. You implied that the amount of cipher text under
analysis might be in the order of several million bytes. If this amount
of cipher text were presented to the "world's greatest cryptoanalytic
team" to crack and the terrorists demands were for a million dollars,
would it be cheaper to pay the terrorist or to pay the cryptoanalytic
team? You mentioned that XOR was being used to produce cipher text so
something is known about the algorithm already. Statistical analysis
might find some bias or pattern in 2 million bytes of cipher text that
would give some additional information about the algorithm.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 17:02:45 GMT
Anthony Stephen Szopa wrote:
> So in order for the FUD you are all casting against Ciphile Software's
> OverWrite program to succeed and to cover up your own ignorance of the
> pass / fail return values of all functions, you will have to claim
> that the OS not only optimizes write operations as you describe but
> in fact LIES because the OS has no idea whether or not a close or open
> function was carried out successfully until it is actually PHYSICALLY
> carried out.
That is correct.
Try this simple test under Windows98, for example.
Open a new file in notepad. Put in a few lines of text. Save it.
Wait for your hard drive to spin down a la power-saving.
Change the text in the file, and say "file->save".
Note that you can type new text (meaning fclose() has returned) before the
drive finishes spinning up again.
Note that I don't expect you to actually *try* this, since it might
challenge your finely honed worldview.
> Do any of you claim that any OS that you know of actually fudges and
> outright LIES when an instruction is given to carry out a function()
> then claims to the compiled program that the function was carried out
> successfully when the OS has no way of knowing this until the
> function has actually physically been carried out just so as to
> optimize its resources?
Yes. That's what we're claiming.
What exactly does "fclose()" promise? Only that the file is closed.
> The specific functions we are talking about
> here are the fclose() and fopen() functions. Can't get more basic
> than these.
Err, you can get a *lot* more basic than these.
fclose() calls close() which calls block device reads and writes which calls
int13 which calls SCSI commands. You do realize that (for example) SCSI
disks have their own processors on board, and that YOUR PROGRAM ISN'T EVEN
THE ONE WRITING TO THE DISK?
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Randomness: "To err is human"
Pseudo-randomness: "That air is from beans."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 17:02:45 GMT
Anthony Stephen Szopa wrote:
> "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!
Uh, from the UNIX manual pages...
DESCRIPTION
The close() function will deallocate the file descriptor
indicated by fildes. To deallocate means to make the file
descriptor available for return by subsequent calls to
open(2) or other functions that allocate file descriptors.
All outstanding record locks owned by the process on the
file associated with the file descriptor will be removed
(that is, unlocked).
[Note the complete lack of any mention of actually writing data]
ERRORS
The close() function will fail if:
EBADF The fildes argument is not a valid file descrip-
tor.
EINTR The close() function was interrupted by a signal.
ENOLINK The fildes argument is on a remote machine and the
link to that machine is no longer active.
ENOSPC There was no free space remaining on the device
containing the file.
The close() function may fail if:
EIO An I/O error occurred while reading from or writ-
ing to the file system.
[Note how it *MAY* fail if an I/O error occurred. That's because of the
buffering]
> As I said, your position ultimately leads you to NoWheresville.
Ooo. That'll teach us. NoWheresville.
> Here is what you are saying, just follow your own illogic:
>
> I code the fclose instruction. I place an if statement to see that
> the close is carried out successfully. If it is then the program
> continues; if not the program exits.
Right.
> You are saying that a conditional statement upon which the very
> foundations of computer programming rests is randomly and
> arbitrarily ignored. If this could be done with any reliability
> then the algorithm that makes these decisions would be known as not
> mere artificial intelligence but as man made machine clairvoyance.
No. What we're saying is that you don't know what the fclose() statement
does. It's possible for fclose() to succeed with no I/O to the disk at all.
> But when a file is explicitly closed and a condition is placed on the
> success or failure of the outcome of this operation then you are out
> of your tree.
No, you're just ignorant.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
Randomness: "To err is human"
Pseudo-randomness: "That air is from beans."
------------------------------
** 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
******************************
