Cryptography-Digest Digest #822, Volume #11 Fri, 19 May 00 17:13:01 EDT
Contents:
Re: Interpretation of Hitachi patent claims (Roger Schlafly)
Re: About AES contest (DJohn37050)
Re: Introduction to zero knowledge proofs? (David A Molnar)
AES contest (DJohn37050)
Re: About AES contest ("Douglas A. Gwyn")
Re: Interpretation of Hitachi patent claims (Richard Heathfield)
Re: what is the status finite automata base cryptosystems? ("Douglas A. Gwyn")
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
ZKPs in practice? (David A Molnar)
Patent state of Elliptic Curve PK systems? (Frank M. Siegert)
Re: Q: Recording on magnetic cards (Mok-Kong Shen)
Re: Interpretation of Hitachi patent claims (Mok-Kong Shen)
On-line authentication protocol (Richard Heathfield)
Re: More on Pi and randomness (Tim Tyler)
Re: More on Pi and randomness (Richard Heathfield)
Re: More on Pi and randomness (Mike Mccarty Sr)
----------------------------------------------------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Fri, 19 May 2000 11:23:05 -0700
Mok-Kong Shen wrote:
> 1. In German there are authors who are fond of writing
> exceedingly long sentences, with one sentence for a
> paragraph. I have however NEVER seen such in English
> before. Maybe the lengthy sentences in the patents are
> there because they are of Japanese origin?? I conjecture
> that the patent reviewer in the US Patent Office probably
> hasn't himself fully understood what has passed through
> his hands.
A US patent claim must be a single sentence.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: About AES contest
Date: 19 May 2000 18:59:01 GMT
Read the MARS summary report and the comments by Meyer in the big file.
For example, they claim their design is best when considered from an "unknown
future" perspective, for example, if variable rotations should prove to be
weaker than now thought for some reason.
Don Johnson
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Introduction to zero knowledge proofs?
Date: 19 May 2000 18:55:18 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
>> Hi!
>> Is there any good introduction on zero knowledge
>> proofs out there?
> simulate a protocol shows it is zero-knowledge, and gives some sample
> zero-knowledge protocols (I think graph non-isomorphism and 3-coloring?).
Found my copy of Koblitz -- it's actually 3-coloring and posession of
discrete logarithm. I think Stinson's book also covers the topic,
but I don't have it with me and so can't comment on it.
I found this thesis online :
http://home.earthlink.net/~jones21/thesis/thesis.html
This is notable because it includes source code for implementing
zero-knowledge proofs.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: AES contest
Date: 19 May 2000 19:01:34 GMT
Also, i think the MARS designers did not promote their algorithm to the extent
that some others have.
Don Johnson
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: About AES contest
Date: Fri, 19 May 2000 19:05:53 GMT
Karim A wrote:
> I wonder myself, which is the best algorithm ?
Such a simplistic question cannot be answered.
> And which algo will be selected ?
Wait and see.
> Sure, you've already implemented one of them on your machine,
> and according to you, which algo is the best in terms of security,
> fast encryption, and easy software and hardware implementations.
There are reports on all these things on the NIST Web site.
Note that mere implementation and use doesn't usually tell
one anything about the system's security.
------------------------------
Date: Fri, 19 May 2000 20:14:20 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Mok-Kong Shen wrote:
>
> The two claims of Hitachi are in the attachment below.
> I hope that some native English speaker of our group
> would kindly translate the material into concise and clearly
> comprehensible mathematical form to enable concrete and
> precise discussions on the issue.
Well, I'm not a mathematician /or/ a cryptographer, so naturally I'm the
ideal person to have a go at translating it into something
comprehensible. I am a native English speaker, however, but I'll try not
to let that influence me too much...
> USP5,103,479 claims:
>
> "Claim 1. An enciphering method for converting a pair of plain
> text data into a pair of ciphertext data by sequentially
Firstly, a pair of plaintext data is simply a bunch of data. There is
nothing particularly unique in treating two bits or two bytes as a
single entity. The only way this makes sense *to me* is if one of the
data items is plaintext and the other is a key.
> performing a plurality of encipherment processes on said pair
> of plaintext data, each of encipherment processes having a
> function to restore a pair of ciphered text data to a pair of
> former text data if each of said encipherment processes is
> performed again on said pair of ciphered text data, comprising
So E(E(P)) = P. Odd, that. I suppose a one-time pad fits this
description, as does a Vigenere cipher.
> the steps of: performing a first encipherment process for
> deriving a first pair of data from said pair of plain text
> data;
Something like:
I1 = (P1 + K1) % 256
I2 = (256 + P1 - K1) % 256
giving us a first intermediate pair of bytes ('I' being an intermediate
byte).
> performing a second encipherment process for deriving a
> second pair of data from said first pair of data by circular
> shifting of first intermediate data derived from one of said
> first pair of data by a first predetermined number of bits;
I think this means
I3 = I1 <<< r1
I4 = I2 <<< r1
Ah, bit rotation. I invented this technique all by myself, even though
I'm not a cryptographer (before I started reading sci.crypt), so it must
surely count as being obvious. Don't patents have to cover non-obvious
processes?
Anyway, Enigma uses the algorithmic equivalent of bit rotation, doesn't
it?
> performing a third encipherment process for deriving a third
> pair of data from said second pair of data by circular
> shifting of second intermediate data derived from one of said
> second pair of data by a second predetermined number of bits
> which are different from said first predetermined number of
> bits;
I5 = I3 <<< r2
I6 = I4 <<< r2
> and performing a fourth encipherment process or other
> encipherment processes by deriving said pair of ciphertext
> data from said third pair of data."
Perhaps C = I5 ^ I6 or some other operation which combines them. Then go
round again for the next byte of plaintext. Whether using the same r1
and r2 or a different set of rotation values isn't clear to me from the
text.
>
> "Claim 10. A method of generating code data by executing a
> plurality of arithmetical processes on message data,
> comprising the steps of: performing a first process for
> generating first intermediate data by arithmetically operating
> on second intermediate data derived from initial data having
> a predetermined bit pattern and a first portion of said
> message data;
This seems ludicrous. It seems to be saying: get your first intermediate
value by taking your /second/ intermediate value and munging it.
> performing a second process for generating third
> intermediate data by circular shifting of said first
> intermediate data by a first predetermined number of bits;
Bit rotation again.
> performing a third process for generating fourth intermediate
> data by arithmetically operating on fifth intermediate data
> derived from said third intermediate data and a second portion
> of said message data; performing a fourth process for
> generating sixth intermediate data by circular shifting of
> said fourth intermediate data by a second predetermined number
> of bits which is different from said first predetermined
> number of bits; performing a fifth process for generating
> seventh intermediate data by arithmetically operating on said
> sixth intermediate data and a third portion of said message
> data; performing a sixth process for generating eighth
> intermediate data by circular shifting of said seventh
> intermediate data by a third predetermined number of bits
> which is different from said second predetermined number of
> bits and by arithmetically operating on said eighth
> intermediate data, said seventh intermediate data, and said
> fourth intermediate data; and performing a seventh process
> generating said code data by arithmetically operating on
> said eighth intermediate data."
This really is extremely badly written. It's most unclear what's being
said. The best interpretation I can put on it is that the algorithm
consists primarily of many bit rotations by different amounts,
presumably with key XORing mixed up in it too.
Since I was capable of discovering this for myself, all by myself (with
the minor twist that I rotate the whole buffer by a varying number of
bits on each round, rather than each byte of the plaintext by a
different amount, which is presumably different again on each round) one
afternoon late last year when I was bored at work, I can't fathom why
Hitachi seem to think they're onto something non-obvious.
Perhaps this application was submitted on April 1. It's the only
rational explanation I can think of. Unless I've completely
misunderstood it, of course, in which case it's not clear enough to be
useful IMHO.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
to go)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what is the status finite automata base cryptosystems?
Date: Fri, 19 May 2000 19:18:26 GMT
Christopher Pollett wrote:
> > > Can anyone out there tell me what the current status of finite
> > > automata based crypto systems?
> Hi I mean the systems first developed in China by Renji Tao.
It has apparently been implemented in Tongli Telecommunication Co.,
Ltd.s' "InfoSec-I". Unfortunately, most of Renji Tao's technical
papers are in Chinese, which undoubtedly has limited their impact.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Fri, 19 May 2000 21:39:28 +0200
Roger Schlafly wrote:
> A US patent claim must be a single sentence.
Ground enough to have reforms, or developments.
M. K. Shen
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: ZKPs in practice?
Date: 19 May 2000 19:05:39 GMT
Hi,
The recent question on "an introduction to zero-knowledge proofs"
had me thinking : where have zero-knowledge proofs been implemented
in the real world?
The most prevalent use I can think of for ZKPs is in the Fiat-Shamir
and GQ (and GQ2) type signature schemes used for smart cards.
Following on that, password authentication protocols like SPEKE,
SRP, SNAPI, and PAK.
Then I seem to recall that there are implementations of contract
signing protocols around (not publically available, though?) which
make use of ZKPs.
What else? Has anyone implemented and deployed ZKP-based voting schemes,
for example?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Patent state of Elliptic Curve PK systems?
Date: Fri, 19 May 2000 19:50:43 GMT
I am just thinking about integrating a form of public key encryption
in one of my software products, however I would like to be free of any
patent problems. So if I should build in a form of elliptic curve PK
system will I stumble into the deep waters of the sea of patents?
Another related question: I search the web for references of the FAPKC
PK system but found not much except references to chinese research
papers - has anyone done some more work on these, preferable written
in Engish or German?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Recording on magnetic cards
Date: Fri, 19 May 2000 22:31:56 +0200
Francois Grieu wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > It seems that the orientation of the card relative to the apparatus
> > is also immaterial.
>
> If the card is indeed a magnetic card, it is not sensitive to magnetic
> fields that remain below some threshold depending on the hysteresis
> and coercitivity of the magnetic material. Writing occurs by generating
> a strong but very local field that goes over this threshold, again
> with a range like 0.1mm.
>
> If there is no close physical contact with some form of sliding
> between the card and reader, then it is not a magnetic card.
> Maybe a contactless IC Card, where induction between a coil in the
> reader and a coil in the card is used to communicate, and possibly
> power the card. ISO 14443 is/will be a standard for such cards.
It is a plastic card with at the back a black strip, just like my bank
card or my Eurocard. There is apparently no chip on it. If such a
card is put together with the bank cards, a writing operation on
on it should have some effects on the others, shouldn't it?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Interpretation of Hitachi patent claims
Date: Fri, 19 May 2000 22:31:48 +0200
Richard Heathfield wrote:
> [snip]
> Something like:
>
> I1 = (P1 + K1) % 256
> I2 = (256 + P1 - K1) % 256
[snip]
> I3 = I1 <<< r1
> I4 = I2 <<< r1
[snip]
> I5 = I3 <<< r2
> I6 = I4 <<< r2
[snip]
> Perhaps C = I5 ^ I6 or some other operation which combines them. Then go
> round again for the next byte of plaintext. Whether using the same r1
> and r2 or a different set of rotation values isn't clear to me from the
> text.
I think that there are two point that could be discussed:
1. If one deviates from the scheme above, say, not having two values
to be rotated, but one or three, then the claim could be considered
not applicable.
2. Doesn't 'predetermined' mean something fixed once and for all by
the chosen key and kept constant for all blocks? If yes, then use
of a dynamic value wouldn't be covered by the patent.
> > "Claim 10. A method of generating code data by executing a
> > plurality of arithmetical processes on message data,
> > comprising the steps of: performing a first process for
> > generating first intermediate data by arithmetically operating
> > on second intermediate data derived from initial data having
> > a predetermined bit pattern and a first portion of said
> > message data;
>
> This seems ludicrous. It seems to be saying: get your first intermediate
> value by taking your /second/ intermediate value and munging it.
I have the same impression. So the passage is ambigious and the patent
claim would be invalid. Further, it is not stated at all what kind of
process the 'first process' exactly is. One couldn't give patent to
some 'process' that is not clearly defined in a fixed and narrow domain!
> > performing a second process for generating third
> > intermediate data by circular shifting of said first
> > intermediate data by a first predetermined number of bits;
>
> Bit rotation again.
>
> > performing a third process for generating fourth intermediate
> > data by arithmetically operating on fifth intermediate data
> > derived from said third intermediate data and a second portion
> > of said message data; performing a fourth process for
> > generating sixth intermediate data by circular shifting of
> > said fourth intermediate data by a second predetermined number
> > of bits which is different from said first predetermined
> > number of bits; performing a fifth process for generating
> > seventh intermediate data by arithmetically operating on said
> > sixth intermediate data and a third portion of said message
> > data; performing a sixth process for generating eighth
> > intermediate data by circular shifting of said seventh
> > intermediate data by a third predetermined number of bits
> > which is different from said second predetermined number of
> > bits and by arithmetically operating on said eighth
> > intermediate data, said seventh intermediate data, and said
> > fourth intermediate data; and performing a seventh process
> > generating said code data by arithmetically operating on
> > said eighth intermediate data."
>
> This really is extremely badly written. It's most unclear what's being
> said. The best interpretation I can put on it is that the algorithm
> consists primarily of many bit rotations by different amounts,
> presumably with key XORing mixed up in it too.
>
> Since I was capable of discovering this for myself, all by myself (with
> the minor twist that I rotate the whole buffer by a varying number of
> bits on each round, rather than each byte of the plaintext by a
> different amount, which is presumably different again on each round) one
> afternoon late last year when I was bored at work, I can't fathom why
> Hitachi seem to think they're onto something non-obvious.
>
> Perhaps this application was submitted on April 1. It's the only
> rational explanation I can think of. Unless I've completely
> misunderstood it, of course, in which case it's not clear enough to be
> useful IMHO.
I was totally unable to 'decipher' the last portion above, even though
I normally have little difficulty to read very long sentences in German
books and even occasionally write some such in private
communications. I am relieved that my performance here was not
too much worse than a native English speaker. So again the claim is
unclear and ambigious and hence invalid. That there is no novelty
in rotation is, I believe, extremely clear to everyone of our group
and to everyone in computer science.
I very much wonder what the patent experts in NIST, IBM and
RSA have to say to the same stuff. Or maybe they are shy of saying
anything because the quality of other patents which they have
submitted themselves are in no single point better and hence are
subject to potential demolitions in exactly the same way?? (I
mentioned previously the proverb 'One hand washes the other'.)
M. K. Shen
=======================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
Date: Fri, 19 May 2000 21:20:50 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: On-line authentication protocol
I would welcome your views on the following authentication protocol,
which I and a work colleague designed, and which incorporates at least
one idea garnered from sci.crypt :-) - I hope to use this protocol if it
stands up to scrutiny; my interest is not just theoretical.
Comments?
Requirement:
Client wishes to talk to server.
Client must know that he's talking to the *right* server, not an
impostor.
Server must be assured of client's identity.
+++
Threat model:
Spotty but clever teenager with an attitude and a packet sniffer.
+++
Legend: S = Server C = Client pK = private Key PK = Public Key DHK =
Diffie-Hellman Key
Diffie-Hellman: N = (Y^X) % P (SN = N generated by server, CN = N
generated by client)
Thus, SPK(T) means that T has been encrypted using the server's public
key.
+++
Protocol overview:
Client Server
1. -> "Hello" (in clear) ->
2. <- Y, P, SN <-
3. -> CN, DHK("Dave") ->
4. <- DHK(CPK(SpK(Random session ID 1))) <-
5. -> DHK(SPK(CpK(Session ID 1,
Session ID 2))) ->
6. <- DHK(CPK(SpK(Session ID 2,
New Y, P, SN))) <-
7. -> DHK(SPK(CpK(N, Session IDs,
First productive message))) ->
8. <- DHK2(Session IDs,
First productive response) <-
9. -> DHK2(Session IDs, second message) ->
+++
Protocol detail:
1. -> "Hello" (in clear) ->
Client informs server that he wants to establish a connection. No
security or authentication at this stage.
2. <- Y, P, SN <-
Server picks an X, and responds with the three elements the client needs
for Diffie-Hellman. (Server pre-calculates its own N, which it can do
independently.)
3. -> CN, DHK("Dave") ->
Client picks an X, works out the Diffie-Hellman key, encrypts his
identification, and sends it to the server, together with unencrypted N.
4. <- DHK(CPK(SpK(Random session ID 1))) <-
Now the server wishes to authenticate that this really is Dave, not an
impostor or a replay attack. Server picks a random session ID. (Yes, I
know random number generation is an issue for heavy NSA-type threat
models...), encrypts with its private key, as a digital signature, then
encrypts with "Dave"'s public key, then encrypts with the session key
already established. Note: If Dave is not known to the server, it will
pick a completely random public key for the encryption, to avoid leaking
information about user names unnecessarily.
5. -> DHK(SPK(CpK(Session ID 1,
Session ID 2))) ->
Client retrieves session ID by applying DHK, CpK, and SPK. Client now
re-encrypts Session ID 1 using CpK, SPK, and finally DHK. If the client
does this successfully, the server can be reasonably assured that he's
talking to Dave.
The client also includes its own randomly-generated session ID, so that
the client can authenticate the server.
6. <- DHK(CPK(SpK(Session ID 2,
New Y, P, SN))) <-
Server works out the client's session ID, and sends it back to the
client, together with a new Y, P and SN for a new Diffie-Hellman key.
Client can now authenticate the server.
7. -> DHK(SPK(CpK(N, Session IDs,
First productive message))) ->
The client works out the key, sends back its N, both session IDs, and
the first payload message.
8. <- DHK2(Session IDs,
First productive response) <-
>From now on, the private/public key encryption can be dropped, provided
both the session IDs are included in every message for the duration of
that session.
9. -> DHK2(Session IDs, second message) ->
Identification is now authenticated in both directions.
+++
Analysis:
Well, I already found a bug (client wasn't authenticating server) which
I've fixed.
I know the random number generation is a theoretical weakness, and I
know the encryption algorithm used for the outer Diffie-Hellman wrapper
is an unknown factor - let's assume for the moment that it's a good
strong algorithm.
I would welcome comments from the clueful on the security of the actual
protocol.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
to go)
------------------------------
Crossposted-To: sci.math
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: More on Pi and randomness
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 May 2000 20:05:02 GMT
In sci.crypt Mike Mccarty Sr <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
: )In sci.crypt JCA <[EMAIL PROTECTED]> wrote:
: ): If I tell you the decimal in position N in the expansion of Pi
: ): you won't be able to tell me anything about the following decimal
: ): sequence short of doing the computation yourself.
: )
: )Even if you *don't* tell me N, it's still possible to make positive
: )statements about the sequence. This was discussed on the other thread:
: )according to mathmaticians, PI doesn't behave randomly.
: This is not something which can be said with our current level of
: knowledge of PI. We can make statements about the first x billion
: digits, but we cannot (as yet) make statements about PI.
So you say. However, you may want to look at the section entitled:
``Are the digits of pi random (i.e., can you make money betting on
them)?''
In the document at:
http://alabanza.com/kabacoff/Inter-Links/fun/puzzles/probability
To summarise the relevant bit:
``A theorem of Mahler (1953) states that [...] pi cannot have a rational
approximation that is extremely tight.
Now suppose that the computer picks position N. I know that the next
41 * N digits cannot be all zero. For if they were, then the first N
digits, treated as a fraction with denominator 10^N, satisfies:
|pi - p / 10^N| < 10^(-42 N)
which contradicts Mahler's theorem.''
It seems that mathematicians can - and indeed have - made statements about
PI's systematic deviations from statistical randomness.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ UART what UEAT.
------------------------------
Date: Fri, 19 May 2000 21:45:38 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Mike Mccarty Sr wrote:
>
> In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
> )In sci.crypt JCA <[EMAIL PROTECTED]> wrote:
> )
> ): If I tell you the decimal in position N in the expansion of Pi
> ): you won't be able to tell me anything about the following decimal
> ): sequence short of doing the computation yourself.
(This is probably true for decimal digits, but not for hexadecimal - er
- hexits.)
> )
> )Even if you *don't* tell me N, it's still possible to make positive
> )statements about the sequence. This was discussed on the other thread:
> )according to mathmaticians, PI doesn't behave randomly.
>
> This is not something which can be said with our current level of
> knowledge of PI. We can make statements about the first x billion
> digits, but we cannot (as yet) make statements about PI.
I understand the Nth hexit of pi, irrespective of the value of N, to be
calculable using the equation derived by Borwein, Borwein and Plouffe.
The 400 billionth hexit of pi has been thus calculated.
(I seem to have switched sides in this debate. :-) )
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
37 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (60
to go)
------------------------------
From: [EMAIL PROTECTED] (Mike Mccarty Sr)
Crossposted-To: sci.math
Subject: Re: More on Pi and randomness
Date: 19 May 2000 20:34:03 GMT
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
)Mike Mccarty Sr wrote:
)> This is not something which can be said with our current level of
)> knowledge of PI. We can make statements about the first x billion
)> digits, but we cannot (as yet) make statements about PI.
)
)Sure we can; the transcendental real number universally denoted
)by the symbol pi has a great many exact properties that are
)mathematically proven.
You took my statement out of context. The context is whether PI be
normal in some base.
WHY DO PEOPLE LIKE YOU POST SUCH ANNOYING DRIVEL TAKING PEOPLE'S
STATEMENTS OUT OF CONTEXT LIKE THIS?
Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
** 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
******************************
