Cryptography-Digest Digest #456, Volume #11      Fri, 31 Mar 00 16:13:02 EST

Contents:
  Re: The NSA's little NCSC bots (Remove NO_SPAM to reply)
  GCHQ ("Gavin")
  Re: new Echelon article (JimD)
  general questions on SSL certificates ([EMAIL PROTECTED])
  Re: general questions on SSL certificates (mark carroll)
  Re: LFSR's (Christof Paar)
  Re: GCHQ (Remove NO_SPAM to reply)
  Re: Chronometric Cryptography ("Joseph Ashwood")
  Re: general questions on SSL certificates (Larry Kilgallen)
  Re: Coderpunks Query on Teledyne Crypto (Mok-Kong Shen)
  Re: Is it really NSA ?! (Arthur Dardia)
  Re: Chronometric Cryptography (Bill Unruh)
  Re: general questions on SSL certificates (mark carroll)
  Proof of Identity (Tom St Denis)
  Re: general questions on SSL certificates (Anne & Lynn Wheeler)
  Re: Legal Opinion advises use of steganographic filesytems in UK (Paul Koning)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Subject: Re: The NSA's little NCSC bots
Reply-to: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Date: Fri, 31 Mar 2000 18:10:35 GMT

Richard Herring <[EMAIL PROTECTED]> wrote:
> In article <UWKE4.4592$[EMAIL PROTECTED]>, Remove NO_SPAM to reply 
>([EMAIL PROTECTED]) wrote:

>> They may do a combination of bots and humans.  In my case (actually,
>> cases) it was humans.  How do I know?  Because they didn't follow
>> every link, because they clicked only on links that one would expect
>> them to be interested in, because they took up to a minute to go from
>> one page to the next.....

> Don't be too sure.  I think we can safely assume that they have 
> heard of the Turing test :-)

Possibly, but they took it pretty far then.  Because they came back the
next day from a different IP and clicked on some of the other links.

(Of course, that just what they _wanted_ me to think!  In reality, it
was aliens who suggested that they do that to further confuse me.  They
knew I would check to see if they returned, of course, since they have
those little mind-reading devices on the alien ship.)

Damian Menscher
-- 
--==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==--
--==## <[EMAIL PROTECTED]> www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==--
--==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==--

------------------------------

From: "Gavin" <[EMAIL PROTECTED]>
Subject: GCHQ
Date: Fri, 31 Mar 2000 19:20:43 +0100

Anyone cracked the code relating to the challenge on the GCHQ website ? I
have found the five hidden parts of the message, which when put together
would make a message if you changed  the two occurences of one particular
letter to another letter. However, I think there is more to it than them
just making a mistake on the website. Any ideas ?



------------------------------

From: [EMAIL PROTECTED] (JimD)
Subject: Re: new Echelon article
Reply-To: JimD
Date: Fri, 31 Mar 2000 17:37:15 GMT

On Fri, 31 Mar 2000 07:07:53 GMT, [EMAIL PROTECTED]=NOSPAM (Arturo) wrote:

>On Thu, 30 Mar 2000 17:36:56 GMT, [EMAIL PROTECTED] (JimD)
>wrote:
>
>>On Thu, 30 Mar 2000 13:34:48 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
>>wrote:
>>
>>I don't understand it either. It isn't at all easy to intercept a
>>mobile 'phone off the air. It's encrypted and it moves around.
>
>       For what I heard, it�s not so difficult to scan mobile phones inside
>one "cell" (I don�t know the exact procedure, but it seems like it can be
>done with a laptop computer).  As for the encryption, it is computationally
>equivalent to 40 bits (or less), well within reach of anybody with a
>medium-size computer.  You save the transmission and then decrypt it
>on-line, or you can even decrypt in real time if you have enough computing
>power.

You'd need a hell of a lot of computing power to store a 10-minute call.

>>Here in democratic bloody Britain, where they tap 'phone lines at
>>will without judicial authority, it would be very much easier for
>>them to order a tap the landline side. 
>
>       Yes.  But that needs a court order.

Not here it doesn't!

> Eavesdropping means nobody cares about asking for permission.

Indeed. But you have two hurdles to jump: firstly it isn't audio,
it's fast digitised audio, then it's encrypted. Not really for the
hobbyist - not in real-time.

>>This may (probably) cause
>>them a problem with mobile-mobile. There may also be problems with
>>calls _to_ a mobile 'phone.
>
>       Not really.  They need merely install tapping ports at the receiving
>cells, or somewhere else in the system.

Yes, but the mobile's location may not be known until it's too late.

-- 
Jim Dunnett.
dynastic at cwcom.net

He who laughs last doesn't
get the joke.

------------------------------

From: [EMAIL PROTECTED]
Subject: general questions on SSL certificates
Date: Fri, 31 Mar 2000 18:32:01 GMT

Hello,

I would like to find out more about the level of security SSL
certificates have to offer. Could someone tell me if there are any
differences between SET certificates and SSL ones ? For some time I
though that SSL certificates did not provide identification of the
conversing entities, just the encryption. But it looks like SSL
certificates also rely on CAs, and that information included in a SSL
certificate describing the owner of the certificate is being signed by
the CA. Is that correct ?
Also, I would like to know where could I find information on CAs issuing
SSL certificates and prices of those, as well as any additional info on
SSL security.

Thank you for your help,

Martin


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (mark carroll)
Subject: Re: general questions on SSL certificates
Date: 31 Mar 2000 18:48:41 GMT

In article <8c2qv1$8p5$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
(snip)
>conversing entities, just the encryption. But it looks like SSL
>certificates also rely on CAs, and that information included in a SSL
>certificate describing the owner of the certificate is being signed by
>the CA. Is that correct ?

Yes, that's commonplace.

>Also, I would like to know where could I find information on CAs issuing
>SSL certificates and prices of those, as well as any additional info on
>SSL security.

If you want CAs recognised by WWW browsers, etc. (I don't know if
you're interested in secure web serving or something else), VeriSign
and Thawte come to my mind. The obvious guesses of URLs for them
probably work; if not, Yahoo is your friend.

-- Mark

------------------------------

From: Christof Paar <[EMAIL PROTECTED]>
Subject: Re: LFSR's
Date: Fri, 31 Mar 2000 14:04:11 -0500

On Fri, 31 Mar 2000, Tim Tyler wrote:

> Pascal JUNOD <[EMAIL PROTECTED]> wrote:
> 
> : [...] irreducible polynom x^63 + x + 1 over GF(2) [...based LFSR]
> 
> : Let's just speak about the period [...]
> 
> : The polynomial being irreducible, it produces a sequence of bits
> : (normally the lsb of each states) with a period of 2^64 -1.

Irreducibility is not sufficient. You want what's called a "primitive
polynomial". All primitive polynomials are irreducible, though.
Non-primitive but irreducible polynomials give you sequence shorter than
2^m-1. For example, x^4+x^3+x^2+x+1 is irreducible but generates an LFSR
sequence of length 5, independent of the start vector. The primitve
polynomial x^4+x+1 yields a maximum length sequence with period 15.

Luckily, most tables in the coding/cryptography field contain primitive
polynomials anyway.

> 
> : Now, instead of taking the lsb, we could take bit #56 or #2 or any one
> : of the 64 bits of the internal state. 
> 
> : All these possible sequences have a period of 2^64 - 1,or am I wrong ?
> 
> You're right.
> 
> : Now, if we output the whole internal state, we produce a sequence of
> : 2^64 - 1 values of 64 bits each, or 64*(2^64-1) bits. Am I right ?
> 
> Yes.

Just a word of warning: Two subsequent 63 bits (if you choose 2^63+x+1,
not 64) words are very similar, as they are essentially shifted versions
of each other. The only difference is the MSB.

Cheers,

Christof

! WORKSHOP ON CRYPTOGRAPHIC HARDWARE AND EMBEDDED SYSTEMS (CHES 2000) !
!                   WPI, August 17 & 18, 2000                         !
!          http://www.ece.wpi.edu/Research/crypt/ches                 !

***********************************************************************
                 Christof Paar,  Assistant Professor
          Cryptography and Information Security (CRIS) Group
      ECE Dept., WPI, 100 Institute Rd., Worcester, MA 01609, USA
fon:(508) 831 5061  email: [EMAIL PROTECTED]   
fax:(508) 831 5491  www: http://www.ece.wpi.edu/People/faculty/cxp.html
***********************************************************************


------------------------------

From: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Subject: Re: GCHQ
Reply-To: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Date: Fri, 31 Mar 2000 19:21:42 GMT

Gavin <[EMAIL PROTECTED]> wrote:
G> Anyone cracked the code relating to the challenge on the GCHQ website ? I
G> have found the five hidden parts of the message, which when put together
G> would make a message if you changed  the two occurences of one particular
G> letter to another letter. However, I think there is more to it than them
G> just making a mistake on the website. Any ideas ?

Yes, I cracked it in about 2 hours.  I think the replacement you're
thinking of is intentional -- it was probably done to make it a bit
less obvious and to keep the message from being easily solvable without
getting all of the clues (note that without that piece, it would be
fairly difficult to guess what was supposed to be there).

Besides, they said all pieces were encrypted in some form, and without
that exchange it wouldn't be encrypted, would it?  (Not that the fifth
clue was encrypted anyway....)

Damian Menscher
-- 
--==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==--
--==## <[EMAIL PROTECTED]> www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==--
--==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==--

------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Chronometric Cryptography
Date: Fri, 31 Mar 2000 11:39:24 -0000

I think at best this would increase the work load by a few
bits. My thoughts are that what you have done is create a
system with 2 keys, one which you call a key, the other is
the number of rounds. Since it's safe to say that your
rounds will certainly not be 2^32 (at least not in the near
future), that adds at most 32 bits to the key space. There
are two erosions on this. First is the fact that your
adversary is likely have knowledge of how much computing
power you have, right now without knowing you I would
estimate that you have a Pentium 2 or 3 or Athlon, this
gives me a known keyspace of only 4 times, or 2 bits. The
other erosion is on your estimate of how to do go about the
attack, a logical attack pattern would be to run through a
specific workload value through all the keys, then increase
the workload value, repeat. The effect of this is that my
first pass is fast, my last pass is about 1/4 the speed,
meaning that you will only get around 1 bit extra out of
this. To add to the complications remember that with a
parameterized algorithm you make it VERY difficult to
analyze, each parameterization needs to be analyzed in order
to avoid round reductions at unexpected places, forming a
group-like property. Done well they can be very good, but
after the very good, you very quickly go to very bad.
                        Joe

"Dan Coyle" <[EMAIL PROTECTED]> wrote in message
news:1aWE4.1130$[EMAIL PROTECTED]...
> Dan Coyle ( [EMAIL PROTECTED] )
>
> I have been working on a project for a while now, and was
wondering if
> anyone here might have some feedback, Good Idea/Bad
Idea/???.
>
> In most cases, that I've seen, key size seems to be the
determining factor
> in judging the effective security provided by any given
cipher.  That is, a
> cipher with a 128-bit key is usually judged to be better
than a cipher with
> a 56-bit key.  This isn't always the case, I know, but
where a stronger
> cipher is needed, a person usually increases the bit size
of the key.  Each
> time this is done the application/object that needs to use
the cipher, needs
> to be updated, and a new version of the product released.
Key size is also,
> usually, the key factor in determining if the
application/object can be
> exported to other countries.
>
> A simple solution to this problem would be to create a
cipher that uses
> processing time as a primary determinate for it's measure
of security.  That
> is, create a cipher that took just as long to encrypt any
given plaintext
> into ciphertext, as it does to convert that ciphertext
back into plaintext.
> Therefore allowing the application/object to determine the
measure of
> security at run-time instead of design-time.  In addition,
when technology
> changes, and more powerful machines are made that can
resolve ciphertext
> back into plaintext using brute force methods, the
hardware which executes
> the cipher is the only component that what would need
upgrading because the
> cipher would still take the same amount of time to
execute, it just gets
> more cycles to do it's job.  I call this type of cipher, a
Chronometric
> cipher meaning a cipher whose security is measured by
time.
>
> Example :
>    User A encrypts a message in 1995 using a 56-bit key
Chronometric cipher
> on a 100MHz Pentium Machine for 1 second.  In 2000, User A
uses the same
> application with the same 56-bit Chronometric cipher on a
Pentium III 700MHz
> machine for a second.  Because the user is on a faster
machine when he
> encrypts the second message, it does more work while
encrypting the message,
> making it more secure, even though it's the same program,
and underlying
> algorithm.
>
>
> Another advantage that a Chronometric cipher would bring,
is that a
> malicious user, attempting a brute force attack, to
decrypt the message,
> would have to decrypt the message with, at least, the same
amount of
> processing effort.  Even more, as long as the malicious
user is not aware
> how much processing effort was put into encrypting the
message, he/she would
> have to hazard a guess, to how much processing effort to
use while
> attempting to brute force the decryption.
>
>
> There are, however, some drawbacks to such an algorithm.
>
> 1. The Recipient, of the ciphertext, has no idea how much
processing effort
> it will take to decrypt an encrypted message.
> 2. Faster machines would either speed up the process, or
make it more
> secure, but not both.
> 3. If an incorrect key is used, it would result in, what
would appear to be,
> an infinite loop.
>
> After some time, and effort, I put together a prototype,
and it seems to
> work pretty well.  I've spent most of my time doing
Cryptanalysis, and I
> think I've tied down most of the weak spots.
>
> The basic algorithm I used was as follows
>
>
> User A enters a message M, a key K, and a time period P
>
> KS <- Hash(K)
> Ki <- KS
> TargetTime <- CurrentTime + P
> While (CurrentTime < TargetTime) do
> Begin
>    M    <- EncryptMessage(M,Ki)
>    Ki <- GenerateNextKey(M,Ki)
> End
> KF <- KS Xor Ki
> M  <- Concat(M,KF)
>
> KS - StartKey
> Ki - Iteration Key
> KF - FinalKey, stored within the final message.
> Hash - A Hashing Function
> EncryptMessage - Any Symmetric Key Cipher function
> GenerateNextKey - A function that Generates the next
Iteration Key, based on
> the old Iteration Key and the Current Message
>
> To decrypt the message I use the following algorithm
>
> User A enters a message M, with Final Key KF Concatenated
to it, and Key K
>
> KS <- KF Xor Hash(K)
> Ki <- KS
> While (KS <> K) do
> Begin
>    Ki <- GeneratePrevKey(M,Ki)
>    M <- DecryptMessage(M,Ki)
> End
>
>
> Thank you for your time.
>
> DC
>
>
>
>



------------------------------

From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: general questions on SSL certificates
Reply-To: [EMAIL PROTECTED]
Date: Fri, 31 Mar 2000 19:29:21 GMT

In article <8c2qv1$8p5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> Hello,
> 
> I would like to find out more about the level of security SSL
> certificates have to offer. Could someone tell me if there are any
> differences between SET certificates and SSL ones ?

The big difference about SET is not the certificate format but
rather the protocols used.  Simply put, with SET the merchant
cannot learn the credit card number of the customer, but does
get cryptographic assurance that the transaction will be honored.

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Coderpunks Query on Teledyne Crypto
Date: Fri, 31 Mar 2000 22:21:05 +0200

Jim Reeds wrote:
> 

> From personal communication with Teledyne people, & from
> reading some Teledyne papers, I know what "orthomorphism"
> means.  A permutation f of the elements of a group
> is an orthomorphism if the function g(x):=f(x)+x (for
> additive groups, or g(x):=f(x)*x for multiplicative ones)
> is also a permutation.  In the case at hand, the group
> is bitwise mod 2 addition of bytes.

Do I understand correctly that x is a character of the input
alphabet and f(x) is the corresponding character of the
output alphabet? Since you have apparently quite some knowledge
about that product, could you please tell what are the essential
advantages of the orthomorphism? Thanks.

M. K. Shen

------------------------------

From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Is it really NSA ?!
Date: Fri, 31 Mar 2000 15:27:27 -0500

[EMAIL PROTECTED] wrote:

> In article <[EMAIL PROTECTED]>
> ,
> Arthur Dardia <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > Hmm...attacking the NSA? Definitely an interesting fantasy...
> >
> > However, to do it properly, I wouldn't suggest an electronic attack, but
> > more of a physical, armed-to-the-teeth attack. First things first,
> > don't bother cutting power - I'm positive they have a generator, and
> > once their generator kicks in, I'm sure they'd be suspicious. Secondly,
> > I'm sure they have metal detectors...porcelain guns? I know I saw them
> > in some movie. :)
> >
>       The russians built a device that can shoot
> an electromagnetic pulse and tested it in an
> open desert- like area. It stopped dead a
> running car by blowing out its electronics
> from a large distance away (I don't remember
> how far). The U.S. and probably other countries
> have these devices. On TV (maybe it was the
> Discovery Channel) there was a physicist or
> electrical engineer who built a smaller one of
> these using commonly available parts
> (although he wouldn't say how on TV).
>       I do *not* recommend this:  but it
> *might* be possible to use such a device to
> clandestinely cause electrical disruptions in
> Ft. Meade from a distance. I wouldn't be
> surprised if they could detect such an assault
> and, anyways, their critical sytems are
> underground for good reason.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

These guns do exist, as far as how advanced I wouldn't know.  On the TLC or
DSC channel (I forget which one), they were showing non-lethal weapons the
police and SWAT teams are developing to end hostage situations and disarm
criminals much easier (Kudos to all those involved in such projects...).  One
of the weapons was designed to be shot out of the front of a police vehicle
and run under the car of the person leading the high-speed chase.  It would
emmit such frequencies and shut down this car, such as you said.  I also
remember hearing about someone building one for a science fair - I believe he
won too...

As far as the TLC or DSC program on non-lethal weapons, it's been airing a lot
recently, maybe you could catch it...

--
Arthur Dardia      Wayne Hills High School      [EMAIL PROTECTED]
 PGP 6.5.1 Public Key    http://www.webspan.net/~ahdiii/ahdiii.asc



------------------------------

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Chronometric Cryptography
Date: 31 Mar 2000 20:33:38 GMT

In <[EMAIL PROTECTED]> Gareth Howell <[EMAIL PROTECTED]> writes:

>"Dan Coyle" <[EMAIL PROTECTED]> wrote:

>> Therefore allowing the application/object to determine the measure of
>> security at run-time instead of design-time.  In addition, when technology
>> changes, and more powerful machines are made that can resolve ciphertext
>> back into plaintext using brute force methods, the hardware which executes
>> the cipher is the only component that what would need upgrading because the
>> cipher would still take the same amount of time to execute, it just gets
>> more cycles to do it's job.  I call this type of cipher, a Chronometric
>> cipher meaning a cipher whose security is measured by time.
>> 

The problem of course is that the cypher has no idea as to what the best
hardware out there is. Ie, I could be running it on a 386, but that is
certainly not "state of the art". 
The variable key size algorithms sort of do exactly what you are
refering to. You can decide on what key size you want to use considering
everyting you know about the state of the art. That way a 386 will do
just as strong a crypto as a 1GH Athelon.

------------------------------

From: [EMAIL PROTECTED] (mark carroll)
Subject: Re: general questions on SSL certificates
Date: 31 Mar 2000 20:38:41 GMT

In article <8c2ru9$s60$[EMAIL PROTECTED]>,
mark carroll <[EMAIL PROTECTED]> wrote:
(snip)
>If you want CAs recognised by WWW browsers, etc. (I don't know if
>you're interested in secure web serving or something else), VeriSign
>and Thawte come to my mind. The obvious guesses of URLs for them
(snip)

I should have added that if you don't care about people recognising
the CA signing your certificate, you can of course be your own CA.

-- Mark

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Proof of Identity
Date: Fri, 31 Mar 2000 20:41:10 GMT

One idea [while sitting in algebra] for proving that you were present at
something [or wrote a book, etc] is to embed simple system of equations
like

11a + 3b  - 9c = -927
-5a - 11b + 7c = 1561
..

And not give the last equation.  Of course the last solution will give
out the values (a, b, c).  The ability to give out the last eqn' or the
set (a, b, c) proves that you wrote the first two equations.   So that
if you add those two lines to your document you can later prove you
wrote.

One major problem is that you can prove that only once.  Then they can
say they wrote it.  Any thoughts?

Question, is it possible to calc the gcd(x, y) mod a number?  So that if
I do 5x mod 11, can I tell if it's a multiple of 5?  I don't think you
can, just wondering.

[btw the solution to the above system is my Social Insurance Number [I
was really bored in class]].

Tom

------------------------------

Subject: Re: general questions on SSL certificates
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2000 21:00:27 GMT

[EMAIL PROTECTED] (Larry Kilgallen) writes:
> The big difference about SET is not the certificate format but
> rather the protocols used.  Simply put, with SET the merchant
> cannot learn the credit card number of the customer, but does
> get cryptographic assurance that the transaction will be honored.

actually this has been argued both ways ... however the merchant needs
to keep a record of the credit card number after the transaction has
executed ... since there are various business processes that rely on
the merchant having that number.

The consumer encrypts the credit card number under the payment gateway
key ... and sends it to the merchant .. who forwards it to the payment
gateway. For a valid merchant/transaction, the payment gateway echos
the number back to the merchant in the transaction response (where
it goes into the merchant database of credit card numbers).

Also, SET is sensitive to the privacy issues ... not identifying the
certificate owner ... just carrying the bare minimum for having some
account. This somewhat falls into the category of "relying party only"
certificates ... because of both liability & privacy issues.

random other references at 

http://www.garlic.com/~lynn/
http://www.garlic.com/~lynn/ansiepay.htm#theory
http://www.garlic.com/~lynn/aepay3.htm#sslset1
http://www.garlic.com/~lynn/aepay3.htm#sslset2
http://www.garlic.com/~lynn/aepay2.htm#aadspriv
http://www.garlic.com/~lynn/aepay2.htm#privrules
http://www.garlic.com/~lynn/aadsmail.htm#comfort
http://www.garlic.com/~lynn/ansiepay.htm#privacy

-- 
Anne & Lynn Wheeler   | [EMAIL PROTECTED], [EMAIL PROTECTED]
 http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/

------------------------------

From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Legal Opinion advises use of steganographic filesytems in UK
Date: Fri, 31 Mar 2000 15:23:33 -0500

[EMAIL PROTECTED] wrote:
> 
>        If you're a limey you might want to
> consider contacting the company Eurotech.
> They have aquired the company Crypto.com
> which *claims* to have a technology that can
> provide absolute security on open circuits
> *without* the use of a key.

Hm.  Sounds fishy.

I looked for info and found none, but I did find
this word from Matt Blaze, who is someone whose
opinions are worth considering:

http://www.crypto.com/cryptocom.html

        paul

------------------------------


** 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
******************************

Reply via email to