Cryptography-Digest Digest #160, Volume #11 Sat, 19 Feb 00 21:13:01 EST
Contents:
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: Does the NSA have ALL Possible PGP keys? ("Trevor Jackson, III")
Re: OAP-L3 Encryption Software - Complete Help Files at web site ("Trevor Jackson,
III")
Re: Question about OTPs (Arthur Dardia)
Re: Q: Division in GF(2^n) (Jerry Coffin)
Re: Is Phi perfect? ([EMAIL PROTECTED])
Re: The TRUTH about STEVEN GUY POLIS - NYC CHILD MOLESTOR (Gregory Andruk Is A
Meower)
Re: Which compression is best? (Michael Wojcik)
Problem solving -- you nee to be better ([EMAIL PROTECTED])
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: decryption (JPeschel)
Re: EOF in cipher??? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
Date: Sat, 19 Feb 2000 16:18:33 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" wrote:
> "Trevor Jackson, III" wrote:
> > However, for production code one cannot rely upon this. It leads to
> > the mistaken assumption that...
> > while ( ( c = getchar() ) > 0 )
> > ... will work. On some compilers this will fail because they do not
> > conform to the standard. I know of two.
>
> That code is wrong anyway, as noted in another recent posting.
>
> However, if a C implementation can't meet even such a simple
> requirement as that of the values returned by getchar, why would
> you use it at all?
Because it often isn't my choice. Someone else, often years before, made
a choice based criteria now long lost.
Case in point from the late 80's. Someone hacked at a RSX-11 C compiler
from who knows where in order to diddle <stdio.h> to handle a prom
burner. I'm tasked to extend the microassembler for upgrades to the
latest and greatest DSP instruction set. They hacker screwed up several
aspect of stream handling during their "improvements". I am probably free
to bitch about the foolishness of the hacker, but I'm not free to switch
to a conforming compiler. I might not even be able to rev the compiler to
standard without breaking code written in it.
If you want to you can call this non-C as another poster did. But when I
wrote narrowly interpreted standard code (in case the customer gained some
engineering sanity) the result was successful.
> This isn't the sort of problem that is
> worth guarding against, because there are an infinite number
> of ways in which implementations could fail to meet clear specs.
Yes. Even conforming compilers have this problem when the specs change.
> In fact, I've never encountered this particular error in any
> serious C implementation, and I've compiled C applications for
> decades on dozens of platforms. (I *have* seen errors in this
> area in *application source code*.) It should be obvious that
> such an implementation error would turn up nearly immediately,
> since it would break the well-known idiom for copying files.
I've seen two flavors of it. Once in the above described RSX-11 system
and another in an instance where a company wanted their own version of
<stdio.h> to diddle. They chose the source from a compiler that was
selling for $19.95 (no I didn't drop a digit) with all sources included.
This decision was motivated by the fact that the project budget would not
support purchasing the source to the tools they normally used.
It was a major software company too. Needless to say I left and haven't
looked back.
------------------------------
Date: Sat, 19 Feb 2000 16:35:20 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
There appears to be an severe sampling error in the examples mentioned. Many
of the self-consciousness effects described can be explain by the simple
four-level competency scale:
1. Unconscious incompetent
2. Conscious incompetent
3. Conscious competent
4. Unconscious competent.
A transition from level one to two produces exactly the (forgive me)
consciousness raising that lowers self-evaluations. Thus choosing only
amateurs, who are presumed to exist at level one, is bound to produce distorted
results.
It would be interesting to include Bob Hope, Jerry Lewis, or Jim Carrey in the
humor tests, or a selection of serious logicians in the reasoning tests (Lem in
particular).
B Poulton wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Steve K) wrote:
> >I just read most of this thread, and it's a very silly thread.
> >
> Agreed. I've been following it because I know little about it. Yet. In
> conjunction with the original post I don't think this article is off topic.
> (Note: This is *not* a slam against Americans. It's just that the study
> groups were primarily American).
>
> Incompetent people rarely know they are
> By Deborah Zabarenko
>
> WASHINGTON, Jan 20 (Reuters) - The truly incompetent may never know the
> depths of their own incompetence, a pair of social psychologists said on
> Thursday.
>
> "We found again and again that people who perform poorly relative to
> their peers tended to think that they did rather well," Justin Kruger,
> co-author of a study on the subject, said in a telephone interview.
>
> Kruger and co-author David Dunning found that when it came to a variety
> of skills -- logical reasoning, grammar, even sense of humor -- people who
> essentially were inept never realized it, while those who had some ability
> were more self-critical.
>
> It had little to do with innate modesty, Kruger said, but rather with a
> central paradox: Incompetents lack the basic skills to evaluate their
> performance realistically. Once they get those skills, they know where they
> stand, even if that is at the bottom.
>
> Americans and Western Europeans especially had an unrealistically sunny
> assessment of their own capabilities, Dunning said by telephone in a
> separate interview, while Japanese and Koreans tended to give a reasonable
> assessment of their performance.
>
> In certain areas, such as athletic performance, that can be easily
> quantified, there is less self-delusion, the researchers said.
>
> IGNORANCE IS BLISS
>
> But even in some cases in which the failure should seem obvious, the
> perpetrator is blithely unaware of the problem. This was especially true
> in the area of logical reasoning, where research subjects -- students at
> Cornell University, where the two researchers were based -- often rated
> themselves highly even when they flubbed all questions in a reasoning test.
>
> Later, when the students were instructed in logical reasoning, they
> scored better on a test but rated themselves lower, having learned what
> constituted competence in this area.
>
> Grammar was another area in which where objective knowledge was helpful
> in determining competence, but the more subjective area of humor posed
> different challenges, the researchers said.
>
> Participants were asked to rate how funny certain jokes were, and
> compare their responses with what an expert panel of comedians thought. On
> average, participants overestimated their sense of humor by about 16
> percentage points.
>
> This might be thought of as the "above-average effect" -- the notion
> that most Americans would rate themselves as above average, a statistical
> impossibility.
>
> The researchers also conducted pilot studies of doctors and gun
> enthusiasts. The doctors overestimated how well they had performed on a
> test of medical diagnoses and the gun fanciers thought they knew more than
> they actually did about gun safety.
>
> So who should be trusted: The person who admits incompetence or the one
> who shows confidence? Neither, according to Dunning. " You can't take them
> at their word. You've got to take a look at performance," Dunning added.
>
> --
>
> bpoulton at vcn.bc.ca (Bob Poulton) Remove the 'trythis.' to reply.
> (for Usenet only) (if I remember to stick it in)
> And Lao-tse said: Those who know don't tell; those who tell don't know.
> --
> x
------------------------------
Date: Sat, 19 Feb 2000 16:36:43 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Anthony Stephen Szopa wrote:
> "Tony L. Svanstrom" wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> >
> > > None of you have convinced anyone of anything and the reason this is
> > > so is simply because none you have made any legitimate claim to support
> > > your strong position that OAP-L3 is "garbage."
> > >
> > > You all offer nothing but excuses.
> > >
> > > There can only be one reason: you cannot do so.
> >
> > No, there could be lots of reasons... One might be that we're too busy
> > making fun of you and your stupid claims...
> >
> > Just look at that stupid Money-Back Guarantee, if I buy your program I
> > have only 180 days to prove that it's useless, and then I'll only get my
> > money back... Meaning that you don't trust your program more than 10
> > bucks worth. That's nice to know, if I lose 10'000+ USD because I
> > trusted your "practicably unbreakable" software I will get 10 USD back
> > (but only if it happens within 180 days after I got the software).
> >
> > /Tony
> > --
> > /\___/\ Who would you like to read your messages today? /\___/\
> > \_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
> > --oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
> > DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
> > ---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
> > \O/ \O/ ©1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
>
> You have no sense of humor.
>
> If you read the theory and operation web pages you would have seen
> that the method is something to be seriously considered.
I did read your explanations. I concluded that the method described should be
dismissed out of hand as a waste of time.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Sat, 19 Feb 2000 16:23:16 -0500
Anthony Stephen Szopa wrote:
> Arthur Dardia wrote:
> >
> > As we all know, many people are becoming interested in one time pads due
> > to their "perfect" security system. Yes, while this system is perfect
> > with totally random data and a "perfectly" secure way to transfer the
> > pad-file, this is rare to come by.
> >
> > Many people attempt to pack CD-ROM's with totally random data; however,
> > then you must tell your recipient which offset to start reading the pad
> > from. So, my question is this: for one message, so that I start at the
> > 30,567,890 byte and the next I start tat the 30,567,889. While this is
> > only one byte off, the ciphertext is totally different; however, how
> > secure is this?
> >
> > (A+K)-(B+K)=A-B
> >
> > While most of the padding is identical, will pushing the offset back one
> > byte still aid cryptanalysts in cracking the message? I plan on writing
> > an OTP program in Python, which will take the path to the pad-file, the
> > starting offset, plaintext path, and ciphertext path and perform all of
> > this for you. Why Python? I don't know. Never used it before, I
> > figure that this will be a rather simple thing to do, yet remain
> > portable. I'm going to use the Windows toolkit so I can build a
> > stand-alone Windows executable; however, the heart of my program will be
> > extremely portable to other systems. Any suggestions on the program and
> > the security of the above problem?
> >
> > --
> > Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
> > PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
>
> Computer implemented OTP encryption is available at
> http://www.ciphile.com
>
> If you want to use your own true random numbers instead of the
> random number files generated by the software, basically all you
> have to do is organize the OTP files using the necessary file
> format which only requires:
>
> a naming convention such as, F0000001, F0000002, F0000003, etc.
> for each consecutive OTP file;
>
> and each file must be the same length.
>
> The software will keep track of which OTP file you are currently
> using and where to offset it. When the file has been used once
> completely it is overwritten and deleted. Then the next file is
> used. If this file is not used up completely a pointer file is
> created that records the offset so the next time you encrypt a
> message it will begin using the OTP where you just left off. Etc.
While everyone else is arguing stuff I don't understand, you answered my
question. I guess it's useless for me to bother writing my own. Thanks.
But now, let's raise the question on the best way to obtain great random
data? I still say make a recording of what happens outside the window by your
computer and mix that with your swap file (which should be really, really
random - unless I'm mistaken), in addition to recording timings between
keypresses, etc. Does it make sense that the more stupid stuff you include,
the more random your data will become, or do you think that the more stuff you
include, the bigger chance that you'd make a mistake and would introduce a
pattern for an attacker. For instance, say you mistakenly use the GPL as part
of your random data. Such a widely available document is not what we'd call
"random." Even though all of your other data is mixed with this, would that
create a hole?
Also, when combining multiple sources of data, should you conectate the two
files or data, or should you xor them together or perform some other operation
on them. Xoring the two would yield as much data as the bigger file holds,
but conectating the two files would give you more data. Which is better,
assuming you don't really need that much data...
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Sat, 19 Feb 2000 14:46:09 -0700
In article <6iCr4.7260$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Cite, please?
I don't have a citation. In fact, now that I think about it, I'm not
at all sure I should have said that publicly at all... :-<
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is Phi perfect?
Date: 19 Feb 2000 18:12:26 -0500
Frank the_root <[EMAIL PROTECTED]> wrote:
> I always thought that the Euler's Phi fonction ( Phi(n) ) was the
> fonction that gives the number of numbers relatively prime to n and
> smaller than n
Yes.
> the multiplication of each primes factors of n reduced
> by one.
No.
If n=p^a*q^b*r^c .... (p,q,r distinct primes: a,b,c non-negative
integers):
n=(p-1)*p^(a-1)*(q-1)*q^(b-1)*(r-1)*r^(c-1)...
(if there are no repeated prime factors, i.e. a=1,b=1,c=1,etc. *THEN* this
*happens* to come out equal to (p-1)(q-1)(r-1)...)
Another way to write this is n*(1-1/p)(1-1/q)(1-1/r)...
------------------------------
Crossposted-To:
news.admin.net-abuse.usenet,comp.security.firewalls,alt.music.pearl-jam,alt.fan.karl-malden.nose
From: Gregory Andruk Is A Meower <[EMAIL PROTECTED]>
Subject: Re: The TRUTH about STEVEN GUY POLIS - NYC CHILD MOLESTOR
Date: Sat, 19 Feb 2000 23:46:36 GMT
In article <88n2mi$1l8$[EMAIL PROTECTED]>, Steven Guy Polis projected:
>
>In news.admin.net-abuse.usenet [EMAIL PROTECTED] wrote:
># > (First posted by Nancy Baldacci in 1999)
>[snip]
>
>Didn't anyone save his picture from when it
>was on the NC site for sex offenders?
When is your picture coming off of the NY CHILD MOLESTOR
website?
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Which compression is best?
Date: 19 Feb 2000 23:29:01 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> writes:
> [Knips' basic claim: it's easy to distinguish valid compressed data
> invalid, for any compressor]
Tim Tyler has already made the more telling argument - that there are
compressors which have no invalid cases for input to the
decompressor.
The heated discussion of "1-1 compression" and "bijective
compressors" a little while back on sci.crypt notwithstanding, it
should be obvious to practitioners in the field that a compressor
that accepts any input for decompression is easy to construct. One
simply adds states to the decompressor's machine until there are no
stop states except for end-of-input transitions, even if those states
don't enhance the compression function. If necessary, output of the
compressor can be whitened to include some transitions to those
states, so those transitions will not in themselves flag bogus
input.
> Well okay, I in fact didn't tried this in practice. For example, I know
> that Huffman has to first dump the huffman tree, and then the huffman
> codes follow.
That's a typical protocol for the application of Huffman's compressor,
but it is by no means a rule. If the length of output can otherwise
be determined, for example, the tree could be dumped after the
compressed data. Or the tree could be fixed - a fine alternative if
the domain is limited (always English text, for example) - and never
transmitted at all. Or the package transformation, or something like
it, could be used to scatter pieces of the tree among pieces of the
compressed text. None of these are difficult techniques.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
See who I'm! -- Jackie Chan and unknown subtitler, _Dragons Forever_
------------------------------
From: [EMAIL PROTECTED]
Subject: Problem solving -- you nee to be better
Date: Sat, 19 Feb 2000 19:33:45 -0500
Reply-To: [EMAIL PROTECTED]
Join the hundreds of people who are enhancing their innovation skills every week.
Submit and read examples of each principle to see how other have experienced or
applied the previous week's principle.
Innovation skill building by reading and applying a new Inventive Principle each week.
Receive a free Inventive Principle each and every week. Reply by clicking on the
reply to e-mail address and type "Sign me up" in the Subject box.
Dana Clarke
Director of Education
Ideation International Inc.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Sun, 20 Feb 2000 01:29:19 GMT
Mok-Kong Shen wrote:
> ... Remembering that previously it has been the firm and resolute
> opinions of a number of authorities (in more than one country)
> that strong cryptos should be under strict control (particularly
> the issue of export) and that (if I don't err) the crypto clauses
> of the Wassenaar Agreement are still 'in force', this 'exception'
> IS indeed remarkable.
How so? The US is not bound by the Wassenaar Agreement, because
our Constitution requires that all foreign treaties be ratified
by our Senate, which did not happen for the W.A. (thankfully).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sun, 20 Feb 2000 01:33:39 GMT
"Trevor Jackson, III" wrote:
> "Douglas A. Gwyn" wrote:
> > John Myre wrote:
> > > (I suppose the whole thing would fail if "int" were 8 bits,
> > > but please - has there *ever* been such an implementation?)
> > The only interesting implementations are the ones that conform
> > to language standards.
> Aha. The true cause of the dispute is revealed! "An amateur does it
> for love, a professional does it for money".
> IMHO the only interesting implementations are those that I am paid to
> use. Were I to wait for a completely conforming implementation I would
> never be able to accept a contract because there aren't any.
Money has nothing to do with it. The original question concerned
use of the C programming language. The C programming language is
defined by a certain standards document. If you want to talk
about some completely inadequate implementation of a vaguely
C-like language, that has nothing to do with C programming, and
it certainly does not address the original question, which was
answered adequately by those of us who *were* talking about C.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sun, 20 Feb 2000 01:36:37 GMT
JPeschel wrote:
> Mok, if you are trying to learn C, I'd suggest you value
> Doug's technical opinions over the opinions and coding
> styles of others here, including myself.
Thanks, although I was careful to use "K&R" coding style
rather than my own, on the principle that that is the one
coding style that every C programmer has to be comfortable
with. In my own style, I use more white space, place the
braces differently, and comment the variables more thoroughly.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sun, 20 Feb 2000 01:40:40 GMT
"Albert P. Belle Isle" wrote:
> /* I'm pretty sure you intended this */
> if ((ofp = fopen(argv[2], "wb")) == NULL) {
Yes; I typed it in directly on a system lacking a C compiler to
check it for typos. Thanks for catching that one.
> fclose(ifp);
> fclose(ifp);
> fclose(ofp);
> fclose(ifp);
> fclose(ofp);
> fclose(ifp);
> fclose(ofp);
> Since everyone and his brother has felt compelled (compiled?<g>) to
> add something to your (obviously knowledgable) postings, I'll pick a
> nit by mentioning the apparent absence of a few fclose() statements in
> order to actually be able to produce a copied file on disk and not
> leave the files in a potentially hazardous condition (at least on
> Wintel platforms, where you might also reconsider being explicit about
> "register" if using any good optimizing compiler - though I guess bad
> ones are part of the discussion).
No, none of those fclose invocations are necessary. Return from
main invokes all the exit actions, which include flushing and
closing all the open streams.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: decryption
Date: 20 Feb 2000 01:43:51 GMT
Jim Gillogly [EMAIL PROTECTED] writes:
>Right. If you do an IC on it the period will pop right out, and
>the encryption system will be the first polyalphabetic you think of.
>Dead simple, but take my word for it: the ad you get isn't worth it.
Might be if you want a primer on online databases.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sun, 20 Feb 2000 01:53:17 GMT
Jerry Coffin wrote:
> If you're going to pick nits, you should probably check the return
> value from fclose (at least on the output file) and only return
> success if you can close it correctly -- in some cases, output buffers
> aren't flushed until you close the file, and if you run out of disk
> space, all the writes can seem to succeed, but closing the file
> fails...
Yes, while none of the fclose invocations were necessary, if one
is trying to catch and report all possible failure modes (a good
thing in production code), then one should invoke fclose for ofp
right before the EXIT_SUCCESS return, testing for success and
reporting failure as you suggest. ifp is already at EOF without
error. I'll accept that as a friendly amendment:
...
if (fclose(ofp) != 0) {
fprintf(stderr, "copyfile: error closing %s\n",
argv[2]);
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
Note: I chose to report only the first error (in all cases).
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
