Cryptography-Digest Digest #561, Volume #10 Fri, 12 Nov 99 23:13:03 EST
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: Ultimate Crypto Protection?
Re: Ultimate Crypto Protection?
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: Proposal: Inexpensive Method of "True Random Data" Generation
Re: Ultimate Crypto Protection?
Re: Proposal: Inexpensive Method of "True Random Data" Generation
([EMAIL PROTECTED])
Some basic facts - internet and crypto ("Markku J. Saarelainen")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sat, 13 Nov 1999 01:30:02 GMT
On Fri, 12 Nov 1999 02:48:38 GMT, in <80fv65$rvt$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>Terry Ritter wrote:
>> [EMAIL PROTECTED] wrote:
>[...]
>> In my proposals, it is has been, and still is, unnecessary to
>> authenticate the cipher choice. No authentication mistake is possible
>> with respect to cipher choice. The ciphers themselves must be
>> authentic, but that is not a cipher-change protocol issue.
>
>I'm not sure what you mean. The adversary may modify the
>messages that influence the choice of cipher. It is the
>authenticity of these messages that is at issue, and the
>handling of these messages constitutes the cipher selection
>protocol. I'll show below why authentication is necessary.
There is something seriously wrong with a cipher system which allows
messages to be substituted by anyone who happens to have a non-secret
public key. This is an issue in public-key cryptography which is not
normally present in secret-key cryptography.
In secret-key cryptography, if more than two users share a key, it is
quite clear that multiple source options exist for any message which
is sent. This is clear. The issue of deception, then, is due to
public-key cryptography, and so must be (and generally will be)
handled in any system which uses that technology.
Having a system where anyone can masquerade as anyone else is simply
insane. Or perhaps you are assuming that the issue *cannot* be
handled in public-key cryptography, which would be an interesting
result.
This is not an issue for the cipher-change protocol. It *is* an issue
which must be considered in every public-key design.
>[...]
>So you've described the protocol: "In my proposal, one
>end sends a list; the other selects from that list".
>You've been clear that when a side sends the list,
>such communication is and under a cipher. Now I'll
>describe the attack on a system entirely consistent
>with your description.
>
>Suppose all parties are given an authentic certificate
>for Bob's public key. Alice sends her list of ciphers
>to Bob, encrypted under Bob's public key. Fred blocks
>the message from Alice and substitutes his own list
>consisting of one cipher he knows to be on Bob's list.
>Bob, as the description specifies, selects a cipher
>from the list.
>
>So just as you described, the negotiation is protected
>by a cipher.
While you claim to have assumed that the negotiation is "protected,"
in reality you have not made any such assumption. Any cipher system
which allows anyone at all to pretend they are the other party to a
particular communication is inherently insecure. The cipher change
protocol is hardly the issue.
>Just as you wrote "In my proposal, one
>end sends a list; the other selects from that list".
>Thus Fred has achieved the chosen cipher attack, within
>the protocol you described. As you noted, we have to
>assume the initial cipher is effective; ciphers provide
>privacy and the example above grants that the cipher
>is effective.
The initial ciphering system was, by your description, remarkably
ineffective. That seems to be an issue for the cipher system design,
rather than any particular cipher, or any plaintext protocol under the
cipher. Again, that issue does not come up when we have a single pair
of nodes operating under secret key. The issue for public-key
cryptography, then, is to provide a protocol which does provide
security. And when that is provided, the cipher-change protocol I
proposed will be fine, perhaps with some additional protection, which,
as you have previously noted, was suggested by "others."
>> You seem to have several big problems here, the first being the
>> possibility that I missed something, and so deserve your castigation.
>
>More like: you missed something and so should recognize
>it now and fix it.
No, you found something which is probably well-known in public-key
design, and have attempted to use it to fault a level at which it does
not apply.
>> Well, I did *not* miss what you think I did, but even if I had, who
>> elected you God? If you had found a factual problem, you could
>> present that. Instead, you cop an attitude and distort reality, both
>> of which are way out of line.
>
>I introduced the issue simply as a matter of fact.
>Over and over you refused to see it, and acted like
>I and others didn't know what we were talking about.
Small wonder.
>> >> Whatever
>> >> cipher system has been established will authenticate
>> >> received messages
>> >> in some way (often with a hash of the plaintext),
>> >> and thus will detect
>> >> "any" attempt by an attacker to "modify the messages."
>> >
>> >Now you're starting to get it. This authentication
>> >was completely missing from your suggestion before
>> >others pointed out the problem.
>>
>> There was and is no problem, and what was pointed out was wrong. If
>> the public-key certification or message authentication is bad, the
>> original security is bad, and there is no protection for the raw
>> plaintext that we are trying to protect, so cipher-change negotiation
>> is the least of the problems.
>
>As I asked before - if you had message authentication on
>the negotiation, please just cite it.
Message authentication is *not* -- and should not be -- part of the
cipher-change protocol, but I would assume that there would be
error-detection, at least, for the delivered message (including hidden
protocol messages). That allows us to detect any change in transit.
But that is not your issue. Your issue is that someone may send a
message which appears to be from our far end, but is not.
Unfortunately, if that issue is not resolved at a higher level, it
probably will not be resolved by particular plaintexts, except perhaps
when we can say, "remember what we did after that party last spring,"
and then get the right answer. But even that assumes there no MITM,
the possibility of which must have been eliminated at the higher
level. Which means no such possibility exists for the cipher-change
protocol.
>You keep saying
>it's protected by a cipher. Got the privacy; where's
>the authentication?
Any cipher system which uses ciphers must protect against masquerade.
Obviously. This is a level above plaintext secrecy, and way above
cipher-change negotiation.
>> Your peculiar concentration on "authentication" obscures the real
>> problem, and that problem is that the original cipher must be secure
>> in many ways, including algorithm, key, and implementation.
>
>But the problem at issue is that the protocol you
>described grants the adversary's choice even when we
>assume these components are sound, as shown.
False. You have assumed an insecure system. The result is insecure.
Congratulations on your insight.
>> Where did
>> *you* ever say that *those* were required? But they *are* required,
>> and you missed those "attacks." Tsk, tsk.
>
>Yes, the protocol could fail because of one of these
>components. The issue here is protocol failure.
>
>
>> >Yes, it can be fixed,
>> >but the actual protocol design is not the simple
>> >exercise you had thought.
>>
>> The protocol is *just* as simple as I first proposed. There is
>> essentially no protocol there at all: We just select at random from a
>> list.
>
>And now we've seen that this doesn't work well without
>the authentication mechanism.
Now we see that the cipher-change protocol does require that the
cipher system provide security. Without that, the cipher system
cannot provide the privacy we expect.
>> The design part of this is the construction of a hidden command
>> channel behind the plaintext, the various messages and retained state
>> required to perform a clean transition, and I believe, the ability to
>> withstand message loss without problem. This does require some
>> design, and failure here means we will not change ciphers, or may do
>> so in regular ways.
>
>As shown, failure can grant the adversary his choice of
>the ciphers, though as I noted in a previous post, the
>cipher does have to be from Bob's approved list.
As described, no cipher system which allows such action can possibly
be secure or private. We certainly expect better for our plaintext,
and the cipher-change protocol is just more plaintext.
>> In other words, the *worst* that can happen from a bad cipher-change
>> protocol is that we end up using one cipher repeatedly, which is the
>> *normal* situation now. Failure in the protocol is thus only a
>> failure to take advantage of new cipher-change strength, and not an
>> introduction of weakness.
>
>Shown false.
Itself shown false.
>[...]
>> It was clear enough for almost everyone else who read my proposals.
>> Stop pretending that you have contributed something important. You
>> have not. Stop pretending that I have ignored or dissembled about a
>> real problem. I have not.
>
>It certainly wasn't clear to you. Even after people
>suggested the possibility of the attacker influencing the
>cipher, you insisted that the secret negotiation under
>a cipher ruled this out. But look at the example - the
>messages are secret under a cipher and the attacker still
>gets his choice. As I wrote the first time I brought
>this up:
>
> Ciphers by themselves offer poor authentication, and
> the authentication of the selection channel is far
> more important than its privacy. If I can find a way
> to forge, I can get you to use _my_ choice of your
> ciphers.
As I noted many times, masquerade must be made impossible, and this
actually must be impossible, in any real security system. Since
public-key technology opens the door, public-key technology is
responsible for somehow closing it. Only then do we have a secure
cipher, and only then does it support plaintext and plaintext
cipher-change messages.
>> As far as I know, the only real problem which came up was the need for
>> additional protection for the command channel, beyond that used for
>> the plaintext. That was pointed out by "others," not me. But that is
>> not your "authentication," and it is easily fixed.
>
>And the problem I noted is easily fixed. Your
>persistence in stating that the channel is protected
>a cipher and never noting an authentication mechanism
>baffles me.
Since you ask for a solution this quandary, my guess would be that you
have had little experience with secure system design above the cipher
level. The minimal discussion of this sort of thing is one of the
problems I have with the conventional crypto references.
>> >The cipher agility of your actual systems is far behind
>> >the state of the art.
>>
>> "Cipher agility" would seem to mean the ability to change ciphers
>> quickly. Any system which can do this is *beyond* the current state
>> of the art. My proposals thus *are* the state of the art in
>> non-government cryptography.
>
>But you cited your commercial systems, which have no
>cipher agility at all.
*Of* *course* it is not in my old ciphers: If my *old* cipher systems
had cipher agility, the cipher-change protocol would hardly be a *new*
idea, now would it?
On the other hand, it was my experience with those systems which
eventually ripened into my protocols for improved security, which
include frequent cipher-change, many ciphers, and multiciphering as a
matter of course.
>[...]
>> >Your commercial
>> >ciphers contradict such claims.
>>
>> I'm a little confused here: Are you saying that I have produced
>> ciphers of such complexity that they obviously were not easy to
>> design? Guilty.
>
>No, I'm saying the commercial ciphers you cited are
>far behind the state of art in cipher agility.
Then you have a remarkably strange idea of "cipher agility." But
apparently you are granting some significant advantage to those
systems which switch between 4 or 5 known ciphers. This is fine as
far as it goes, but I would like to see at least 100 ciphers, used in
3 independent levels, giving 100**3 = 1,000,000 possible ciphering
processes.
>If you
>believe so strongly that protocols should allow many
>ciphers, and also that the design is not so hard, why
>are they so monolithic?
Could that be because my ciphers are *old* designs?
>> Actually, my ciphers are fairly simple, as serious systems go. But
>> the design and actual implementation of real cipher systems is not
>> easy. Perhaps you should try it, so we can see how well *you* do.
>
>That's most of what I do for a living.
Odd. Clearly you don't publish stuff others can use or learn from or
criticize. And yet *you* obviously love to criticize. It does seem a
bit one sided.
>[...]
>> Frankly, since your years-ago claim to have a break for my Fenced DES
>> Cipher broke down in your own failure, you have been hard to live
>> with.
>
>When you first wrote that I claimed to "break" Fenced
>DES, I immediately corrected you. I called my analysis
>successful because it showed your security analysis was
>wrong. I was entirely clear on what my attack did -
>and you know it.
Well, now, let's just see:
from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, near the middle:
"That's as far as I'll take the attack for now. Perhaps I've
misunderstood something about the design; please let me know if any
of the steps I've described is impossible. I'll elaborate if parts of
my explanation are unclear. If as much as I've described can be done,
I certainly think it's a strong enough toe-hold for the analyst that
Fenced DES is dead."
from http://www.io.com/~ritter/NEWS/HUGEBLK.HTM#HB16, at the bottom:
"I think I probably have a few numbers wrong in my analysis, but
not so far wrong as invalidate the attack on Fenced DES."
So we have "Fenced DES is dead" and the (clearly implied) "I have a
valid attack on Fenced DES." Both of these seem remarkably clear to
me. But anyone who wishes to follow your slimy claims and
word-weaseling can do so for themselves:
http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
http://www.io.com/~ritter/FENCED.HTM
>> The reality is that I produced a design which, in the end,
>> withstood your attacks; I built a cipher which you thought you could
>> break, but could not. I'm sure it was very embarrassing for you.
>
>You produced a defective design, as I showed.
Nonsense. My cipher did not succumb to an attack which you thought
would work. Nor is the cipher is weaker because of your attack. My
cipher won, you lost, it's as simple as that.
It is true that your approach was unexpected to me. It is true that
you started out making significant headway. That you were unable to
finish in fact clarified a major advantage to layered ciphers: One
layer in a cipher may cause an attacker to "commit" in terms of
available information in a way which then prevents the solution of
another layer. This is not an error -- that is the way layered
systems work, and understanding this is a step ahead in cipher design.
If it had turned out that the cipher was weaker because of your
attack, then the cipher would have been flawed. It did not so turn
out. And while I would include more mixing layers in any new design,
the old design proudly stands as it is.
Various descriptions of Fenced DES can be found in the Technical
Articles by Ritter section of my pages:
http://www.io.com/~ritter/#TechnicalArticles
>How
>many times have you written that a block cipher
>should simulate a large random permutation?
Many times.
>Now we
>know Fenced DES does not do what a block cipher
>should. You
Any real design is an approximation of the desired goal. Perhaps it
could be better, but as far as you are concerned, it is more than good
enough.
>tried to make my analysis look like
>failure by making things up and saying I said them;
>you even had quotation marks around claims you
>fabricated. Do you think that by now I've
>forgotten that you wrote them and I didn't?
In one case, as I recall, quoted words provided the essence of your
argument and were correct in context. For anyone to follow your
argument, and see the reasoning beyond your claims, so they could see
how the claims could be refuted, a concise summary was needed. You
did not provide that. I did. I make no apologies for it, nor was I
misrepresenting either your position, or your words. You're just
whining because the quoted position did in fact represent your
position, and that position was wrong.
As always, I provide extensive referencing to the original material,
which is available both from me and from independent news sites. In
context, it should be very clear where the words originate, but if
not, the original message will clear that up absolutely. If I was
trying to obscure the source material or misstate the reference, I
would hardly make it so very easy to follow the reference back.
>> But
>> everyone makes mistakes, and those of us who speak out are especially
>> exposed; most of us accept reality and move on. Get over it.
>
>Me get over it? I don't think I've brought up
>your pathetic dishonesty in years.
OK, that's about it. I don't think I need to hear any more from you.
>You keep
>inserting Fenced DES into completely unrelated
>discussions so you can once again lie about what
>I wrote.
What you wrote is archived on my own site, so I could hardly lie about
it.
But as far as I know, *you* don't maintain publicly-accessible
archives, and so are free to misrepresent the past with some impunity.
Until someone reminds you of reality, of course.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ultimate Crypto Protection?
Date: 13 Nov 99 01:41:10 GMT
BigJim44 ([EMAIL PROTECTED]) wrote:
: I have a friend who tells me that the Russian military used double enciphered
: OTP all through the cold war and that NSA, with all it's expertise and computer
: hardware never had much success breaking it.
Well, the NSA did have some success, despite the fact the messages were
first in code, and then enciphered by what was supposed to be an OTP. It
is only because the Russians used some of the pads twice that we're today
hearing about the intelligence coup of Venona.
: Is double encipherment really all that effective?
With known plaintext, an attacker with a very large associative memory can
mount an attack on double encryption that reduces it to single encryption,
by trying each key for each half separately, and finding two values for
the middle result calculated from each end that match.
Other than that theoretical attack - which can be defeated by using triple
encryption - yes, double encryption is very effective.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ultimate Crypto Protection?
Date: 13 Nov 99 01:43:03 GMT
Tom St Denis ([EMAIL PROTECTED]) wrote:
: > I have a friend who tells me that the Russian military used double
: enciphered
: > OTP all through the cold war and that NSA, with all it's expertise
: and computer
: > hardware never had much success breaking it.
: Your friend is a liar. There is no such thing as a 'double-otp'. For
: any two OTP's another OTP can exist which is the composite of the two.
: For example for C = P xor K1 xor K2 there exist a K3 which is equal to
: K1 xor K2 ...
The messages that were cracked in Venona were first put into code with a
code book, and then enciphered a second time with what the Russians had
hoped would be an OTP...but wasn't.
John Savard
------------------------------
From: [EMAIL PROTECTED] (john baez)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 12 Nov 1999 17:48:48 -0800
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>john baez ([EMAIL PROTECTED]) wrote:
>: Yeah, right. That remark reassures me that you don't know what
>: you're talking about. Why make up shit like this? Do you think
>: we're all gullible idiots?
>This thread is under crosspost to several groups besides sci.math; it is
>entirely possible for a nonmathematician to make a mistake in remembering
>something he's read in _Scientific American_ or the like.
Okay, I apologize - I was getting annoyed at authoritatively proclaimed
misinformation, but I guess not everyone makes a habit of qualifying
their remarks according to the degree of certainty they have.
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 13 Nov 99 01:51:27 GMT
james d. hunter ([EMAIL PROTECTED]) wrote:
: Coen Visser wrote:
: > Let's tackle long range weather
: > forecasting and climate modelling. Even the tiniest difference between
: > our model and the real world and the two will diverge before
: > you can say: "we need infinite precision so we can calculate
: > with *real* real numbers."
: No you don't need infinite precision. Somebody decided
: 2000 years ago that it would be convenient if really, really, really,
: real numbers existed, and humans have been imagining that really,
: really
: really, real and really, really, really imaginary numbers existed ever
: since.
Oh, dear. You wouldn't like my web site then; I have a description of
Cantor's diagonal proof there.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Ultimate Crypto Protection?
Date: 13 Nov 99 01:48:04 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: Adam Durana wrote:
: > Used correctly it cannot be broken.
: And if pigs had wings, they would fly.
Pigs don't have wings, but it _is_ possible to use an OTP correctly. (Even
then, the large volume of keys required might be copied in transit, of
course.)
Just because it seldom seems to happen that way in practice doesn't make
noting the possibility a thing worthy of such harsh criticism.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Sat, 13 Nov 1999 01:59:38 GMT
Coen Visser <[EMAIL PROTECTED]> wrote:
[...]
> Keep in mind that compression is defined + O(1).
Aye, there's the rub. The + O(1) means that we
cannot meaningfully talk about whether an
individual string is compressible in the
Kolmogorov complexity sense (except with respect
to a given representation language). The length
of the string is a constant; the length of any
representation of the string is a constant. If
our notion of compressibility ignores constant
differences then there's nothing left to compare.
For _any_ string, there is some language in which
the string has a representation that is one
character long. Tell me the string and I'll
construct such a language.
The most basic cool theorem from Kolmogorov
complexity states:
For any two reasonably powerful languages L
and L', there is some constant C, such that
for all strings x, the shortest representation
of x in L and the shortest representation of x
in L' differ in length by at most C.
The order of quantification is critical. It's
easy to mess it up and think the theorem
contradicts the claim that for any string there's
a language in which the string has complexity 1.
The theorem tells us that if we ignore additive
constants, we can talk about the compressibility
of strings without concern for the representation
language. But ignoring constants only makes
sense when talking about infinite sets of strings.
For an individual string, what the theorem implies
is completely vacuous: two constants differ by at
most a constant.
> So I allow for
> some overhead of a Turing Machine definition. Now I can compress all
> finite length strings of form "0101010101010101..." by preceding
[...]
Yes. There are infinitely many strings of this
form, so it's meaningful to say their complexity
is the log base 2 of their length plus or minus a
constant. Saying the same of some particular
string is nonsense: the length of the shortest
representation of "01010101" is three plus or
minus some constant.
In conclusion, there is no meaning in talking
about whether a given string by itself is random,
in either the sense of Shannon's entropy or
Kolmogorov complexity. The entropy is defined
only when given the probability distribution, and
the complexity of a given string is meaningful
only when given the representation language. For
infinite sets of string, Kolmogorov complexity
can provide a notion of their compressibility
independent of the representation language.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Crossposted-To:
alt.math,alt.politics.org.cia,soc.culture.russian,soc.culture.europe,soc.culture.spain,alt.security
Subject: Some basic facts - internet and crypto
Date: Sat, 13 Nov 1999 02:10:15 GMT
*****************
DISCLAIMER: This unencrypted message has been intercepted and read by
several intelligence agencies before you have read it.
*****************
CIA is operating a wide and deep intelligence network in international
businesses in many regions. The objective of this network is to steal
economic, business and technological information and data for the
benefit of some specific U.S. corporations 031599
CIA's former and current agents are promoting their services to certain
international companies in order to collect specific business
intelligence for these companies (their "clients"). There have been
meetings, where identified and known CIA agents have performed this
promoting. 031599
A hidden order of influential business men and industrialists exist to
influence and transform covertly existing and new legislation, executive
orders to ensure optimum tactical and strategic financial results.,
042799
CIA is actively pursuing its economic intelligence programs to collect
economic intelligence for U.S. companies, 042799
U.S. and UK intelligence agencies are using Internet to collect economic
intelligence for U.S. and U.K businesses., 0427994
Encryption conspiracy to implement Wassenaar encryption control
agreement so that US UK intelligence agencies can collect and decipher
more easily other people's private / business information, 042799
There is an active secret channel between certain intelligence agencies
and some large software companies to enable these companies to continue
it monopolistic intentions and activities, 042799
One of the most popular encryption program is one element of NSA's
covert action program to control the strength of encryption algorithms
in the market place. An encryption application with trapdoors. Its
"author" is the member of info security architecture committee. 051699
A competitive intelligence professional society is used by some US
companies and government agencies for counterintelligence purposes.
070199
Some rental car agencies have installed microphones and other
surveillance devices into their vehicles in order to monitor their
clients. 070199
All search engine queries are used for many marketing and other research
purposes and specific IP addresses and people ID's are recorded on
tracking files. 050199
Specific hubs have been created and used by CIA, NSA and other UKUSA
intelligence agencies to monitor all Internet traffic and
communications. 031599
Most of main stream media sources and other main radio and TV stations
are controlled by some religion and other interest groups to influence
individuals' daily decision making processing on their finances,
personal matters and others. 051599
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 12 Nov 1999 21:10:36 -0500
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
>
> james d. hunter ([EMAIL PROTECTED]) wrote:
> : Coen Visser wrote:
>
> : > Let's tackle long range weather
> : > forecasting and climate modelling. Even the tiniest difference between
> : > our model and the real world and the two will diverge before
> : > you can say: "we need infinite precision so we can calculate
> : > with *real* real numbers."
>
> : No you don't need infinite precision. Somebody decided
> : 2000 years ago that it would be convenient if really, really, really,
> : real numbers existed, and humans have been imagining that really,
> : really
> : really, real and really, really, really imaginary numbers existed ever
> : since.
>
> Oh, dear. You wouldn't like my web site then; I have a description of
> Cantor's diagonal proof there.
Well, I read Cantor's original once, that seemed to be enough times.
So, why do you think I would want to visit a "scientist" web page
to read it again.
------------------------------
** 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
******************************
