Cryptography-Digest Digest #325, Volume #10 Tue, 28 Sep 99 18:13:03 EDT
Contents:
Re: simple algorithm for hardware device? ("Trevor Jackson, III")
Re: Electronic envelopes ("Richard Parker")
Re: Bit commitment via hash and coin flipping (Anton Stiglic)
Re: ECC97 Challenge Solved ("Trevor Jackson, III")
Re: NEMA, Swiss cipher machine ("Douglas A. Gwyn")
Re: Perfect Shuffle Algorithm? (John Savard)
Re: Electronic envelopes ("Matt Timmermans")
Re: Bit commitment via hash and coin flipping ([EMAIL PROTECTED])
Re: Perfect Shuffle Algorithm? (Jean-Jacques Quisquater)
Re: Exclusive Or (XOR) Knapsacks ("Matt Timmermans")
Re: ECC97 Challenge Solved (Tom St Denis)
Re: Electronic envelopes (Mok-Kong Shen)
Re: Electronic envelopes (Mok-Kong Shen)
books on discrete logarithm problem (Tom St Denis)
Re: Electronic envelopes ("Richard Parker")
Re: ECC97 Challenge Solved (Richard D. Latham)
Re: Electronic envelopes (Mok-Kong Shen)
Re: Please review proposed rebuttal... (Richard D. Latham)
Re: books on discrete logarithm problem ("karl malbrain")
Re: Electronic envelopes ("Richard Parker")
Re: Perfect Shuffle Algorithm? ("Douglas A. Gwyn")
Re: Comments on ECC ("Douglas A. Gwyn")
----------------------------------------------------------------------------
Date: Tue, 28 Sep 1999 14:27:19 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: simple algorithm for hardware device?
Volker Hetzer wrote:
> Trevor Jackson, III wrote:
> > There is _no_ encryption algorithm with a fixed key < ~ 1 megabit that
> > cannot be represented by such a code table. Fill the table by running
> > 97-DES if you want. It's not more secure.
> Wouldn't DES require a 64-Bit table (64 Bit address and 64 bit data)?
> You surely mean " There is _no_ 16 Bit encryption algorithm ...".
Yes, of course. Perhaps I should have made the statement more explicit, but I
thought the context was clear (that of filling in the previously defined 16-bit
table).
In theory you can codebook any encryption algorithm even OTP*. But any algorithm
for which codebooks are useful (16 bit words is marginal and 32-bit words probably
feasible but silly), the codebook technique is so much more powerful for the
Opponent than it is for the Communicator that it's a symptom of insecurity.
* Yes, a codebook implementation of OTP is really stupid. But in theory possible.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 18:21:16 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Could someone of the group kindly provide some pointers?
> I hope that these adequately take the time issue into account
> which is essential for the present scheme.
Helger Lipmaa <[EMAIL PROTECTED]> wrote:
> The next publication should give a state-of-the-art (AFAIK) overview
> of the subject:
>
> "Conditional Oblivious Transfer and Timed-Release Encryption", Giovanni
> Di Crescenzo (University of California San Diego), Rafail Ostrovsky, and
> Sivaramakrishnan Rajagopalan (Bellcore) , Eurocrypt 1998
I searched for this paper and found it at the following URLs:
<http://link.springer-ny.com/link/service/series/0558/tocs/t1592.htm>
<http://www.argreenhouse.com/papers/rafail/42.pdf>
The Crescenzo/Ostrovsky/Rajagopalan time-release protocol is superior
to the one I proposed earlier in this thread. The COR protocol has at
least two advantages:
Storage and computation is logarithmic in the size of the time
parameter instead of linear.
The protocol is valid even if the sender is malicious, since the
message can always be decrypted after the claimed release time.
The only advantage to my method is that, unlike the COR protocol, my
method does not require active communication between the notaries and
the clock.
Additional reading on my part has revealed that "my method" is, in
fact, the offline version of the time-release protocol proposed by
Rivest/Shamir/Wagner in the following paper:
"Time-lock puzzles and timed-release Crypto", Ronald L. Rivest, Adi
Shamir, and David A. Wagner, MIT/LCS/TR-684, February 1996
<http://theory.lcs.mit.edu/~rivest/RivestShamirWagner-timelock.ps>
-Richard
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Bit commitment via hash and coin flipping
Date: Tue, 28 Sep 1999 14:45:23 -0400
>
I did not read AC, so I don't know if this is in there, but here
is a Bit commitement scheme using hash functions:
Commitement:
1. Alice picks a random string s and computes v = h(s).
2. Alice computes c = h(s || b), where b is the bit she wants to commit to.
3. Alice gives (v,c) to Bob.
Revealing:
1. Alice gives s to Bob.
2. Bob verifies if, in fact, h(s) = v.
3. Bov verifies if in fact h(s || b) = c.
Alice would rely on the fact that given h(s) and h(s || b),
it is difficult to found s or b or both (if it was not hard,
we could find collisions easily)
It doen't matter, for Bob, if Alice picks a random s, it's
just safer for Alice to do so.
Bob is convinced that b is what Alice commited to for
the following reason: Say Alice wants to cheat, she
would need to find an s and s' such that she can give
h(s) = h(s') and h(s || b) = h(s' || b'), even with
pre-existing known collisions, this is very difficult.
Anton
------------------------------
Date: Tue, 28 Sep 1999 14:48:07 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: ECC97 Challenge Solved
Medical Electronics Lab wrote:
> Which has always been "obvious", but at least now there's some
> empirical evidence to back that up.
A parable about "obvious".
The new Professor starts his weekly math 856 seminar, the one with 11 nouns
and 29 adjectives in the title, by writing a short equation on the black
board. He then starts the lecture by pointing to the fomula and saying "It
is OBVIOUS that ...", whereupon he pauses, studies the formula for a while,
and walks out of the classroom. The students wait patiently, not wanting
to do anything that would risk their participation in the prestigious
class.
Thirty-five minutes later the professor returns, walks up to the podium and
resumes the lecture; " I was right. It is OBVIOUS that...."
;-)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEMA, Swiss cipher machine
Date: Tue, 28 Sep 1999 15:39:19 GMT
[EMAIL PROTECTED] wrote:
> that would mean that the wheel/rotor distinction does not exist in the
> original German, ...
Standard practice is that a "rotor" is a rotating component,
or an electrical analogue of one (e.g. a circular shift register),
and a "wired rotor" is an Enigma-like rotor.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Date: Tue, 28 Sep 1999 18:43:08 GMT
[EMAIL PROTECTED] wrote, in part:
>I was to write a routine that cuts a computer simulated deck and
>performs a perfect shuffle. A perfect shuffle, you cut the deck x cards
>from the top. Then the bottom card from the top stack deck goes down
>first, then the bottom card from the bottom of the deck on top of it,
>one at a time, until one of the stacks runs out, then the remaining
>cards go on top of the deck. I was to simulate this pretty easy in JAVA
>and it works fine. The question he had was if the deck was 1001 cards,
>and you cut from the top 102 cards, then perfect shuffled, how many
>times would you have to shuffle the deck to return it's to it's original
>order?
I think you'll get a lot of replies here which refer to another
shuffling algorithm entirely.
There was something about this kind of thing in an old Mathematical
Games column by Martin Gardner.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 14:56:12 -0400
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>You are right. I should have confined the goal a bit and made
>that explicit. I negected to say that the depositor trusts the
>notaries, i.e. they will dutifully do their job. The big problem is
>how the public can believe that there is no manipulation (even though
>the depositor has no doubt and there indeed is no manipulation.)
Now I am somewhat lost. Your original post said:
>It is not possible by anyone else than the sender to get the contents
>of the envelope before a predetermined time point without that act
>of manipulation be known
What, exactly, is the envelope supposed to prove?
If we are proving a claim of some sort of prophecy by the sender, then the
envelope must prove to the public that it has been sealed for some length of
time. This is not possible without the public trusting either the sender or
some kind of notary. But this can't be what you meant, because you said
that the sender is allowed to change the contents without telling anyone.
If we're trying to prove to the public that the contents have not been
disclosed before the appropriate time, then:
1) We must trust the sender not to disclose the information through
separate channels; and
2) We require some key to be communicated at the appropriate time by the
sender or a _publicly_ trusted notary.
If neither of these, then what?
Note that in both instances, the "notary" is any system that is trusted by
the public to hold some given information unrevealed for a pre-specified
length of time.
These scenarios require a notary in Today's paper systems as well, because
no common method of envelope sealing can be accurately dated.
Similarly, if noone is trusted to keep a secret, then any information that
could have been used to create an electronic envelope and its contents is
assumed to exist at all future times.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Bit commitment via hash and coin flipping
Date: 28 Sep 1999 19:11:10 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>> Basically, why wouldn't this work instead:
>>
>> (1) Alice generates on random-bit string R.
>> (2) Alice creates a message of (R,b)
>> (3) Alice computes and sends/publishes H(R,b).
>> To confirm:
>> (4) Alice sends/publishes (R,b).
>> (5) Bob computes H(R,b) and compares it to the original message.
>
> If only *one* collision (c_1, c_2) is known (with last bit of c_1 different
> from the last bit of c_2) your protocol does not work, since
> Alice could always choose b to be c_1 and cheat.
Well, if Alice can say "Teehee, I made a thinko and published H(b,R)
instead." then the protocol in AC won't work either since Alice can
say "I published H(R1,b,R2),R1 instead." No?
--
Sent via USENET
Learn what you know. Share what you don't. -- [EMAIL PROTECTED]
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Date: Tue, 28 Sep 1999 21:22:30 +0200
> what does this have to
> do with crypto. <plonk - killfiled>
>
> Post follow ups to dev/null.
Well, do you know this nice book?
"Magic tricks, card shuffling and dynamic computer memories"
by S. Brent Morris (NSA)
MAA, 1998.
see http://www.maa.org/pubs/books/cards.html
link with crypto is immediate (see our paper at CRYPTO 83 :-)
Jean-Jacques Quisquater,
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Exclusive Or (XOR) Knapsacks
Date: Tue, 28 Sep 1999 15:27:14 -0400
[sorry, lost the original poster]
>Exclusive Or (XOR) Knapsacks
>
>Problem:
>Given an n bit number X and a set {B1,B2,...,Bn} of n bit numbers;is there
a
>subset whose elements collectively XORed give X?
>
>Can the general problem be solved easily?
Yes. The problem is a simple system of linear equations with coefficients
in GF(2)
Let me just make up an example:
1010 = B1
0101 = B2
1001 = B3
1101 = B4
so:
isolate 4th bit
1010 = B1
0101 = B2
0011 = B3 +B1
0111 = B4 +B1
3rd bit
1010 = B1
0101 = B2
0011 = B1+B3
0010 = B1+B4 +B2
2nd bit
1001 = B1 +(B1+B3) = B3
0101 = B2
0011 = B1+B3
0001 = B1+B2+B4 +(B1+B3) = B2+B3+B4
1st bit
1000 = B3 +(B2+B3+B4) = B2+B4
0100 = B2 +(B2+B3+B4) = B3+B4
0010 = B1+B3 +(B2+B3+B4) = B1+B2+B4
0001 = B2+B3+B4
So, for any 4 bit X...
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: ECC97 Challenge Solved
Date: Tue, 28 Sep 1999 19:29:38 GMT
In article <[EMAIL PROTECTED]>,
"Sam Simpson" <[EMAIL PROTECTED]> wrote:
> http://www.certicom.com/press/99/sept2899.htm
>
> It is interesting to note that this challenge took ~16,000 MIPS-years
> whilst an 512-bit RSA key took ~8,000 MIPS-years.
>
> Any comments on the press release?
One point, taking 16000 mips-years while quite a long time does not PROVE
there is no other method to solve ECC. It does seem impressive that a key 5
times smaller takes 2 twice as long to solve though.
Hey any good ECC books for beginners? (or so)? I think I should learn more
about it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 19:23:52 +0200
Anton Stiglic wrote:
>
> The sole fact that you use time is enough to say that
> it can't work. Time is relative, you would need a trusted
> central unit that would give you the exact time. If you have
> a trusted central unit (authority) U, Alice and Bob could just
> agree with U about the time U is to reveal the ciphertext to Bob.
>
> It isn't more complicated than that!
Is Alice the depositor of the document in your scenario? I guess
yes. Probably I hadn't been very explicit. But the last sentence
of my original post implies that the depositor is no longer
available for anything connected to the matter after deposition of
the envelope. In your scenario it could be that Alice is no longer
alive at the predetermined time point of secret disclosure.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 19:24:01 +0200
Richard Parker wrote:
>
> The Crescenzo/Ostrovsky/Rajagopalan time-release protocol is superior
> to the one I proposed earlier in this thread. The COR protocol has at
> least two advantages:
>
> Storage and computation is logarithmic in the size of the time
> parameter instead of linear.
>
> The protocol is valid even if the sender is malicious, since the
> message can always be decrypted after the claimed release time.
Would you please say whether this means it can be ensured that the
message can be decrypted exactly at time point T and not before T and
this is entirely independent of computing resources available? If
yes, my problem is solved.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: books on discrete logarithm problem
Date: Tue, 28 Sep 1999 19:40:06 GMT
Are there any books (under 50 us dollars) still in print (preferably recent)
that cover the discrete logarithm problem? I want something that includes
1) description of the various applicable moduli (2^n, p^n, p)
2) description of what a primitive generator is
3) any information on current sovling algorithms
Any online descriptions would be nice as well.
Thanks,
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 19:55:46 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Richard Parker wrote:
>> Assume the existence of trusted clock. The trusted clock generates a
>> set of public-key/private-key key pairs. The clock publishes the
>> public keys along with a time at which the corresponding private key
>> will be announced for each public key. The clock guarantees that it
>> will only release a private key at that time.
>
> This is not a bad idea. However, it assumes that there is a central
> agent that is trusted by all people and that that agent never fails
> (because of political events, etc.) and probably also some minor
> technical issues.
The trust placed in the clock can be relaxed by having multiple clocks
and dividing the keys among them using a threshold secret-sharing
scheme. This would protect the system against the failure, or
compromise, of individual clocks.
-Richard
------------------------------
From: [EMAIL PROTECTED] (Richard D. Latham)
Subject: Re: ECC97 Challenge Solved
Date: 28 Sep 1999 14:59:57 -0500
[EMAIL PROTECTED] (Jerry Coffin) writes:
[ deletia ]
>
> As far as cryptography itself goes: I found it interesting that not
> only one, but in fact TWO pairs of points were found in FAR less time
> than was predicted. The obvious conclusion is that this is simply a
> fluke, but it's possible that the algorithm is more likely to find
> matching points than we realize. If the latter is true (unlikely
> though it seems right now) it could have real implications on the key
> sizes needed for security with ECC.
>
Interesting isn't quite the word that came to mind :-)
"One chance in a hundred" was alluded to in one of the press releases.
Finding one pair ten times faster than expected might be chalked up
to "just chance", but finding the second pair almost immediately
afterwards would probably make a "card carrying Bayensian" consider
whether it isn't time to begin scruntinizing his prior :-)
--
#include <disclaimer.std> /* I don't speak for IBM ... */
/* Heck, I don't even speak for myself */
/* Don't believe me ? Ask my wife :-) */
Richard D. Latham [EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 20:01:51 +0200
Matt Timmermans wrote:
>
> What, exactly, is the envelope supposed to prove?
>
> If we are proving a claim of some sort of prophecy by the sender, then the
> envelope must prove to the public that it has been sealed for some length of
> time. This is not possible without the public trusting either the sender or
> some kind of notary. But this can't be what you meant, because you said
> that the sender is allowed to change the contents without telling anyone.
>
> If we're trying to prove to the public that the contents have not been
> disclosed before the appropriate time, then:
>
> 1) We must trust the sender not to disclose the information through
> separate channels; and
>
> 2) We require some key to be communicated at the appropriate time by the
> sender or a _publicly_ trusted notary.
>
> If neither of these, then what?
If taken 'exactly' by the 'word', one could argue that nothing
in this world can be absolutely proved. Assuming we are not taking
that pedantic position, there can be cases that it is evident that
the depositor indeed wants to keep his secret (message) till a
certain time point T and discloses it exactly at T. This means in
other words he doesn't cheat the public and secretly discloses the
secret to somebody before T. It could be something he desires
to get done at sometime where he is no longer alive in all probability.
So (1) doesn't apply and (2) also, because the depositor is not
available and the notar is not assumed to be trusted by everyone
interested in the matter. (Anyway I, for one, wouldn't trust an
unknown notar simply by his name, in case the secret involves a
financial value of several billions of dollars.)
> These scenarios require a notary in Today's paper systems as well, because
> no common method of envelope sealing can be accurately dated.
There is of course no absolute security. In the case of convential
envelopes, one can seal it such that illegal opening can be detected
(with high probability) by experts specilized in crimes. (Compare
signatures on cheques.) On electronic media there is no equivalent
of that as far as my current knowledge goes. The opening can be
a public session where the notar arranges to have the presence
of necessary persons to testify the act of opening and the contents
of the envelope.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Richard D. Latham)
Subject: Re: Please review proposed rebuttal...
Date: 28 Sep 1999 15:27:45 -0500
Bob Silverman <[EMAIL PROTECTED]> writes:
> In article <7spki3$hdo$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Bill Unruh) wrote:
> > In <[EMAIL PROTECTED]> "me" <[EMAIL PROTECTED]> writes:
>
> <snip>
>
> > Sorry. Too many problems.
> >
> > What has been shown is that 512 bit key (any organisation's
> > 512 bit key) is breakable with modest resources (modest for a
> reasonable sized organisation).
>
> One needs a very large Cray-class machine to deal with the matrix.
> (fairly big bucks, i.e. $5-10 Million)
>
> Might I ask if you either:
>
> (a) forgot about this requirement. (no flame intended)
> (b) consider it a 'modest' resource?
>
> I have all the resources (and code!) to break a 512-bit key EXCEPT
> for dealing with the matrix in reasonable time. And I would consider
> RSA Security as a 'reasonable sized' organization.
>
A very interesting practical point.
It doesn't appear that the current best-known approach to ECDL
requires access to a "limited resource" of this class. Doesn't this
call into question the assertions of (mumble mumble) that ECDL is
"more secure" than RSA.
As a untutored layman, I had thought that most people considered this
"large machine" requirement at the end of the factoring process, which
apparently isn't amenable to a distributed effort, to be the "real
ceiling" in attacking RSA.
I mean, I'll have twice as many MIPs at my disposal in 18 months or
so, just by standing around and doing nothing ... I'm not ever likely
to have a Cray-class machine lying around idle.
--
#include <disclaimer.std> /* I don't speak for IBM ... */
/* Heck, I don't even speak for myself */
/* Don't believe me ? Ask my wife :-) */
Richard D. Latham [EMAIL PROTECTED]
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: books on discrete logarithm problem
Date: Tue, 28 Sep 1999 13:58:01 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:7sr5ik$m26$[EMAIL PROTECTED]...
> Are there any books (under 50 us dollars) still in print (preferably
recent)
> that cover the discrete logarithm problem? I want something that includes
Why don't you try KNUTH's Concrete Mathematics first. Karl M
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 20:55:03 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Would you please say whether this means it can be ensured that the
> message can be decrypted exactly at time point T and not before T and
> this is entirely independent of computing resources available?
Hmmm. Well, the Crescenzo/Ostrovsky/Rajagopalan time-release protocol
allows time to be specified with whatever granularity is required.
The message can be decrypted by the receiver if and only if the time
is not earlier than the release-time T. Note that technically the
method I proposed also allows time to be specified with arbitrary
granularity, but the COR time-release protocol is much more practical
if you want to specify the release-time with a fine granularity.
As to being "entirely independent of computing resources available"
the answer is no. However, the requirements are modest. The paper
provides the following estimates for the interaction between the time
server and the message receiver:
n - size of public key
k - number of bits to encode time
t - soundness parameter for the non-interactive zero-knowledge proof
computational complexity: 8nk modular products
communication complexity: 12nk + n log t
storage complexity: 6n + n log t
Also, I should note that the security of the protocol relies on
public-key encryption and the hardness of deciding quadratic
residuosity modulo Blum integers.
-Richard
------------------------------
Crossposted-To: sci.stat.math,sci.math
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Perfect Shuffle Algorithm?
Date: Tue, 28 Sep 1999 17:29:27 GMT
Dr D F Holt wrote:
> The easiest approach, which would certainly solve the problem fast, is
> to program the case of finding the order of an arbitrary permutation of the
> set {1,2,3,...,n} (in your case n=1001). Just write the permutation in
> cycles, and then the order is the least common multiple of the cycle
> lengths.
Yes, that is workable; nice answer! So the program sought would
simulate the shuffle only once, to build the permutation (not
hard), then would decompose the perm. into cycles (not hard),
then find the LCM of the cycle lengths (not hard). Perhaps the
interviewer's purpose was to probe the applicant's experience in
working with things very like this. In which case, turning to
the net means he has not met the criteria.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Comments on ECC
Date: Tue, 28 Sep 1999 17:31:01 GMT
Patrick Juola wrote:
> If you assume that we know, for whatever reason, that P=NP, then
> that knowledge will *give* us the algorithm we need.
No, it won't. Suppose I tell you that P=NP and for some
reason you believe that I have a proof. Now, how does that
suddenly produce any algorithm that you didn't already know
how to produce? It doesn't.
------------------------------
** 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
******************************
