Cryptography-Digest Digest #229, Volume #9 Sat, 13 Mar 99 09:13:04 EST
Contents:
Re: Crypto transmission in noisy ambient ([EMAIL PROTECTED])
Re: Entropy and Crypto-Grade Randomness (R. Knauer)
Re: Quantum Computation and Cryptography (R. Knauer)
Re: Quantum Computation and Cryptography ([EMAIL PROTECTED])
Re: Entropy and Crypto-Grade Randomness (Bill Unruh)
Re: Crypto transmission in noisy ambient (Chris Monico)
Re: How do i compute (a^b) mod n (Boris Kazak)
Re: ElGamal vs RSA ([EMAIL PROTECTED])
el-gamal as permutation for OAEP? (David A Molnar)
Re: CD Cipher
Re: CD Cipher
Re: ElGamal vs RSA ("Roger Schlafly")
Re: Finite Field with Hard Division? ([EMAIL PROTECTED])
Re: Key Schedule Error Corrected in Quadibloc III (John Savard)
Looking for encryption algorithm (kufan)
Re: Limitations of testing / filtering hardware RNG's ("Trevor Jackson, III")
Re: Quantum PRNG ("Andrew Wall")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Crypto transmission in noisy ambient
Date: Sat, 13 Mar 1999 00:19:15 GMT
> 2) Use a pure stream cipher with no error-propagation, with a message
> format (i.e. uncompressed text) that can still be read in case of error.
Try RC4. Sample 'C' source code can be found at:
http://members.tripod.com/~tomstdenis/rc4.c
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Entropy and Crypto-Grade Randomness
Date: Sat, 13 Mar 1999 00:38:35 GMT
Reply-To: [EMAIL PROTECTED]
On 12 Mar 1999 23:51:52 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>>Entropy gives a precise definition to the intuitive notion of
>>true randomness.
>Since entropy is itself not precisely defined, this statement may be
>true by useless.
There are several precise definitions of entropy.
Please explain your comment.
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Quantum Computation and Cryptography
Date: Sat, 13 Mar 1999 00:37:14 GMT
Reply-To: [EMAIL PROTECTED]
On 12 Mar 1999 23:44:57 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>Nand gates cannot be reversible. You can create a gate with two output
>channels which is reversible. But nothing which takes two inputs and
>produces one output can ever be reversible.
>With a nand gate, you have three input states which go to the same
>output. Thus you would need the second output to have three possible
>states-- it could not be a binary output.
What about a Freidken gate?
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quantum Computation and Cryptography
Date: 13 Mar 1999 01:23:45 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Bill Unruh) writes:
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (R. Knauer) writes:
>>>I have heard plenty of
>>>statements that such NAND gates are possible, that equations have
>
>Nand gates cannot be reversible. You can create a gate with two output
>channels which is reversible. But nothing which takes two inputs and
>produces one output can ever be reversible.
>
>With a nand gate, you have three input states which go to the same
>output. Thus you would need the second output to have three possible
>states-- it could not be a binary output.
so, what's wrong with having three outputs and "throwing away" the
output of the other two?
--
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Entropy and Crypto-Grade Randomness
Date: 12 Mar 1999 23:51:52 GMT
In <[EMAIL PROTECTED]> Bryan Olson <[EMAIL PROTECTED]> writes:
>Entropy gives a precise definition to the intuitive notion of
>true randomness.
Since entropy is itself not precisely defined, this statement may be
true by useless.
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: Crypto transmission in noisy ambient
Date: Sat, 13 Mar 99 00:13:11 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>"F. Arndt" <[EMAIL PROTECTED]> wrote, in part:
>
>>but are there clever ways of making the
>>process distinctly more efficient for a given bit error rate (BER)?
>
>Two ways:
>
>1) Divide the message into many short blocks (after encryption), and
use
>error-correcting codes on each one, so that errorless transmission is
>usually achieved, and small blocks of ciphertext only get
retransmitted if
>necessary.
Depending on the type of channel, shortening the block length could
make the problem worse. If the channel is bursty, for example, an
error correcting code with a longer block length may be able to
correct the errors, whereas the shorter block length would neccesitate
retransmission. This may even be true for some AWGN channels,
depending on the exact parameters of the channel. There's an _obvious_
solution that I've mentioned several times, and has been thus far
ignored (or at least, not addressed, or the postings got lost-I don't
know):
Construct a Goppa code that allows for enough random errors to
be purposely induced (so as to foil syndrome decoding) and still has
enough error correcting capability for the given channel. Then use a
McEliece type cryptosystem with that code. There are methods of
constructing "good" goppa polynomials that hide the algebraic geometry
involved, so one does not even need to go out and learn the
mathematics. I think MacWilliams & Sloane give such a construction.
Then one gets (public key) encryption and error correction in the same
box. And it's one fast box, at that. I see many advantages to doing it
this way (Easy to implement in hardware and software, faster than
RSA- I think the originator of this thread mentioned wanting to do an
RSA key exchange in the presence of noise, at least as secure as
RSA,...), and no disadvantages other than a big public key. If I'm
wrong, I'd hope someone would point out where.
In fact, even if one had intended to use a secret key system, this
method gives a secure public key system, with the only added expense
being the public key size (which is not bad at all by today's
standards of data size), since one will necessarily have to add
redundancy to the data anyway, for the error-correction capability.
>
>2) Use a pure stream cipher with no error-propagation, with a message
>format (i.e. uncompressed text) that can still be read in case of
error.
Everything except the [bits or bytes with] errors could then be read,
but what if it's binary data?
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: How do i compute (a^b) mod n
Date: 12 Mar 1999 06:08:08 GMT
Reply-To: [EMAIL PROTECTED]
Luke Herbert wrote:
>
> I would like to calculate (a^b) mod n
> where a,b and n are large integers less than approx. 2*10^9.
>
> thank you
=================
You can use "square and multiply" procedure, at the
expense of using more memory to keep the intermediate
products handy.
If you look at the binary representation of the power
to which you want to raise your number, this power can
be expressed as a sum of powers of 2:
b = k(0)2^0 + k(1)2^1 + ... + k(i)2^i
where k(j) will be either 0 or 1.
Define variables "product" and "temp".
Start with the "product" = 1, "temp" = a, j = 0.
If k(j) = 0, do nothing with "product", square the "temp":
temp := temp*temp(mod N)
If k(j) = 1, multiply "product" by "temp":
product := product*temp(mod N)
and square the "temp":
temp := temp*temp(mod N)
Proceeding like this, you will accumulate in your "product"
those powers of a, where the corresponding k(j) = 1.
You can do a simple arithmetic and verify the correctness.
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ElGamal vs RSA
Date: Sat, 13 Mar 1999 03:45:24 GMT
In article <7ca2r5$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote in message <7c9kgt$3a$[EMAIL PROTECTED]>...
> >The discussion is about using GF(2^n) itself for ElGamal, not Elliptic
> >Curves over GF(2^n). Coppersmith's algorithm applied to the former makes
> it
> >unsuitable for cryptographic use.
>
> I don't agree with this.
You don't know enough about the subject to agree or disagree.
> Coppersmith's algorithm has the same asymptotics
> as the best factoring method.
Wrong. The constant for Coppersmith's algorithm is (32/9)^1/3.
The best factoring algorithm for RSA keys has constant (64/9)^1/3.
Solving DL's over GF(2^n) via Coppersmith's algorithms is a lot easier than
solving DL over GF(p) using the Number Field Sieve to EXACTLY the same extent
that factoring 2^n-1 is easier via the Special Number Field Sieve than is
factoring N = pq by the General Number Field Sieve.
Next time I suggest you read about the subject before making such
pronouncements.
> For a given key size, DH over GF(2^n) is
> slight less secure than RSA, but users can compensate for this by
No!!! It is significantly less secure. DL over GF(2^1024) is almost
within reach now. DL over GF(p) where p is an odd 1024-bit prime is NOT
in reach.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: el-gamal as permutation for OAEP?
Date: 13 Mar 1999 04:25:55 GMT
can el-gamal be turned into a k-to-k bit permutation suitable for
use with optimal asymmetric encryption padding?
does anyone do this? has it been studied in theory or practice?
I ask because a separate thread cited the abundance of standards using
RSA as a reason to choose RSA over ElGamal. Part of the reason given
was that these standards contain proven (or at least battle-hardened)
ways of avoiding nasties like distinguishable or malleable encryptions.
While it's impossible to
go back in time and create standards for ElGamal of similar vintage,
it would be nice to learn from their previous mistakes.
Just looking at ElGamal there seems to be a problem with message expansion,
since the ciphertext is 2x the size of the plaintext (going by the
description in applied crypto 2nd ed), but I'm wondering if
there exists any variant or clever padding which may fix that. Also I
have to go through and check where the k-to-k restriction becomes
important...I know it must be, I just need to pin it down.
In any case, pointers to
papers on the subject and/or
demonstrations that it's obviously enough impossible as to be self-evident
are always welcome.
Thanks,
-David Molnar
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: CD Cipher
Date: 13 Mar 99 04:48:54 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: On Fri, 12 Mar 1999 20:14:06 GMT, [EMAIL PROTECTED]
: (John Savard) wrote:
: >I remember discussing something like this a while back, in posts entitled
: >"My Large-Key Brainstorm", so, naturally, I'm biased in favor of the idea.
: Well... don't keep us in such suspense. What is it?
Essentially, I took DES, the Vernam two-tape system, and other ideas, and
stirred...
Start with a block cipher in OFB mode. Use that to generate bits. These
bits are taken, two at a time, to increment the counters that advance
through sixteen lists, each with a different length, of 48-bit subkeys.
The sixteen subkeys are then used to encipher a plaintext block in what is
otherwise DES.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: CD Cipher
Date: 13 Mar 99 04:45:15 GMT
R. Knauer ([EMAIL PROTECTED]) wrote:
: On Fri, 12 Mar 1999 20:18:01 GMT, [EMAIL PROTECTED]
: (John Savard) wrote:
: >My "Large-Key Brainstorm" idea
: Well... don't keep it a secret. Where is it?
It was posted to this group a few months ago. But it's also in the
conclusions section of Chapter 4 of my web site:
http://members.xoom.com/quadibloc/comp04.htm
has links to all of Chapter 4, so it's just one jump away from there.
John Savard
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: ElGamal vs RSA
Date: Fri, 12 Mar 1999 22:18:59 -0800
[EMAIL PROTECTED] wrote in message <7ccn0j$ltm$[EMAIL PROTECTED]>...
> [usual ad hominem attack snipped]
>> Coppersmith's algorithm has the same asymptotics
>> as the best factoring method.
>
>Wrong. The constant for Coppersmith's algorithm is (32/9)^1/3.
>The best factoring algorithm for RSA keys has constant (64/9)^1/3.
I was ignoring the constant. Your statement implied that DL over GF(2^n)
was easy.
>> For a given key size, DH over GF(2^n) is
>> slight less secure than RSA, but users can compensate for this by
>
>No!!! It is significantly less secure. DL over GF(2^1024) is almost
>within reach now. DL over GF(p) where p is an odd 1024-bit prime is NOT
>in reach.
DL over GF(p), p = 1024 bit prime, is more secure than 1024 bit RSA.
1024-bit RSA is more secure than DL over GF(2^1024). Agree? Good.
If someone wants to use DL over GF(2^n), and his application is such
than n = 1024 is not safe enough, then he can pick n = 2048 or even
a larger value, if he wishes.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Finite Field with Hard Division?
Date: Sat, 13 Mar 1999 07:40:05 GMT
On Fri, 12 Mar 1999 20:31:14 GMT, [EMAIL PROTECTED] (Guenther
Brunthaler) wrote:
>On Thu, 11 Mar 1999 04:31:02 GMT, [EMAIL PROTECTED] (Peter L.
>Montgomery) wrote:
>
>> If the field has q elements, then x^q = x for all x in the field.
>>The inverse of any nonzero x is x^(q-2). You can get this with
>>O(log(q)) multiplications, regardless of the method used to
>>encode field elements.
>
>Am I doing something wrong? This statement only seems to be true ONLY
>for field sizes 1, 2, 3, 5, 7 and 11. (But to be honest, I just tested
>all field sizes up to about 30)
>
>
>
>Greetings,
>
>Guenther
A field is, afterall, a group. The order of any element of a group
divides the order of the group.. Since we are considering
multiplication in a field here, the order is one less than the size of
the field, thus, in this case, q-1. (The order of the multiplicative
group of a field of order q is q-1---throw out 0) Thus for every x in
the field, x^(q-1)=1. That is, x^q=x, as was originally stated
(correctly).
Mike
Decrypt [EMAIL PROTECTED] with ROT13 for email address.
NOTICE TO BULK EMAILERS: Pursuant to US Code,
Title 47, Chapter 5, Subchapter II, 227, any
and all nonsolicited commercial E-mail sent to
this address is subject to a download and archival
fee in the amount of $500 US. E-mailing denotes
acceptance of these terms.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Key Schedule Error Corrected in Quadibloc III
Date: Fri, 12 Mar 1999 22:51:46 GMT
[EMAIL PROTECTED] () wrote, in part:
>John Savard ([EMAIL PROTECTED]) wrote:
>: My description of the key schedule for Quadibloc III completely omitted any
>: mention of how the key-dependent S-box S8, used in Quadibloc III as well as
>: in Quadibloc II, is generated.
>There was another mistake: the middle GoodStuff rounds were given an
>arrangement that did not at all correspond to the original design goals:
>the second round stood in the (second) best relationship to the first, but
>the third was not appropriate at all: it has now been changed, so that it
>has the (third) best relationship.
And there were a few more minor errors in S8 generation in Quadibloc III
and Quadibloc IV ER that I have just corrected, mainly centering on the
number of bytes of input required to generate the permutation.
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (kufan)
Subject: Looking for encryption algorithm
Date: 8 Mar 1999 15:31:40 GMT
Does anyone know any kind of encryption algorithm that
using 2 or more keys to encrypt and using 1 key to decrypt,
and the encryption speed will be as fast as symmetric
encrypt algorithm?
------------------------------
Date: Sat, 13 Mar 1999 08:29:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Jim Gillogly wrote:
> > > > R. Knauer wrote:
> > > > > If you filter the output as you suggest, then the TRNG is no longer
> > > > > proveably secure in principle.
>
> > > Trevor Jackson, III wrote:
> > > > Show me the leak. Otherwise stop repeating this nonsense.
>
> > Jim Gillogly wrote:
> > > OK. Just to be definite, let's assume that [you filter the TRNG
> > > stream so that] there will never be a run of 8 0-bits in a row.
> > >
> > > We now have a message coming in. The ciphertext starts "YNAQJ BFPGD".
> > > ... I can tell with certainty that this message did not
> > > start with "YES" or "INREP LYTOY".
>
> Trevor Jackson, III wrote:
> > In principle (theory) you are correct. However, in practice it is
> > meaningless. Consider the 10 character message that you used as an example.
> > A perfect OTP would allow any plsible decruption of those 10 characters or
> > N^10 possible decryptions where N is 64 or 256 depending on your alphabet.
> > Let's say N=64 to give you the maximum benefit of the doubt.
>
> I don't care what N is. Let's call it 26 for the purpose of exposition.
> The point of a OTP is that it leaks no information. As soon as you let
> it leak even one bit ("this letter is not a Y"), you lose all the theorems
> and you must start being careful. Let's make my example even more pointed.
>
> You are the chairman of the Federal Reserve of the Duchy of Florin, and
> each day you send a message to all 100 branches of the Federal Reserve
> bank, each of which has its own OTP to talk to you. The message is
> one of "UPXX", "DOWN", or "EVEN". I have tapped your outgoing line. If
> I can tell which way you're moving the interest rate before it reaches
> the Florinese bourse, I get rich.
>
> If you're using a true OTP with each of the branches, I'm out of luck. I
> can see that you've sent 100 4-letter messages, and that's all. If one of
> the messages says "DOWN", I shrug, since I know it was by chance. If you're
> filtering as hypothesized above, I win almost every day with a simple
> positional frequency count, because the 100 messages will have at most 25
> letters in each of the four positions. It's a near certainty that one of
> the letters of the other messages will appear in one or more positions of
> the ciphertext, and I'll be able to eliminate those messages.
There are several issues here. Let's try to separate them. The first
consideration of the FRDF example is that all unsalted ciphers are
vulnerable to similar analysis. On the first three days the tapper
collects ciphertexts, labeling each with the behavior of the FRDF. On
or before the fourth day the tapper is going to receive a ciphertext
whose meaning is known.
================
Secondly, this is example is so small that I find it
non-representative. To show why, let's take an even sillier example,
that being two messages, "0" and "1", whose meaning is important (e.g.,
status of "launch WWIII" button) but otherwise irrelevant.
Working blindly on the original premise, that we don't want the
plaintext to shine through the cipher, we'll just have to filter out the
null key/pad of '0' leaving only the key/pad of '1' for encipherment.
Obviously this is a ridiculous failure.
The FRDF example above is not ridiculous, but it contains the same
conceptual misapplication of filtration. As applied it is indeed
flawed. However, the solution is not to avoid filtration, but to add
sufficient filtration to correct the flaw.
Consider that the pad maps the plaintext onto some ciphertext. The
trivial filter prevents a mapping from a plaintext character onto an
identical ciphertext character. A useful filter prevents all mappings
that produce ciphertext that appears to contain any possible plaintext.
I.e., we not only prevent identity mappings, but mappings from one
plaintext character to any other.
Consider a partition of alphabet into 3 possible plaintext characters
and 23 possible ciphertext characters for each of the first three
character positions and 2/24 for the last character. Filter out pads
that map from the plaintext alphabet back into the plaintext alphabet.
This eliminates leakage.
===============================================
The above analysis is easier when we realize that all of the information
in the FRDF messages is contained in the first character. The trailing
characters are redundant. In fact, only a couple bits of the leading
characters are meaningful because the entire message space fits into a
two-bit representation.
Given three two-bit message codes one needs a two-bit pad for the
cipher. I suppose one could filter out the '00' pad, leaving '01',
'10', and '11', but this is another blind application of filtration.
Let me avoid overloading the OTP concept by defining OTP to mean the
classic system of the same name without filtration, and single-use pad
(SUP) cipher as an OTP that uses filtered pads.
The purpose of filtration as applied to a SUP cipher is the same as the
filtration applied to the collection of 1,000,000 random numbers
(published by Rand Corp I think). This body of numbers was heavily
conditioned to remove apparent biases. It was supposed to represent a
sampling of numbers from a random source. But the unbalanced
distributions were eliminated so ruthlessly that the lack of outliers is
itself a form of bias.
In a similar fashion an SUP cipher is designed to eliminate the
infrequent but expected appearance of apparent bias (as opposed to
actual bias). In a pad of 2^16 bits, we would expect, on average, to
find one run of 16 zeros and one run of 16 ones. If we find a pad
containing 32 consecutive zeros we've got a rare pad because we would
only expect to find one such pad in every 2^16 samples. If we get such
pads more often than once every 2^16 there's probably a systematic bias
in the pad generator.
Of course it is unreasonable to perform an exhaustive search on pads
that size because the search space is 2^65536. So we use prophylactic
means to reduce the possible damage caused by potential biases.
Filtration is only useful if it lowers the odds of a systematic bias.
On a more abstract level than simple pattern elimination, if a spectral
test shows a deviation past some rejection threshold, say one sigma, we
should be able to reject a particular pad without compromising the
security of the system.
Note that PRNG masking accomplishes much the same benefit. A good PRNG
with N bits of internal state is going to have a cycle length of almost
2^N. A perfect PRNG will represent every possible subsequence of length
N once in every 2^N bits. This means that masking a biased RNG with a
good PRNG* will reduce the occurrence of extreme samples to their proper
rarity. Apparently non-normal sequences will still apper in the
combined output, because they can be created by chance interactions of
the original RNG and the mask, but these accidental creations will be
properly rare.*
* Note that the masking PRNG must be unrelated to the original RNG. If
they are related their correlations may create new biases that make the
output extremely "bad".
>
> When you muck about with your TRNG stream this way, you lose all the
> theorems about infallibility, and have to start doing other things to
> achieve "acceptable" levels of confidence. You're then talking about
> "good enough" rather than "perfect security".
>
> OTP is a special case. If you muck with it, you must redo the analysis.
If you muck with it in the brutish manner described, yes. But if you
muck with anything that brutally, you are going to create bruises
indicative of damage. This is not news.
Consider the type of filtration based on spectral testing described
above. Do you believe it invalidates the OTP in a similar manner?
>
> > > Filtering the TRNG stream in the way you suggest (eliminating runs
> > > of 0's or 1's) breaks this assumption.
> >
> > In theory yes. In practice no. Try it yourself. Set up a filter allowing
> > only the best 50% of pads and show that it "breaks" the cipher.
>
> A cipher need not be read completely in order to leak some information.
> A OTP does not leak any information other than a bound on the length.
>
------------------------------
From: "Andrew Wall" <[EMAIL PROTECTED]>
Subject: Re: Quantum PRNG
Date: Sat, 13 Mar 1999 12:47:36 -0000
Christopher wrote in message ...
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
<snip>
<snip>
>It seems to me the only thing that would make it a better choice is if
>it's proven that attacking the seed is easier then studying its output.
>BTW, how do the other PRNGs fit here. I've seen mention of generators
>with extremely large cycles (256 bit), if only the least significant byte
>of one of these is used (making 31 bytes hidden internal state) is it
>probable that figuring the state from a stream is as much work as guessing
>the seed?
>
I would like to know what quality of a hardware PRNG would be.
What if you built one with a large amount of non-volatile memory to hold its internal
state that produced numbers all the time?
Whenever it was powered on, it produced numbers whether you wanted them or not.
I propose that no-one could guess better than 1/2^N (where N is the number of bits in
the memory) what the internal state was and
therefore what the next number would be.
If you only take numbers when you want them, you are introducing a true random factor
also.
Would this then qualify as a TRNG?
Andrew Wall
------------------------------
** 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
******************************
