Cryptography-Digest Digest #805, Volume #9 Wed, 30 Jun 99 07:13:03 EDT
Contents:
A Quanitative Scale for Empirical Length-Strength (wtshaw)
Re: The One-Time Pad Paradox ("Douglas A. Gwyn")
Re: The One-Time Pad Paradox ("Douglas A. Gwyn")
Re: two questions ("Douglas A. Gwyn")
Re: trapdoor one way functions (David A Molnar)
Re: one time pad (Greg Ofiesh)
Re: PIII Random Number Generator? ("Douglas A. Gwyn")
Re: two questions ("dlk")
Re: Can Anyone Help Me Crack A Simple Code? ([EMAIL PROTECTED])
Re: two questions ("Douglas A. Gwyn")
Re: one time pad ("Douglas A. Gwyn")
new book ("Douglas A. Gwyn")
Re: A slide attack on TEA? ("Joe")
Performance of cryptographic algorithms (Peter Krueger)
Re: two questions ("Douglas A. Gwyn")
Re: one time pad (Rob Warnock)
Re: Secure link over Inet if ISP is compromized. (Alan Braggins)
Re: A Quanitative Scale for Empirical Length-Strength (Mok-Kong Shen)
Re: A slide attack on TEA? (Ed Yang)
Re: Performance of cryptographic algorithms (Ed Yang)
Re: two questions ([EMAIL PROTECTED])
Re: Can Anyone Help Me Crack A Simple Code? (Ed Yang)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: A Quanitative Scale for Empirical Length-Strength
Date: Tue, 29 Jun 1999 22:42:50 -0600
A Quantitative Scale for Empirical Length-Strength
Empirical---1.a. Relying on or derived from observation or experiment. b.
Verifiable or provable by means of observation or experiment. 2. Guided
by practical experience and not theory....
Finding mathematical proof or formula for assigning strength to a
particular algorithm seems an elusive goal. The folk method of looking a
bit lengths may be acceptable to the underinformed, but not to those who
appreciate the diversity of algorithms. What is written here is a stab at
preducing something quantitatively useful in one aspect of strength.
While it is somewhat competitively popular to look for the best, the
strongest, the fastest, the desire to compare algorithms on some common
basis seems natural.
I would think that starting near the bottom is important, because we have
lots of data accumulated over decades. Travel along with me here to seen
that the same procedure might well work to look at one component of
strength in numerous algorithms.
Surely, there are many ways of looking at strength, and many factors that
might be included in a comprehensive picture of strength. But, in a
philosophical bent, strength in algorithms is always to be referenced to
what you want them to do for you.
We cannot escape what Shannon has said, or rather tried to do, about
caluculating the expected average amount of ciphertext necessary to
confirm a solution with an algorithm. What I am considering here is
something similiar, the recommended amount of ciphertext for being
solvable, art most definitely included.
My source of good information is none other than the ACA, who places
windows of length for submissions for solvable algorithms. I am looking
at only some of those that have a clear character count, not those defined
in so many columns or rows. The usual designation for length, beyond some
general guidelines as to admissable text qualitities and prefered types of
key construction, is from x to y, and sometimes never less than w or more
than z.
A few ciphers are *Length: Trivial*, easily solved if you know the trick.
A Caesar would fit here. Only a few ciphertext characters need be
available.
Now to those that are not trivial:
Clearly, near the low end of the totem pole are Baconian at 25-33,
Autokey, Interrupted Key, and Running Key, all at 40-50. If a cipher can
be usually solved with less than about 50 characters of ciphertext, it is
*Length: Extremely Weak*.
A little stronger are Morbit, 50-75, Aristocrats, 75-100, then Playfair,
80-100, and a host of others with lengths recommend above, below, and
around 100 chararacters. These are all still *Length: Very Weak*.
Moving up, we find ciphers who have recommended lengths above, below, and
around 200 characters. A few of the just plain *Length: Weak* ciphers are
Diagrafid, 120-220, Granpre, 150-200, Brazeries, 150-250, Trisquare,
200-250, and Pollux, 155-385.
I would grant that with computer methods, these routine lengths might be a
bit high. Shannon would allow any method, but the data we have is the
data I will use. Like an engineer that builds a bridge that collapses in
the wind because he did not include all important factors, attempts to
closely predict quantified minimum lengths of ciphertexts are likely to be
failed efforts due to the varied qualitites of plaintexts, if for no other
reason. I opt for that which is soundly known, not being satisfied with
mere equational expectations, fact not theory.
Oh, I mentioned a scale of some sort. To make something of the sort
useful enough to include algorithms at the low end, these, and, yes, the
well known, DES, which is no killer in the required ciphertext length
department, while allowing much length-stronger ciphers to be included,
something more than a simple letter quantity.
26-27 letters is a starting point at which to give a value of one.
Choosing 27, close enough to 26, also allows me to do some trit related
calculations, and covert mathematically to bits and other information
units as whim might require.
Given 27 as a base, close enough to 26, the the length-strength value of
one means
that approximately 27 characters are necessary to solve the ciphertext for
its key and message. The value of two means that 27*27, or 729 characters
are necessary, more than enough to eclipse Pollux. Just for curiosity, I
find that 27^1.5 = 141. For the trivials, 27^0.5 = 5
On the L-S scale, the named ciphers mentioned above are somewhere between
1 and 2. We can presume that all pencil and paper solvables are also
pretty well defined in much the same range. In reality, given advances in
attacking a new algorithm, placement on the L-S scale should diminish to a
stable range.
What is the other end of the scale? Sure for the step-child OTP it is
infinity. Responsibly, I would consider no algorithm as strong unless it
had a higher L-S value than those mentioned. A value of 4 is something
like a half a million characters. A value of 7 is 10^10 characters.
L-S is not the only factor in Algorithm Strength, but it is worth
mentioning as one of the important ones. To not include it appropriately
is to look foolish.
--
It's always possible that a politician is acting out of principles.
--Michael Kinsley of Slate.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Tue, 29 Jun 1999 21:57:48 GMT
"Dr.Gunter Abend" wrote:
> Do you see any weakness in this modified OTP method? It merely
> excludes such ciphertexts that could give the adversary a hint,
> even a misleading one. The actual keystring is still truely random.
You would require slightly more key material *and* a much more
complex encryption system, for no gain whatsoever.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The One-Time Pad Paradox
Date: Tue, 29 Jun 1999 22:01:48 GMT
John Savard wrote:
> If, however, by incredibly bad luck, one of the first thousand or so
> one-time-pads encountered is all zeroes, and the particular message
> to be sent with it is particularly important, the situation at least
> seems different.
Sure; it's occurring in some other universe than ours, since in the
entire life of our universe, that is practically certain not to occur.
It is *more* likely that the pad will accidentally be such that every
message is encrypted to apparent plaintext that conveys the exact
*opposite* of the actual meaning. Why aren't you happy about *this*
possibility?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: two questions
Date: Wed, 30 Jun 1999 04:50:07 GMT
William Tanksley wrote:
> DES-OFB uses a block cipher to generate a keystream, which is XORed
> into the plaintext. Obviously, any block cipher could be used in OFB
> mode.
Yes, but you're not using it as a block cipher any more, just as a
PRNG running totally independently of the input plaintext.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: trapdoor one way functions
Date: 30 Jun 1999 04:56:10 GMT
Nicol So <[EMAIL PROTECTED]> wrote:
B
> Yes. Taken at face value, the statement is obviously false, as you'd
> probably notice when you look at it a second time.
OK. Thank you for pointing that out.
-David
------------------------------
From: Greg Ofiesh <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 30 Jun 1999 05:19:31 GMT
> I am 100% certain that they do not have such a device. Such a machine
> cannot be built in this universe, regardless of the technology.
Show me the physics. I need the physics. Why can't POSSIBLY a quantum
computer be built in this universe?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: PIII Random Number Generator?
Date: Tue, 29 Jun 1999 21:47:18 GMT
Mok-Kong Shen wrote:
> How 'random' are these? Do you have a standard unit of meausre of
> 'randomness'?
Sure; it's a process description.
------------------------------
From: "dlk" <[EMAIL PROTECTED]>
Subject: Re: two questions
Date: Wed, 30 Jun 1999 06:56:26 GMT
I've been curious about this myself for some time now. I've
come up with two reasons for this:
A. Block ciphers are "sexier" - i.e. fancy, cutting edge math.
B. Many BC's lend themselves well to implementation in hardware?
A I'm pretty sure of, people tend to want to work on the "fun" stuff. B
I'm not so sure about....
Since the topic of RC4 has come up:
1. It takes 512 bytes of RAM to implement RC4 (2 arrays of 256 bytes)
2. Maximum key is 2048 bits (256 * 8)
3. It is very nice, compact and quick PRNG with a period of 2^1700
Thought I'd throw those 3 points out here, so to speak, since I've seen all
sorts of mis-info propagated in this NG and others about it.
What I'd like to see is a paper on the "math" behind RC4. If anyone knows
of such pls post or email me a link. Curious thing: entering "RC4" in
a simple search on Yahoo gets 1 return (something about the Tokyo
music scene). Same critieria for Altavista will keep one busy for awhile
(>10K hits) but no papers of any depth...
Dave Keever
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Wed, 30 Jun 1999 07:13:16 GMT
I can give you a solution, however this may not be the algorithm you
need. You can assume I am a neural network, which generalized the data
you have presented, with zero error in the training set. The
generalized rule may or may not be what you are looking for. :-) This
is why everyone is telling you that there are infinite number of
solutions. Assuming that the underlying algorithm is really simple
(which means the author still thinks adding numbers are a good way of
obtaining checksums) you can observe the following:
5 == 8+2+2+8+5+8+1+8+3 = 45 (mod 10)
7 == 5+3+9+8+0+4+8+2+8 = 47 (mod 10)
... and so on and so forth ...
I hope what you are trying to do is not illegal. ;-)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: two questions
Date: Tue, 29 Jun 1999 22:13:17 GMT
[EMAIL PROTECTED] wrote:
> 1. Block ciphers are actually more versitile than stream ciphers. A
> block cipher can be used as a stream cipher, ...
That's exactly backward. A block cipher *cannot* be used as a stream
cipher, since nothing can be emitted until an entire block is ready.
> 2. As far as I know, no one has broken RC4. The only other stream
> cipher that I know of that I haven't heard of being broken is SEAL.
There are numerous stream ciphers that have never been broken, to the
best of our knowledge. Even SIGABA was in this category, although I
think under favorable circumstances we now have the technology to
break it, many decades after its deployment.
> 3. There has been a lot of research done into stream ciphers, however
> I think we're in a lull right now since people are analyzing the
> properties of FCSR's (Feedback Carry Shift Registers). The big
> problem with stream ciphers is generating a fast, "random" number
> generator.
No, that's actually a rather stupid way to build a stream cipher.
This question seems to come up every few months, always with the
same (mostly wrong) answers.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Wed, 30 Jun 1999 07:56:44 GMT
Greg Ofiesh wrote:
> > I am 100% certain that they do not have such a device. Such a machine
> > cannot be built in this universe, regardless of the technology.
> Show me the physics. I need the physics. Why can't POSSIBLY a quantum
> computer be built in this universe?
There has been an awful lot of context dropping here recently.
The post to which you replied actually didn't say a quantum
computer couldn't be built, just that one capable of finding a
1024-bit key via brute-force search (presumably in a reasonable
amount of time) couldn't be constructed. That might be a
defensible assertion.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: new book
Date: Wed, 30 Jun 1999 08:16:00 GMT
Code Breaking : A History and Exploration
by Rudolf Kippenhahn, Ewald Osers (Translator)
(Found via Amazon; I haven't seen it yet.
The fact that Kirkus thinks it is too technical
makes me think it might be a good book.)
------------------------------
From: "Joe" <[EMAIL PROTECTED]>
Subject: Re: A slide attack on TEA?
Date: Wed, 30 Jun 1999 19:05:04 +1000
David Wagner <[EMAIL PROTECTED]> wrote in message
news:7lc7vi$orc$[EMAIL PROTECTED]...
> In article <7kq6c1$qd1$[EMAIL PROTECTED]>,
> Jooyeon Cho <[EMAIL PROTECTED]> wrote:
> > I suspect a slide attack can be applied for TEA.
> > The TEA algorithm consists of 32-round identical F-functions.
> > And 128-bit master key is simply used in each round.
>
> Aren't you forgetting about "c", which is used to introduce
> diversity into the round functions?
Excuse me for my ignorance.
But "c" is not data dependent but predictable.
I thought If we could find a slid pair, variables were only key values(128
bits).
Because we know the input and output values of round function, "c" plays
only the role of the change of input value.
However, I'm not sure the round function is weak or not because I regarded
one cycle as one round.
Joe
------------------------------
From: [EMAIL PROTECTED] (Peter Krueger)
Subject: Performance of cryptographic algorithms
Date: Wed, 30 Jun 1999 09:19:57 GMT
Hi,
I'm looking for a survey of the performance of cryptographic
algorithms, symmetric, asymmetric and one-way hashs.
Fine would be an analysation of efficient algorithms in
the O-Notation.
I couldn't find something in the Internet, that's why I'm asking.
Bye
Peter
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: two questions
Date: Wed, 30 Jun 1999 07:59:47 GMT
dlk wrote:
> A. Block ciphers are "sexier" - i.e. fancy, cutting edge math.
That can't be it. The math involved with stream ciphers tends to be
much more interesting (and more generally applicable to other things).
> B. Many BC's lend themselves well to implementation in hardware?
Stream ciphers tend to be even simpler to implement in hardware.
Usually they are just a clock, a few shift registers, and a few
simple logic gates.
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: one time pad
Date: 30 Jun 1999 09:27:29 GMT
<[EMAIL PROTECTED]> wrote:
+---------------
| First, "genuinely random" does not imply provably random. Second,
| genuine is ingenuous. Like my wallet which is genuine imitation
| cowhide. The hardware RNGs available are genuine RNG _simulators_.
| Until we have a rigorous definition of random that's all we'll ever have.
+---------------
We *have* a rigorous definition of random, given in Chaitin's papers
on Godel's Proof. And he *proves* that you can't "prove" a random
stream is "genuinely random"... You can't only (maybe) prove it *isn't*
(but even then, only if it fails before you give up watching). See
for example:
http://www.cs.auckland.ac.nz/CDMTCS/chaitin/sciamer.html
"Although randomness can be precisely defined and can even
be measured, a given number cannot be proved to be random."
...
"In a formal system of complexity "N" it is impossible to prove
that a particular series of binary digits is of complexity greater
than "N+C", where "C" is a constant that is independent of the
particular system employed."
But since a "genuinely random" stream is one whose complexity is equal to
its length (intuitively, it can't be compressed), there's no way to prove
that a generator which generates streams longer than "N+C" is in fact
"random". [Note: This is a "hard" limit, as it falls right out of Godel's
Proof (as extended by Chaitin).]
+---------------
| This is ingenuous again. "Provably random" in context does _not_ mean
| "I can't break it". It means "I can prove nobady can ever break it".
+---------------
But even if an OTP *is* "genuinely random" (whatever you want that to mean),
you can't *prove* it!!!
So even though we all know that a "provably random" OTP would provide provably
secure communciations, there's no such thing as a "provably random" OTP!!
-Rob
p.s. But an OTP based on a "good enough" physical random generator
(say, thermal noise XOR'd with radioactive decay) is certainly more
secure than your key-distribution method! ;-} ;-}
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: Secure link over Inet if ISP is compromized.
Date: 30 Jun 1999 11:13:15 +0100
"Else" <[EMAIL PROTECTED]> writes:
> >That is incorrect. Any internet encryption sceme is as secure as the
> >parameters allow it to be.
> Show please how SSL is secure against man-in-the-middle attack.
Use of client and server certificates, and the trusted authority
mentioned below.
> >If, for example, a trusted certification authority/ trusted public key
> >collection exists,
> How do you access this authority? Whould not it be thorough the ISP?
It needn't be. For example see
http://www.cl.cam.ac.uk/Research/Security/Trust-Register/index.html
"This book is a register of the fingerprints of the world's most
important public keys; it implements a top-level certification
authority (CA) using paper and ink rather than in an electronic
system."
If _all_ your communications, your phone, your mail, face-to-face
conversations, are compromised, and you have no existing shared
secrets with the person you want to communicate with, then you can't
establish a secure channel.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A Quanitative Scale for Empirical Length-Strength
Date: Wed, 30 Jun 1999 12:36:42 +0200
wtshaw wrote:
>
>
> Now to those that are not trivial:
>
> Clearly, near the low end of the totem pole are Baconian at 25-33,
> Autokey, Interrupted Key, and Running Key, all at 40-50. If a cipher can
> be usually solved with less than about 50 characters of ciphertext, it is
> *Length: Extremely Weak*.
>
> A little stronger are Morbit, 50-75, Aristocrats, 75-100, then Playfair,
> 80-100, and a host of others with lengths recommend above, below, and
> around 100 chararacters. These are all still *Length: Very Weak*.
>
> Moving up, we find ciphers who have recommended lengths above, below, and
> around 200 characters. A few of the just plain *Length: Weak* ciphers are
> Diagrafid, 120-220, Granpre, 150-200, Brazeries, 150-250, Trisquare,
> 200-250, and Pollux, 155-385.
Not all names above are familiar to me. A question: How about the
classical transposition cipher (enter text in rows of a matrix and
using a key to take out in columns) applied twice with two different
keys?
M. K. Shen
------------------------------
From: Ed Yang <[EMAIL PROTECTED]>
Subject: Re: A slide attack on TEA?
Date: Wed, 30 Jun 1999 03:39:41 -1000
Joe wrote:
>
> David Wagner <[EMAIL PROTECTED]> wrote in message
> news:7lc7vi$orc$[EMAIL PROTECTED]..
> > In article <7kq6c1$qd1$[EMAIL PROTECTED]>,
> > Jooyeon Cho <[EMAIL PROTECTED]> wrote:
> > > I suspect a slide attack can be applied for TEA.
> > > The TEA algorithm consists of 32-round identical F-functions.
> > > And 128-bit master key is simply used in each round.
> >
> > Aren't you forgetting about "c", which is used to introduce
> > diversity into the round functions?
>
> Excuse me for my ignorance.
> But "c" is not data dependent but predictable.
> I thought If we could find a slid pair, variables were only key values(128
> bits).
> Because we know the input and output values of round function, "c" plays
> only the role of the change of input value.
>
> However, I'm not sure the round function is weak or not because I regarded
> one cycle as one round.
>
> Joe
The round function is not as weak as my mind:
sum += delta
y += (z<<4)+k[0] ^ z+sum ^ (z>>5)+k[1]
z += (y<<4)+k[2] ^ y+sum ^ (y>>5)+k[3] /* end cycle */
delta is a constant. If you can find the key k[] knowing y, z
initially and y and z after the round, then it is weak.
See
http://www2.ecst.csuchico.edu/~atman/Crypto/code/tea-encryption.alg.html
for more information. Unless someone here can tell me this is
weak, then the slide attack will not be an appropriate attack
on TEA. (In California, it is now legal to export source code,
but this code I edited so it cannot run as is).
--
Oxygen : Love It Or Leave It !
------------------------------
From: Ed Yang <[EMAIL PROTECTED]>
Subject: Re: Performance of cryptographic algorithms
Date: Wed, 30 Jun 1999 03:47:57 -1000
Peter Krueger wrote:
>
> Hi,
>
> I'm looking for a survey of the performance of cryptographic
> algorithms, symmetric, asymmetric and one-way hashs.
> Fine would be an analysation of efficient algorithms in
> the O-Notation.
>
> I couldn't find something in the Internet, that's why I'm asking.
>
> Bye
>
> Peter
Here are 15 algorithms with very extensive documentation and
perfomance measurements. They are candidates for the Advanced
Encryption Standard for the next century.
http://aes.nist.gov/
--
Oxygen : Love It Or Leave It !
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: two questions
Date: Wed, 30 Jun 1999 11:00:02 GMT
In article <7lbs1j$[EMAIL PROTECTED]>,
"Harvey Rook" <[EMAIL PROTECTED]> wrote:
> You can use a stream cypher as a block cypher. To turn a stream
cypher
> into a block cypher by...
> Stream0 = Encrypt( Password, password );
> Stream1 = Encrypt( Password, Stream1 );
> Stream2 = Encrypt( Password, Stream2);
Sorta... in the case of RC4 it does a feedback on the sbox, which
updates with each output.
> Today, 768 bytes of ram is nothing. Are you sure it's slower? I know
> that a good implemenation of RC6 is faster than RC4.
It would be cheaper if you could fit the encryption and host code in
smaller chips. I wrote a sample RC4 code that takes 400/256 memory
(rom/ram). I wrote it in 'C' and compiled with DDS for the 68HC11.
That's pretty small. With a 62C08 you could fit the RC4 state and
about 768 bytes of host data...
In most implementations RC4 takes about 7 to 10 cycles per output.
Most AES ciphers are on the mark of about 18 cycles per byte. I don't
see how they are faster. (This is cycles per byte not block).
Iterating RC4 16 times cost about 180 cycles, most AES ciphers are 250-
350 cycles....
> Stream ciphers have some inherent weaknesses that block ciphers don't
Not really. A weakness in block ciphers is chosen plaintext as well.
Have you heard of differential and linear cryptanalysis?
> First off if you know the plaintext, you can edit the cipher without
needing
> to find the password. Provided the cipher doesn't implement a message
> digest, you won't get caught.
Well first off the plaintext will not resemble what it should. If you
change a byte of ciphertext (presumably you don't have access to
plaintext), when you decrypt it, the text will not make sense.
> In addition, you can't use the same password twice with a stream
cipher.
That's what a message salt is for. If you want to know most programs
don't use the same symetric key twice. It's called message
independance.
> So, why use a stream cipher?
You have not presented a worthy argument. I think my stance still
holds.
What I am trying to promote is that if RC4 is so secure (which I
currently believe it is). Why bother writing block ciphers? If RC4
makes truly cryptographically secure random output then we should use
that.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Ed Yang <[EMAIL PROTECTED]>
Subject: Re: Can Anyone Help Me Crack A Simple Code?
Date: Wed, 30 Jun 1999 04:04:13 -1000
mercury wrote:
> If anyone has any helpfull advice, I would very much appreciate it.
> Thanks.
>
> -mecrury
>
> My Six Number Sets:
>
> 582 285 8183
> 753 980 4828
> 653 429 9888
> 833 285 8883
> 528 853 8849
> 628 382 2858
I called all of those telephone numbers and I got the same
result for each one. I got a recording from the telephone
company asking me to look up the number again and make sure
it is correct. Please do that for me, Mercury, if that is
your real name (you spelled your name wrong, maybe you
typed the numbers wrong, too).
--
Oxygen : Love It Or Leave It !
------------------------------
** 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
******************************
