Cryptography-Digest Digest #175, Volume #11 Mon, 21 Feb 00 13:13:02 EST
Contents:
Re: ISIT2000 -crypto (Mark Lomas)
Re: In the diaries of Markku J. Saarelainen, the Caspian Oil is one of the most
interesting topics .. (Robert Harley)
Re: Keys & Passwords. (Runu Knips)
Re: EOF in cipher??? (wtshaw)
Re: NSA Linux and the GPL (wtshaw)
Re: UK publishes 'impossible' decryption law (Richard Herring)
Re: NSA Linux and the GPL (Paul Koning)
Re: NIST publishes AES source code on web (Paul Koning)
Re: NIST publishes AES source code on web (wtshaw)
Re: Keys & Passwords. (wtshaw)
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: NTRU Speed Claims (100x faster, etc.), explained (Mike Rosing)
Re: I will bring PGP to the masses h15 (wtshaw)
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: NSA Linux and the GPL ([EMAIL PROTECTED])
Re: EOF in cipher??? ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: Mark Lomas <[EMAIL PROTECTED]>
Subject: Re: ISIT2000 -crypto
Date: Mon, 21 Feb 2000 16:09:49 +0000
Reply-To: [EMAIL PROTECTED]
Further information on this symposium may be found at
http://www.dia.unisa.it/isit2000/
Mark
In message <[EMAIL PROTECTED]> of newsgroup sci.crypt, Jacques
Quisquater wrote:
>
> Cryptography I
>
> A Simple and Efficiently Verifiable Characterization of the
> Possibility of
> Information-Theoretic Key Agreement Secure Against Active
> Adversaries (310)
> Stefan Wolf
>
> The Strong Secrecy Capacity and its Equality to the
> Wyner-Csiszar-Körner Secrecy
> Capacity (308)
> Ueli Maurer, Stefan Wolf
>
> Information-Theoretic Analysis of Information Hiding (669)
> Pierre Moulin, Joseph A. O'Sullivan
>
> Information-Theoretically Secure Keyless Authentication (61)
> Valeri Korjik, Maxim Bakin
>
>
> Cryptography II : Watermarking
>
> Identification in the Presence of Side Information with Application
> to Watermarking (352)
> Neri Merhav, Yossef Steinberg
>
> Quantization Index Modulation: A Class of Probably Good Methods for
> Digital
> Watermarking and Information Embedding (460)
> Brian Chen, Gregory W. Wornell
>
> Relationship between Quantization and Distribution Rates of
> Digitally Watermarked Data
> (190)
> Adrian Papamarcou, Damianos Karakos
>
> On the Gaussian Watermarking Game (211)
> Amos Lapidoth, Aaron Cohen
>
>
> Cryptography III
>
> The simple ideal cipher system (112)
> Boris Ryabko
>
> Better than "Optimum" Homophonic Substitution (558)
> Valdemar C. da Rocha Jr., James L. Massey
>
> Watermark Codes: Reliable Communication over Insertion/Deletion
> Channels (245)
> Matthew C. Davey, David J.C. MacKay
>
> A Calculus of Conditional Independence and ist Applications in
> Cryptography (637)
> Ueli Maurer
>
>
> Cryptography IV
>
> Global Broadcast by Broadcasts Among Subsets of Players (636)
> Matthias Fitzi, Ueli Maurer
>
> Performance of a Secure Wireless Transmission Method (551)
> Havish Koorapaty, Amer Hassan
>
> A New Identity-based Conference Key Distribution Scheme (91)
> Sheng-bo Xu, Henk van Tilborg
>
> An Information Theoretic Model for Distributed Key Distribution
> (171)
> Carlo Blundo, Paolo D'Arco
>
>
> Cryptography V
>
> Traitor Traceable Signature Scheme (278)
> Yyuji Watanabe, Hideki Imai
>
> An Efficient Traitor Tracing Scheme for Broadcast Encryption (289)
> Maki Yoshida, Toru Fujiwara
>
> Inherently Large Traceability of Broadcast Encryption Scheme (634)
> Kaoru Kurosawa, Takuya Yoshida, Yvo Desmedt
>
> Reducing String Oblivious Transfer to Universal Oblivious Transfer
> (311)
> Stefan Wolf
>
>
> Cryptography and Coding I
>
> Fourier Spectrum of Optimal Boolean Functions via Kasami's
> Identities (223)
> Pascale Charpin, Anne Canteaut, Claude Carlet, Caroline Fontaine
>
> A Construction of Resilient Functions with High Nonlinearity (259)
> Enes Pasalic, Thomas Johansson
>
> On the Structure and Numbers of Higher Order Correlation-Immune
> Functions (58)
> Yuriy Tarannikov
>
> Large Weight Patterns Decoding in Goppa Codes and Application to
> Cryptography (221)
> Pierre Loidreau
>
>
> Cryptography and Coding II
>
> Theoretical Analysis of a Correlation Attack based on Convolutional
> Codes (256)
> Frederik Jönsson, Thomas Johansson
>
> Compared Performance of Fast Correlation Attacks on Stream Ciphers
> (222)
> Anne Canteaut, Michael Trabbia
>
> Novel Fast Correlation Attacks via Iterative Decoding of Punctured
> Simplex Code (690)
> Miodrag J. Mihaljevic, Marc P.C. Fossorier, Hideki Imai
>
> Using Low Density Parity Check Codes in the McEliece Cryptosystem
> (567)
> Chris Monico, Joachim Rosenthal, Amin Shokrollahi
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.europe,soc.culture.venezuelan,soc.culture.israel,alt.2600,soc.culture.nordic,soc.culture.china
Subject: Re: In the diaries of Markku J. Saarelainen, the Caspian Oil is one of the
most interesting topics ..
Date: 21 Feb 2000 17:14:53 +0100
"William A. Nelson" <[EMAIL PROTECTED]> writes:
> When I stole the diaries of Markku J. Saarelainen, I knew that he had
> some considerable knowledge of certain aspects of the Caspian Oil and
> Caucasus. In his diaries, he wrote [...]
Rockin' Echelon bait, dude!
Keep up the good work,
Rob.
------------------------------
Date: Mon, 21 Feb 2000 17:30:56 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
John wrote:
> This may be a stupid question. Let's assume, for the sake of
> argument, we have found a good encrypter. How important is the
> choice of a password? I have often heard that if you had a
> password like athxa or bthxb, it is not good because there is
> repitition.
Well, if you want to use a bad password anyway, then just
"encrypt" the following way:
#define rotl(n, x) (((n) << ((x)&31)) | ((n) >> (32-((x)&31))))
void encrypt (const char passwd[], size_t pwlen,
char buf[], size_t bflen)
{
size_t i, j;
char cbc;
if (pwlen == 0) {
passwd = " ";
pwlen = 1;
}
cbc = 0x3D; j = 0;
for (i = 0; i != len; ++i) {
cbc ^= buf[i];
cbc ^= rotl (passwd[j], i & 7);
buf[i] = cbc;
++j;
if (j >= pwlen) j = 0;
}
}
void decrypt (const char passwd[], size_t pwlen,
char buf[], size_t bflen)
{
size_t i, j;
char cbc;
if (pwlen == 0) {
passwd = " ";
pwlen = 1;
}
cbc = 0x3D; j = 0;
for (i = 0; i != len; ++i) {
char tmp = buf[i];
buf[i] ^= rotl (passwd[j], i & 7);
buf[i] ^= cbc;
cbc = tmp;
}
}
No, sorry, I just was in the mood for a joke ;-)
Please don't be angry !! Hey ! DONT! NO!!!
OUUUUUUCH !!!!!!!!!!!!!!! ;-)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: EOF in cipher???
Date: Mon, 21 Feb 2000 10:04:08 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>... Yes, I can
> also consult the C standard and the good books of C to boast up
> my knowledge, but then I wouldn't need to read this thread at all.
> In fact, I am in possession of a C++ book containing code for I/O
> of binary stuffs. That should work, though I haven't yet tried it.
> But I also like to know what one should properly do for the same in C.
>
In explaining means of doing things, it is sometimes most difficult to
predict all the places where the novice will get hung up. One or several
books on C or C++ may fail to clearly examine the circumstance.
If you are examining crypto code, special sitations unknown to you may
escape your notice, as code can be written in so many ways, and can be
quite cryptic in themselves.
One must keep at it when befuddled, looking at even several books and
asking questions. "It's in the book," may fail to anwer the immediate
concern, and it might not be, not clearly, or one of the details actually
missed. Each day I learn more about C/C++, things assumed that were
wrong, and things obscure that must be found.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA Linux and the GPL
Date: Mon, 21 Feb 2000 10:07:33 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> John Savard wrote:
> > Doubtless, one could add a sort of MLS to Linux with a few changes to
> > the kernel ...
>
> No, sorry. You don't get a secure system by tweaking an insecure one.
Making a waterbag out of a large-sieved fishnet is a difficult if not
hopeless stategy.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: 21 Feb 2000 17:00:22 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Tim Tyler ([EMAIL PROTECTED]) wrote:
> In sci.crypt Jim <[EMAIL PROTECTED]> wrote:
> :>BTW France was very restricted, until a short while ago, when the whole law
> :>was reversed, so that now France is much freer than the UK.
> : How do you mean? There are no restrictions on the use of crypto in
> : the UK.
> Read the thread.
> If you use crypto in the UK - and lose your key, the current bill will
> make this a criminal act, if the government asks you to decrypt.
Future tense, and two explicit conditionals. Also a third implicit
one "if the bill becomes law in its current form".
Not exactly a restriction.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Mon, 21 Feb 2000 11:46:58 -0500
"Douglas A. Gwyn" wrote:
>
> John Savard wrote:
> > Doubtless, one could add a sort of MLS to Linux with a few changes to
> > the kernel ...
>
> No, sorry. You don't get a secure system by tweaking an insecure one.
Ok, so I guess you don't get a secure system at all, if you can't
start from an insecure one, because I don't think there are any
that just spring into existence by magic.
Echoing what Vernon said, I remember watching DEC sink dozens of
manyears into building a B1 grade VMS. I don't think they ever
went back to certify the microcode, though, leaving open nice
opportunies for Trojan Microhorses (trojan ponies? :-) )
Come to think of it, it might be possible to build a B1 grade
secure system, provided it does very little and definitely doesn't
do networking. Certainly it would have to be far more limited
than DOS. Perhaps a good place to start would be to review
the famous paper on the THE system... which was about the right
size, too.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 11:55:38 -0500
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:...
> > Cf. the history (in the sixties, if I remember correctly)
> > that crypto publications should be suppressed or (as is later
> > implemented) the manuscripts are subject to voluntary presentation
> > by the journal editors to the authorities for prior 'review'.
>
> I think you refer to *one* incident where an NSA employee on
> his own initiative contacted symposium attendees about vetting
> their presentations.
The claim of "on his own initiative" has certainly been made
before; I wonder how many people find it convincing.
> ... As one result of the flap that occurred, several
> publishers agreed to voluntarily submit potentially dangerous
> articles for Agency review, but would not be bound to abide by
> the Agency recommendations. There was precedent for this, for
> example, David Kahn's "The Codebreakers" was published minus a
> couple of items that could have adversely impacted on national
> security.
Not the same thing at all. Kahn really did (apparently) do
that as a voluntary act. On the other hand, the prior review
system proposed in the 70s was NOT intended to be honestly
voluntary. At least it was not designed to appear that way
to me at the time, and I did spend some time looking at it.
That's one reason why I will never trust anything written
by Dorothy Denning...
paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 10:21:24 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> Note that the US Congress had immediately prior to that told the
> US Executive branch that such controls, especially key escrow
> provisions, were not the will of the People of the US. But
> this Administration has the longstanding habit of all Liberal
> Democrats of believing that it knows what is best for others and
> will keep trying to get its way regardless of the absence of a
> mandate to do so.
Assuming you know what is best for others is descriptive of many groups.
Abusing that assumption is destined for any group that believes they are
superior, including the right wing nuts as well as the left wing nuts, be
they harder to find but still there.
>
> ...Perhaps there is a feeling among the decision makers that
> the ploy of removing more and more freedom in the name of "law
> enforcement" is not fooling so many citizens these days.
Beyond feeling superior, finding real and publishable reasons for
justifying actions which are based on that feeling is another story.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Keys & Passwords.
Date: Mon, 21 Feb 2000 10:38:48 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> If I use a hashing program to hash a long parsepharse (that
> presumably has more than 8*256 bits of entropy) and get an
> appropriate sequence of hexs, how should I 'optimally' turn that hex
> sequence to the 8 characters that I am going to type in.
You must lose something because of the mathematics involved. Absolute
numbers of possibilities from 8 characters is 94^8 to be compared with
256^8 possibilities of your binary input. This is not allowing for some
information to be absorbed by the hashing process you want.
>.... Suppose I want to limit the input characters to the set
> {A-Z, a-z, 0-9), consisting of 62 allowable characters, what should
> I 'best' do to the hex sequence obtained from my hashing program
> for the purpose? (If mapping, how is that mapping to be done?)
Hashing from 62 to 64 character sets is doable. If you need hex, since
each character of base 64 is six bits, and one in base 16 is four, 2
characters in base 64 = 12 bits = 3 characters in base 16, hex.
> I must admit that I don't yet quite understand the last part of
> your paragraph above. If I map each hex to one character of my set
> (an obvious choice is the 'identiy' mapping), then I'll get
> only 8*4 bits of entropy in my password, don't I? Thanks for
> your help in advance.
>
Mapping is not practical that does not include cross base calcutations,
unless you are going to allow the tremendous loss of information involved;
really the same thing, it makes little sense to encrypt text is ascii
where a lesser and more efficient base can be used.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: misc.survivalism,comp.security.pgp.discuss
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Mon, 21 Feb 2000 12:41:05 +0000
On Mon, 21 Feb 2000 08:46:49 -0700, Bobo <[EMAIL PROTECTED]> wrote:
>Well, I would postulate that an infinite being can have direct knowledge of an
>infinite amount of numbers. An infinite being with infinite knowledge knows
>Pi to all of it's decimal places, for instance. An infinite being could
>probably divide by zero with no problems whatsoever. :-)
I never claimed otherwise, what I claimed was unknowable was the last
digit of pi or the biggest number. Neither of which exist to know.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: Mon, 21 Feb 2000 11:51:25 -0600
Dr. Yongge Wang wrote:
>
> I think the 3:4=plain:cipher is obtained by re-using some randomness
> (I donot have the paper at hand and do not want to bother to check it,
> but if you are really interested in it, you may find it in their
> ANTS paper--can be downloaded from www.ntru.com)
>
> Roughly I remember that after the first encryption,
> the second message is encrypted with some info from the
> first ciphertext...or...i forget the details and canot
> get this 3:4 now
That sounds familiar. I think John is right for an individual
key/message.
You do get a lot of expansion if you reset all the data each time, but
that
isn't necessary for lots of keys.
For bandwidth limited applications I don't think NTRU is a good fit. It
has
lots of other uses tho, and the math is pretty interesting.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: I will bring PGP to the masses h15
Date: Mon, 21 Feb 2000 10:46:15 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> PGP_for_ALL wrote:
> > I will bring PGP to the masses
>
> The only way the typical PC user is going to use PGP is for it to
> be the *default* mode of his e-mail interface *as bundled* with his
> computer or ISP package when he purchases it.
Or, have AOL add it to their package, a kinda remote possibility, don't
you think?
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
Date: Mon, 21 Feb 2000 13:03:36 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
"Douglas A. Gwyn" wrote:
> "Trevor Jackson, III" wrote:
> > So, you are now the final arbiter of "interesting"?
>
> No, but I do have an interest in the dissemination of
> accurate information about C.
>
> > Get stuffed.
>
> So that's your response to being wrong?
Using the term "you" is a flag that typically indicates an ignition
source or an actual flame because the discussion is getting personal
rather than substantive. Since this is the third or fourth ply
containing the term, I'm going to assume this is no longer an issue of
meritorious concepts, but one of purely personal animosity. I.e., a
flame war.
Readers interested in topics relevant to sci.crypt are invited to stop
reading here.
My suggestion was not a response to being wrong. It was a response to
pedantic stupidity. Yours.
Being pedantic is no vice. It is often a virtue. Being stupid is also
not a vice. All humans experience brain fade occasionally. So the
proper thing to do on recognizing it is to note it without rancor, and
move on.
However, there is no excuse for the combination. Pedantic stupidity is
intolerable in the science and engineering. It is often a cover for
insecurity. It often manifest, as you have manifested it, as false
authority, exercised for its own sake. Your quote regarding
"interesting" was telling. It indicated that you were uninterested in,
and perhaps may not even have understood, the issue under discussion.
You have _insisted_ that the original issue was one of language
standards. It wasn't then, and it isn't now. The issue is good
engineering practice.
Note that _both_ topics were appropriate responses to the original
query. But _neither_ topic should dominate the other. Both topics are
relevant and important.
You appear to have a significant amount of expertise regarding the
standards of the C language, and a serious lack of engineering talent
about using the language. Since I was making points relevant to good
engineering practice your objections do not affect the relevance of my
comments (complete), or the importance of my comments (medium strong).
All you have managed to achieve is a demonstration of your knowledge of
the C standards (medium relevance) and your ignorance of good
engineering principles (strong relevance).
Your suggestion that my statements were "wrong" is silly. My statements
were correct in context. When you change the context to one where the
only criteria of interest is conformance with standards, naturally, the
interpretation of my statements changes along with it. If you fail to
understand my comments in their original context, perhaps because I did
not make the context clear enough for you, then the proper thing for you
to do is ask for clarification. Several other posters, including some
opposed to my original statements, appeared to understand the
distinction between language standards and engineering principles. Thus
my statements couldn't have been _that_ obtuse.
If it makes you happy to think that I was wrong, do so. There is
nothing contradictory about being pedantically stupid and winning minor
"points". In fact the two traits often go hand in hand.
I retract the suggestion that you get stuffed. It was both rude and
unnecessary. You are already stuffy enough.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NSA Linux and the GPL
Date: 21 Feb 2000 17:55:51 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> 1. As far as I can tell, Linux is doing a much better job of being a
>> viable desktop alternative. I don't see many desktop applications
>> being ported to a xBSD.
...
> There is usually a platform-specific "ABI" to specify such details
> for each platform, so for example all Intel x86 applications running
> on some flavor of UNIX should conform to the ABI in order to work on
> all platforms of that type. Last I heard, Linux did not support the
> x86 UNIX ABI. Some other UNIX variants for x86 now have Linux
> emulation layers, so that binaries built for Linux stand a good
> chance of being usable anyway.
Personally, I think a system-independent ABI for all x86/unix
applications is a nice, but misguided (or impractical) idea. There
are simply too many issues for such a thing to work reasonably. There
are certainly some reasonable approximations: most (all?) x86/unix
variants support ELF binaries, and many support system-emulation
environments by providing appropriate translation libraries and that
sort of thing. As two examples, FreeBSD can run Linux binaries, and
Linux can run Solaris binaries. However, both emulation layers have
some problems, so it's not perfect. I think that such problems will
always be there. Theoretically you can get rid of them, but
practically doing this reliably is an entirely different matter.
At the source level, Linux is certainly about as close to POSIX
compliance as any OS (in fact, it was designed from the ground up
precisely to be a POSIX OS, unlike others which have added that on top
of previous work).
> For example, I have Solaris 7 (also Plan 9 and Windows 98/NT) on my
> home Pentium, also at work on SPARC processors, and other machines at
> work have other versions of UNIX on MIPS processors. Most of the
> software I develop has to work on DSPs and oddball microprocessors as
> well as on that variety of host systems. It would be insane to think
> of Linux as a particularly attractive target under the circumstances.
I'm not sure why you'd say that.... Linux will certainly run on all
those platforms (x86, SPARC, MIPS). In fact, I can't think of any
other single OS (except perhaps some of the *BSDs?) that will run on
all 3 of those. Are you saying that you need commercial development
tools to cross-compile for DSPs or something like that? Applications
that are only available for certain OSes might be a strong reason to
go with a particular OS, but it's not a particularly compelling
argument on a more abstract level -- as soon as the application is
available for the other OS, the argument vanishes. In particular,
it's not a technical argument against the OS, but rather a practical
one about application availability (which is, of course, a very good
practical argument).
>> I personally have never used a xBSD, but from what I've read they
>> are very mature and perform exceptionally well. I am planning on
>> trying out at least one of them sometime in the future mainly
>> because I heard that they have excellent TCP/IP stacks.
> Nearly everybody uses BSD-based implementations of the IP protocol
> suite. (Unfortunately, these have had many security problems, but
> that is another issue.) Even Microsoft "WinSock" is modeled after
> the BSD interface. BSD UNIX itself is no longer under active
> development.
BSD variants ("xBSD" as the quoted poster said) are certainly under
active development. FreeBSD, NetBSD, and OpenBSD are certainly all
being worked on. Do you not consider those "BSD UNIX" because they're
not being done at Berkeley?
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
Date: Mon, 21 Feb 2000 13:08:53 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Mok-Kong Shen wrote:
> JPeschel wrote:
> >
> > >Mok-Kong Shen [EMAIL PROTECTED] writes:
> >
> > >In a situation where everyone says his opinions are right and
> > >those of the others are not, it is pretty hard for a non-expert
> > >to sort out the correct code postings, I am afraid.
> >
> > 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.
>
> This issue has a remarkable connection to a recent thread concerning
> trust. Since I know nobody of this group personally, if person
> A says I should trust him and person B says I should trust him (B)
> instead, how should I decide? What would you personally do in
> such a situation? A non-expert has to wait till the heated dispute of
> the diverse experts settles before being able to know the truth,
> doesn't he?
You can do that but it produces a democratic version of the Aristotelian
Fallacy if the dispute terminates, and an unending wait if it does not.
I would suggest two standards of evaluation for disputes among experts.
First, do the suggestions make sense when evaluated against your own
experience. Second, if you do not trust your own opinion or experience
base, improve it. Gather evidence (not opinions). Experiment. Try out
the suggestions and see if you are satisfied with the results.
------------------------------
** 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
******************************
