Cryptography-Digest Digest #802, Volume #13 Mon, 5 Mar 01 00:13:01 EST
Contents:
Why do people continue to reply to Szopa? (Paul Crowley)
Re: sci.crypt? (David A Molnar)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Benjamin
Goldberg)
How 'bout Borg whore Yelena Perhunkova? She's a Internet Cock Huntress - ask Igor
Chudov {Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER ("--"
<-<alexplore@alexplore>->)
Re: super strong crypto, phase 3 (John Savard)
Re: Monty Hall problem (was Re: philosophical question?) (Adam Stephanides)
Re: The Big Breach (book) available for download (Fogbottom)
Re: "RSA vs. One-time-pad" or "the perfect enryption" (Steve Meyer)
Re: super strong crypto, phase 3 (Steve Portly)
Re: The Foolish Dozen or so in This News Group (Crypto Neophyte)
----------------------------------------------------------------------------
Crossposted-To: alt.hacker
Subject: Why do people continue to reply to Szopa?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 05 Mar 2001 01:54:54 GMT
William Hugh Murray <[EMAIL PROTECTED]> writes:
> Dan Beale wrote:
>
> > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > <snip everything>
> >
> > Having cleared my kill-filter i am _amazed_ to find you still trolling the
> > crypto groups Anthony. Have you learnt any math yet?
>
> No, but not because we have not tried to teach him.
>
> Would you leave if you were getting the attention he gets?
Can someone explain this to me? I've never written an article that
addressed Szopa directly, and I never plan to; he's clearly a loon who
will never learn anything. 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. Yet many highly intelligent
and knowledgable people waste a great deal of effort trying to explain
basic facts about computer security to a man who is clearly unable to
grasp them. Why?
If you think he's a troll then don't feed him. If you think (as I do)
that he's sincerely clue-resistant, what's the point?
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: sci.crypt?
Date: 5 Mar 2001 02:09:54 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Does anyone know the exact date sci.crypt was last a discussion forum about
> "scientific cryptography"?
there's some discussion here which is of scientific merit. it comes and goes.
most recently, I've been skimming the discussion of Rabin's new scheme.
almost all of it is civil, and most of it is thoughtful. I haven't had the
time to read other threads.
> I want to make a head stone for the group... hehehe
I'm not sure that it's worse here than elsewhere on Usenet.
> Can we come to a consensus of "on topic" traffic please? I see cross posts
> from alt.kkk, alt.2600, alt.pedophile.looky.here, etc... seriously...
who's "we" ? I doubt that any of the "regulars" are crossposting to these
groups, and I also doubt that others will pay much attention to a followup
scolding them for being off-topic.
-David
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 02:33:06 GMT
Anthony Stephen Szopa wrote:
>
> Benjamin Goldberg wrote:
> >
> > Szopa, you are an utter moron. Didn't you read what I wrote?
> >
> > A sucessful close operation merely means that the entry in the list
> > of open files is removed.
> >
> > Sure, your program "closes" sucessfully.
> >
> > What does that have to do with disk writes?
> >
> > You call the fclose() instructioction, which in turn calls close()
> > on the file descriptor. It's removed from the list of open files.
> > The dirty pages remain in cache. (The OS will write them out,
> > eventually, but nothing has yet happened to make this urgent.) You
> > open the file again. This creates a new entry in the list of open
> > files, and returns an index to that list (the file descriptor).
> > IIRC, This becomes the _fildes element of the (FILE*) struct. You
> > write to the file. The OS says to itself, hey, I still have some
> > dirty pages in cache for that file, and so your write() operation
> > modifies the contents of those pages. You call close again. It
> > successfully removes the entry from the list of open files. It
> > therefor returns a 'sucess' value. etc, etc.
> >
> > At no point is close returning sucess when it actually failed;
> > however, at no point does sucess imply an actual hardware write
> > operation.
>
> Check this out.
>
> "Closes a stream.
>
> fclose closes the named stream. All buffers associated with the
> stream are flushed before closing. System-allocated buffers are
> freed upon closing. Buffers assigned with setbuf or setvbuf are
> not automatically freed. (But if setvbuf is passed null for the
> buffer pointer it will free it upon close.)"
>
> AND
>
> "Remarks
> The fclose function closes stream. _fcloseall closes all open
> streams except stdin, stdout, stderr (and, in MS-DOS�, _stdaux
> and _stdprn). It also closes and deletes any temporary files
> created by tmpfile. In both functions, all buffers associated
> with the stream are flushed prior to closing. System-allocated
> buffers are released when the stream is closed. Buffers assigned
> by the user with setbuf and setvbuf are not automatically released."
>
> Tell us: when an OS flushes its buffers associated with an output
> stream what does the OS do to make sure that the data in those buffers
> is not lost since there is an immediate write command just before the
> fclose command?
It's not the OS flushing it's buffers, it's the C library flushing it's
buffers.
There are [at least] 3 different levels that need to be dealt with.
FILE* / Program level buffers. This is a pointer to a structure, which
contains, among other things, a buffer of bytes, and a file descriptor.
File descriptor (no buffers) This is an index (usually an integer, but
possibly a struct containing an integer) into a table maintained by the
OS describing each of the input and output objects.
device driver / OS level buffers. The device driver is what handles
write() calls. It uses the info stored in the program context's file
descriptor table, and in it's own internal data, to determine if a
write() is to a page of data that's in memory or one that's on disk. If
the place being written to is on disk, the driver loads that page (from
the hardware) into memory, and then the write() operation modifies that
page and marks it as dirty. Note that the write() operation does not
actually write to hardware. Of course, loading one page may fill up the
computer's memory, forcing another page *out* of memory. If the page
being forced out of memory is dirty, it is written to disk (either to
swap space, or to somewhere in the file system, depending on what it was
used for).
Disk / On board buffers. The disk driver is what handles actual,
physical reads and writes to the disk. It doesn't see anything about
'files' only about sectors. It may also do compression (see elsewhere
in the thread the effects of this).
> Here is the code sequence:
>
> write to disk (this commands to write the data waiting in the
> associated buffers to disk.)
Actually, since you're using fwrite, I assume, this actually writes to
the buffer that the C library (stdio library) maintains. If these
buffers fill up, it calls on write() to send the data to the OS (device
driver).
> fclose() (this will among other things flush the associated output
> stream buffers)
Yup. It sends all the data that's in program space (the buffers which
the FILE* points to, maintained by the c library/stdio library) out to
the OS (device driver).
> So if the write operation has not taken place yet the buffers are now
> going to be flushed, don't you think the OS better hurry up and write
> the data contained in the buffers to the disk?
Flush just means send data out of the buffers to the next lower level.
fclose causes the contents of the stdio buffers be sent to the device
driver buffers. It doesn't do anything about the device driver buffers,
cause it can't see them.
> What you are saying is that the OS knows that the file is going to be
> subsequently and immediately reopened and overwritten and therefore it
> knows that it does not need to and does not flush the buffers.
Erm, no. fclose causes the FILE* buffer to be sent to the OS. The OS
is never asked to flush the buffers. You fclose, then fopen, and the
stuff in the OS buffers is still there from when it was written.
> If it knows so much you would also agree that it must know enough not
> to close the file either. Isn't this consistent with your theory of
> low level OS / hardware operation?
I'm curious, what do you think 'closing a file' is?
> Or are you saying that although it knows it does not need to close the
> file and that all this hanky panky is being done for operation
> optimization that it goes ahead and dose close the file and does not
> flush the buffers, perhaps just to spite me.
Oh, it closes the file alright. Sure enough, the entry in the table of
open files is removed. But, that's all that closing a file consists of.
You seem to think that more is/should be going on.
The dirty pages sit around in memory until the OS is confident that
nothing needs them to be availble soon (or until it has to cause memory
is filling up, or whatever), and then (maybe 30 seconds or more later)
writes them out, since they're not needed.
If (before the dirty pages are written out) the file is opened, and the
file written to, then it's the pages which are written to (they're still
sitting around in memory).
> Don't you think you are about to have a nervous breakdown?
Naaw. I'm cool. But you, on the other hand, need to cut down on
caffiene.
> Well?
>
> Prove to us who the "utter moron" is, again, please.
>
> You can start by explaining to all of us what it means to FLUSH the
> buffers.
Means send the data to the next lower level. When the stdio level
flushes its buffers, it takes the data in it's buffer and uses the file
descriptor to request the device driver write some data. When the
device driver flushes its buffers, it takes the data in its buffers, and
asks the hdd to write some data. When the hdd flushes its buffers, it
takes the data in its buffers, and does some funky magnetic stuff to the
spinning metal thingy.
Fclose flushes the stdio level buffers. Clocks in the OS and the hdd
cause the device driver and hdd buffers to be periodically flushed.
The fsync function also is supposed to flush the device driver buffers.
Note that fclose does not call fsync, AFAIK. Also, as I've mentioned,
many M$ implementations of fsync are flawed, and may even simply be
noop. It is impossible for program level code to determine if fsync is
properly implemented (except /maybe/ by measuring timing). If the
library programer simply has fsync always return 0, noone will ever
know.
When the OS shuts down, the device driver buffers are flushed, and a
request is sent to the hdd for it to flush its buffers.
Note that, when the OS shuts down, QUIT, and the KILL signals are sent
to any still running processes. If QUIT is intercepted, then the
program may call fflush or fclose or whatever, and thus flush it's stdio
buffers. KILL cannot be intercepted. If the program doesn't intercept
QUIT, or ignores it, it's stdio buffers are not flushed, and are simply
lost.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: "-<alexplore>-" <-<alexplore@alexplore>->
Crossposted-To:
alt.support.depression.manic,soc.culture.russian,dk.snak.mudderkastning,alt.drugs.hard,alt.support.anxiety-panic,alt.support.depression,alt.support.depression.manic,alt.support.ocd,alt.support.attn-deficit,alt.support.eating-disord,soc.support.
Subject: How 'bout Borg whore Yelena Perhunkova? She's a Internet Cock Huntress - ask
Igor Chudov {Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER
Date: Sun, 4 Mar 2001 21:29:36 -0500
Reply-To: "-<alexplore>-" <-<alexplore@aleplore>->
Johan M. Olofsson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
Chris... wrote....
<BIG SNIP>
> >
> > NORMAL PEOPLE AGAINST HEADCASES AND PSYCHIATRIC MED JUNKIES
> > LIKE LIKDA GORE THE PROZAC WHORE. EXCEPT DESIPRAMINE OF COURSE
> > I TAKE 200MG/DAY. MY HARD-ONS LAST FOR DAYS
>
> You need a woman.
>
How 'bout Borg whore Yelena Perhunkova? She's a Internet Cock Huntress - ask
Igor Chudov
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Mon, 05 Mar 2001 03:12:22 GMT
On Sun, 04 Mar 2001 16:07:00 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>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.
Might as well do XOR M2 instead of XOR M1. Why use the mask without
the extra layer of encryption the first time?
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Subject: Re: Monty Hall problem (was Re: philosophical question?)
From: Adam Stephanides <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Date: Mon, 05 Mar 2001 03:30:51 GMT
in article [EMAIL PROTECTED],
Fred Galvin at [EMAIL PROTECTED] wrote on 3/4/01 6:32 PM:
> All right. Can you explain the fallacy in my reasoning?
>
> I pick door #1. Without opening any doors, Monty offers me the chance
> to switch to door #2. I don't know what's behind door #3, could be the
> car, could be a goat. However, if the car is behind door #3, then it
> doesn't matter what I do, I'm choosing between two goats. Therefore,
> in deciding what to do, 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?
Let A = "there is a car behind door #1", B = "there is a goat behind door
#3", and C = "Monty opens door #3 and reveals a goat." Now P(A|B) =
(1/3)/(2/3) = 1/2. To calculate P(A|C), on the other hand, observe that
there are four cases:
Case 1a: Car behind #1, Monty opens #2, probability 1/6.
Case 1b: Car behind #1, Monty opens #3, probability 1/6.
Case 2: Car behind #2, probability 1/3.
Case 3: Car behind #3, probability 1/3.
(We are assuming that when there is a car behind #1, Monty is equally likely
to open #2 or #3.)
After Monty opens #3, cases 1a and 3 are eliminated, so P(A|C) =
(1/6)/[(1/6)+(1/3)] = 1/3. Because Monty doesn't always open door #3 when
there is a goat there, P(A|B) != P(A|C).
One way of looking at the difference is that knowing there is a goat behind
door #3 gives you information about whether there is a car behind door #1,
but Monty opening door #3 and revealing a goat doesn't (since he always
shows you a goat, and he has no bias in favor of #2 or #3).
--Adam
------------------------------
Date: 5 Mar 2001 03:30:26 -0000
From: [EMAIL PROTECTED] (Fogbottom)
Subject: Re: The Big Breach (book) available for download
Crossposted-To: alt.security.pgp,alt.security.scramdisk
In article
<ITBo6.14822$[EMAIL PROTECTED]>
"Ridge Cook" <[EMAIL PROTECTED]> wrote:
>
> Thanks Sam-
Me too. I got it last night.
>
> Have heard only faint rumblings in the US, I'll take a look
tonight.
MI6 and your Home Office have done what no amount of advertising
dollars could have accomplished! ;-)
------------------------------
From: [EMAIL PROTECTED] (Steve Meyer)
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Reply-To: [EMAIL PROTECTED]
Date: 5 Mar 2001 04:02:54 GMT
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
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Sun, 04 Mar 2001 23:26:02 -0500
"Douglas A. Gwyn" wrote:
> > Statistical analysis might find some bias or pattern in
> > 2 million bytes of cipher text that would give some
> > additional information about the algorithm.
>
> The algorithm is known. What various features of the
> straw-man-phase-3 scheme are designed to do is to remove
> all exploitable patterns. As I noted, it is not possible
> to cryptanalyze an isolated block no matter what technique
> might be used, because there is no way to distinguish a
> valid key from an invalid one (the correct PT is random).
> That means the only hope for the cryptanalyst is to attack
> multiple blocks simultaneously, but since they use
> different keys (unrelated to each other, if one chooses to
> spend a little more bandwidth than I originally suggested)
> it is hard to see how correlations might be established.
This may be a silly assumption on my part, but if
1. The algorithm is known.
2. All of the cipher text passed has been collected and is known.
3. The initial key is smaller in size than all of the likely plain text
eventually encrypted by this key.
A brute force attack is theoretically possible.
Your scheme has a major advantage if case 2. is not met.
With extra bandwidth case 3. may not be met either.
------------------------------
From: Crypto Neophyte <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Crossposted-To: alt.hacker
Date: Mon, 05 Mar 2001 05:02:28 GMT
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. 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. 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.
HKRIS
------------------------------
** 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
******************************
