Cryptography-Digest Digest #818, Volume #13 Tue, 6 Mar 01 09:13:00 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: 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: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: Monty Hall problem (was Re: philosophical question?) ([EMAIL PROTECTED])
Thanks ("Latyr Jean-Luc FAYE")
AES and DES ("Latyr Jean-Luc FAYE")
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:13:48 -0800
David Hopwood wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Anthony Stephen Szopa wrote:
> > I understand your optimization explanations and those given in the
> > few documents I have read. I was also familiar with the fact that a
> > block of data is read and stored into the cache and the reasons for
> > this. I believe that the assumption in the documentation and in your
> > casts of doubt was that the opened file that is repeatedly written to
> > is never instructed to be closed.
>
> No, that was not the assumption. fclose (with a return value of 0,
> indicating success) does not guarantee to write changes to disk. You
> may not like that, but what you would like the OS to do is irrelevant:
> the behaviour of Windows 3.1x, Windows 9x, Windows NT, and almost all
> variants of Unix is that the changes may not be written to the disk
> controller, if those blocks are written to again or if the file is
> deleted before the cache is flushed. In all modern disk drives, the
> disk controller will also do its own caching.
>
> (IIRC Win3.1x and Win9x have options to disable write-behind caching,
> but an application program should not rely on it being disabled.)
>
> 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.
>
> > 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.
>
> You're not only incompetent to write secure overwriting software,
> you're incompetent to write any C program, if you think fclose
> returns NULL on failure. RTFM.
>
> > You do have one last hope. His initials are Bill Gates.
>
> No, this time it's not Bill's fault. Write-behind caching is the
> expected default behaviour on any reasonable operating system (and
> besides, the disk controller still caches even if the operating system
> does not).
>
> - --
> David Hopwood <[EMAIL PROTECTED]>
>
> Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
> Nothing in this message is intended to be legally binding. If I revoke a
> public key but refuse to specify why, it is because the private key has been
> seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBOqHn0jkCAxeYt5gVAQERwAf+N72QfOUdOvYEruaa51BRKYSmwezV/8mS
> 86GjegCrC4eO2D5dYxqszInyHq4ETYUM9VPd97e2KApceBCozxWd38h55w7NXBrp
> TEJO+6vmRnI4JI89xdZu/qyTRJCrBJ6xhdHjen2xV4sf7IDkdfAvZbOtQGO1PuGs
> gxxCUjnkfvyXwJyktMyx4vJAeUtLmfECK75Xw8t2ogBOD1g4jpBWLcIce9Zcy3qS
> Y0MvwjuBVpWX0Jwclnw2OsLhOmq9UfvsiW+j+k+e8lUUGFt9NtBp5Buorb4ds9ck
> 9R3ThxhX7K+l8JVjj9h7h90hY5774N2UoKFrpqkmGQj3CAdxVWODIw==
> =5xxT
> -----END PGP SIGNATURE-----
WE have nothing to talk about since you are incompetent at reading.
Here is what I posted in the post you are replying to here:
"P.S. EOF for error in fclose() and NULL for error in fopen()"
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:15:18 -0800
Paul Rubin wrote:
>
> David Hopwood <[EMAIL PROTECTED]> writes:
> > No, this time it's not Bill's fault. Write-behind caching is the
> > expected default behaviour on any reasonable operating system (and
> > besides, the disk controller still caches even if the operating system
> > does not).
>
> And the disk DRIVE still caches if the controller does not, and it may
> flush its caches to places on the media where software can't reach, but
> forensic data recovery can.
Does that not apply to floppy disks as well? Or are these an
exception?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:17:09 -0800
Darren New wrote:
>
> 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.
In any event, I updated the OverWrite software by adding one simple
line of code that is only 8 characters long for each pass.
Now when you run it you can see it go to the hard drive 27 times
just by watching your hard drive LED access light and perhaps by
listening to your hard drive as well. Choose a file about 2 - 6
KB for starters. Depending on the file size it may access the hard
drive more than this: it appears that it works in multiples of 27
but they can get hard to count. Depending on the file size some
parts of multiple accesses for a single pass on larger files can
be pretty short.
I could see the hard drive access LED clearly lighting up 27 times.
I had to cup my hand over the LED to make it dark enough so I could
see it clearly. Can't hear much on my one system's hard drive but
I can sure hear it on my other system's hard drive.
You can download Ciphile Software's OverWrite Security Utility
(UPDATE) Version 1.1 at http://www.ciphile.com now.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:20:22 -0800
Eric Lee Green wrote:
>
> On Sat, 03 Mar 2001 20:50:32 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> > wrote:
> >2) If the file opens properly then it is overwritten.
>
> >I understand your optimization explanations and those given in the
> >few documents I have read. I was also familiar with the fact that a
> >block of data is read and stored into the cache and the reasons for
> >this. I believe that the assumption in the documentation and in your
> >casts of doubt was that the opened file that is repeatedly written to
> >is never instructed to be closed. In other words, a seek to the
>
> Closing a file has nothing to do with it. All a close does is tell the
> filesystem functions to remove the association between a filehandle
> and a file on disk. The buffer cache layer writes out the buffer
> whenever it feels like it, or when told to by an 'fsync' call. If you
> open and write that same file again it makes no difference as far as
> the buffer cache layer is concerned.
>
> In addition, there is an additional buffer cache that you must
> consider, and this is the buffer cache that is actually inside the
> hard drive. This is especially true for SCSI hard drives with
> disconnect capability. These hard drives have their own internal
> scheduler that you have absolutely no control over at the OS level. If
> you have sixteen writes, what happens is that those sixteen writes get
> transferred to the hard drive's buffer cache. If those sixteen writes
> are all to the same sector, the hard drive has the option to throw away
> the first fifteen writes. This is part of the T-10 SCSI-3 standards
> (see http://www.t10.org/drafts.htm ).
>
> >operation. If the return value is NULL then the fclose() has failed.
> >And if the fclose() succeeds then the return value is zero. This is
>
> And as I mentioned, fclose() has absolutely nothing to do with things.
> fclose() is a "C" library function. It flushes any internal buffers that
> it has associated with the filehandle, then calls the low level OS function
> to actually remove the association between filehandle and file on disk.
> None of this affects the buffer cache on disk.
>
> >carried out. To optimize as you all have been claiming in Ciphile
> >Software's OverWrite program, the OS would have to LIE that it had
> >successfully closed the file in order to proceed to carry out a
>
> First of all, as I mention, 'fclose()' is not an operating system function.
> It is a "C" library function. The definition for 'fclose()' in the "C"
> standard specifically states that fclose() *MAY* return an error if
> the underlying operating system function fails -- but does not state
> that it *MUST* return an error if the underlying OS functions fail.
>
> Again: fclose() is *NOT* an operating system function! It does *NOT* do
> anything other than flush the "C" library's internal buffers -- it does
> *NOT* flush the underlying operating system's disk buffer cache!
>
> >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()
>
> Calls like fclose() know only what they are told by the underlying operating
> system. And the "C" standard does not require them to report anything
> told to them by the underlying operating system.
>
> >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? The specific functions we are talking about
> >here are the fclose() and fopen() functions. Can't get more basic
> >than these.
>
> Err, fclose() and fopen() are *NOT* operating system functions. They are
> "C" library functions. They do *NOT* control the underlying operating system
> buffer cache. They do *NOT* control the underlying SCSI hard drive cache,
> which has its *OWN* built in optimizer.
>
> >I hear that LSD and DMT are great therapies for narrowing the gaps
> >in one's conceptual continuity.
>
> Ah. So that is your problem. You got too much LSD. Okay.
>
> So let me spell it out to you:
>
> *I WRITE LOW LEVEL SCSI CODE*. That is my job. You can verify that this
> is my job very easily by going to http://mtx.sourceforge.net .
> And that's only a subset of what I do at the SCSI level. The T-10
> manuals are my friend, my bible, my well-thumbed three-inch-thick glob
> of paper.
>
> In other words, I have first-hand experience with how SCSI schedulers
> work at the OS level on Linux, FreeBSD, and Unix. Granted, this is not
> with Windows NT, but I seriously doubt that NT's SCSI scheduler does
> differently, because out-of-order writes and optimizations are the
> fastest way to do the job. I do know that Windows NT has benchmarked
> faster than Linux on some benchmarks, so if anything they probably
> MORE HIGHLY schedule their SCSI writes.
>
> >(I only get a good laugh like this once in about three months.)
>
> I'm not laughing. It's a pity you're so ignorant of how modern
> operating systems and modern hard drive hardware work internally. I
> know that not everybody can be smart enough to understand buffer cache
> mechanisms, elevator algorithms, and T-10 SCSI manuals, but when you
> then claim that your ignorance of how this works means that your
> software works, (shrug). I can think of ways to make your software work,
> but fopen() and fclose() definitely won't do it -- you'll have to go
> down to the raw SCSI level. Read the T-10 manuals, please, before you
> further make a fool of yourself.
>
> --
> 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! =-----
Are you qualifying this to be restricted to hard drives only?
Or do you mean all this applies to floippy disks, too?
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 05:31:11 -0800
Doom the Mostly Harmless wrote:
>
> It occurs to me that, however many foolish people there are in this news
> group, you are certainly one of them.
>
> After a certain point, it doesn't really matter whether your software does
> as you claim or not. By now, you've convinced those who will ever believe
> you, and will never convince those who openly criticize your posts.
>
> Your personal attacks on those who do criticize you, while often amusing,
> aren't really doing much besides pissing people off and hurting your
> reputation. Personally, I'm far less inclined to believe you because of
> these attacks than because of any technical arguments by those you seem to
> have designated opponents.
>
> Why? Because, imho, the point of this newsgroup is not to create enmity or
> take sides so much as share information and point out flaws in others' work
> in an open forum. If you don't want your software criticized, don't post
> news about it in a newsgroup designed to improve software, theory, etc.
> through constructive criticism. Most of the posts I've seen aren't of the
> nature "You're stuff is shit, shut the hell up!" so much as "It seems to me
> that you will encounter problems x,y,and z. How do you deal with them?"
> which is exactly what this newsgroup is about.
>
> I recognize that I'm not an expert on cryptography or cryptology, and am not
> a regular poster. I'm not well known here, but I have been lurking on and
> off for over a year and a half, and have come to believe that, while there
> are occasional bouts of spurious rudeness, most of the wars are started by
> people who come expecting god-like status because they've done something
> they think is cool, or wizardry, or unique. People like you.
>
> Perhaps I'm wrong about some or all of this. For all I know, this
> dissention has boosted sales by 150%. Or perhaps you just enjoy shooting it
> out in the trenches. Maybe I'm the only one who thinks this newsgroup is
> all about constructive criticism.
>
> --
> To air is human....
> --Doom.
No.
I like my software to be criticized if the criticism has merit.
How about this: "Your interface sucks!"
Now that's criticism.
I performed a test using a floppy disk. And I updated the OverWrite
software.
I updated the OverWrite software by adding one simple line of code
that is only 8 characters long for each pass.
Now when you run it you can see it go to the hard drive 27 times
just by watching your hard drive LED access light and perhaps by
listening to your hard drive as well. Choose a file about 2 - 6
KB for starters. Depending on the file size it may access the hard
drive more than this: it appears that it works in multiples of 27
but they can get hard to count. Depending on the file size some
parts of multiple accesses for a single pass on larger files can
be pretty short.
I could see the hard drive access LED clearly lighting up 27 times.
I had to cup my hand over the LED to make it dark enough so I could
see it clearly. Can't hear much on my one system's hard drive but
I can sure hear it on my other system's hard drive.
You can download Ciphile Software's OverWrite Security Utility
(UPDATE) Version 1.1 at http://www.ciphile.com now.
I took a blank floppy and I copied one file that was 859KB to it
then I copied another file to this same floppy that was 322KB.
Then I created an OverChk2.txt file to flag the process after just
two passes. This should be enough to prove my points.
Then I ran the original OverWrite Program Version 1.0 and overwrote
the larger 859KB file. After the second pass the OverChk2 flag file
was detected and the process ended.
I did a file compare on the 322KB file with its original file and
there were no differences.
I then used the Read Utility from the OAP-L3 (OAR-L3) software and
the file was overwritten completely with binary 170 just as it should
be
after two overwrite passes.
Once the OverWrite program was loaded there were no hard drive
accesses. There were only continuous floppy drive accesses. You
could see the access light and hear the drive writing all the while.
You could even hear the distinct sound when the write head had to
track back to the beginning of the file to begin the second pass.
What does this show: the OS had no need to work in secondary cache
as evidenced from there being no hard drive accesses.
The OS did not utilize any cache because you could see and hear that
the floppy write process was continuous for two write passes.
There is no read instructions coded into the program. Just an
initial file seek to get the file length.
Since the 322KB file on the floppy was exactly as the original the
OS did not use any additional floppy disk space. The entire
operation was confined to the space bit for bit of the 859KB file.
So indeed a perfect byte for byte overwrite was executed with no
cache operations just a I described from the beginning.
I then ran the same test from scratch using a blank floppy using the
updated OverWrite program Version 1.1 and the results were the same.
Do any of you dispute this floppy drive test?
Try it yourself.
"Well. I guess we can at least be sure this Ovewrite Program works
on floppies."
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: 6 Mar 2001 08:43:13 -0500
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Joe H.
Acker) writes:
> Mxsmanic <[EMAIL PROTECTED]> wrote:
>
>> "Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>>
>> > Interestingly, this can be tested empirically. All
>> > you need is a good TRNG based on radioactive-decay
>> > and a function that takes input from the TRNG to
>> > produce an unbiased random number in an integer range.
>>
>> I've done it, with a standard PRNG. The empirical results still say
>> that you should switch doors; you double your chances of winning that
>> way.
>>
>> > If I'm wrong, the first iterated run should create
>> > a 33% and the second run a 66% winning rate.
>>
>> In my tests, it did.
>>
>> > Any volunters? (I don't have a TRNG...)
>>
>> It doesn't have to be a TRNG; a PRNG will do.
>
> My tests are contradicting to your test. They give a 50:50 result.
I translated your code to Fortran, ran it and got a 66/32 result on
two trials of size 100.
Did you actually run your code or did you simply fudge the results?
John Briggs [EMAIL PROTECTED]
> Function MontyHall(iterations as Integer, alwaysSwitching as Boolean) As
> Integer
> Dim doors(2) as Integer
> Dim choice, monty_choice, car_door,i, j, counter as Integer
>
> CONST goat = 0
> CONST car = 1
>
> for j = 1 to iterations
> // assign car randomly to one of the doors
> car_door = Random(2)
> doors(car_door) = car
>
> // contestand picks out a door
> choice = Random(2)
>
> // Monty's algorithm
> if doors(choice) = car then
> // contestant has picked out the car door
> // Monty picks out any of the two remaining doors
> // deterministically, but could also be randomly chosen
> monty_choice = choice + 1
> if monty_choice > 2 then
> monty_choice = 0
> end if
> else
> // contestant has chosen a goat door
> // Monty determines the remaining door that is not the car door
> // the loop is indeed a stupid way to do this...
> for i = 0 to 2
> if i<>choice and i<>car_door then
> monty_choice = i
> exit // only one door can be the correct one, exit loop
> end if
> next
> end if
>
> // evaluate the result
> if alwaysSwitching then
> for i = 0 to 2
> if i<>choice and i<>monty_choice then
> choice = i
> exit
> end if
> next
> end if
> if doors(choice)=car then
> counter = counter + 1
> end if
>
> // reset
> doors(car_door) = 0
> next
> return counter
> End Function
options /extend_source
program monty
implicit none
integer doors(3)
integer goat, car
parameter ( goat = 0 )
parameter ( car = 1 )
integer iterations
integer switching
integer seed / 12345 /
integer choice, monty_choice, car_door, i, j, counter
read ( 5, * ) iterations
read ( 5, * ) switching
type *, 'iterations = ', iterations
if ( switching .ne. 0 ) then
type *, 'with switching always strategy'
switching = .true.
else
type *, 'with never switch strategy'
switching = .false.
end if
do j = 1, iterations
car_door = 1 + 3*ran(seed)
doors(car_door) = car
choice = 1 + 3*ran(seed)
if ( doors(choice) .eq. car ) then
monty_choice = choice + 1
if ( monty_choice .gt. 3 ) then
monty_choice = 1
end if
else
do i = 1, 3
if ( i .ne. choice .and. i .ne. car_door ) then
monty_choice = i
end if
end do
end if
if ( switching ) then
do i = 1, 3
if ( i .ne. choice .and. i .ne. monty_choice ) then
choice = i
end if
end do
end if
if ( doors(choice) .eq. car ) then
counter = counter + 1
end if
doors(car_door) = goat
end do
type *, 'total iterations = ', iterations
type *, 'total cars = ', counter
end
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: Thanks
Date: Tue, 6 Mar 2001 13:51:43 -0000
I want to thanks everybody.
I am a new user of newsgroup and as well a beginner in cryptography.
I have appreciated each contribution at its value.
Regards
Latyr
--
Latyr Jean-Luc FAYE
http://faye.cjb.net
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> Hi everybody,
>
> I am looking for a source code (in C/C++, VB, VHDL or Java) to implement
the
> DES Cipher.
> The system should perform both encryption of 64bit blocks of plaintext and
> decryption of 64 bit blocks of ciphertext.
> The system should be modular in nature with separate module implementing
the
> various elements of the algorithm.
> The operation of the system should be verified by using various plaintext
> and keys.
>
> The best would be in C/C++
>
> Thanks in advance
>
> --
> Latyr Jean-Luc FAYE
> Ing�nieur G�nie Logiciel
> Master Eng in Telecommunications
> http://faye.cjb.net
>
>
------------------------------
From: "Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]>
Subject: AES and DES
Date: Tue, 6 Mar 2001 14:00:05 -0000
Hi
As I told in my previous submission, I am begining in Crypto.
I red some stuff about AES that will replace DES.
Can somebody explain me the differecences and the advantages.
A brief dicuss or some useful links with this informations.
Regards
Latyr
------------------------------
** 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
******************************
