Cryptography-Digest Digest #204, Volume #10 Wed, 8 Sep 99 20:13:02 EDT
Contents:
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) (John Savard)
Re: THE NSAKEY ("karl malbrain")
Re: Random and pseudo-random numbers ("Thomas J. Boschloo")
Re: NSAKEY as an upgrade key (Was: NSA and MS windows) ("Thomas J. Boschloo")
Re: Source code (Tom St Denis)
Re: some information theory (DJohn37050)
Re: THE NSAKEY (Tom St Denis)
Re: THE NSAKEY (Tom St Denis)
Re: some information theory (Tom St Denis)
Re: some information theory (SCOTT19U.ZIP_GUY)
Re: Random and pseudo-random numbers (Tom St Denis)
Encrypt Credit Card number (Neela Datta)
Re: some information theory (John Savard)
Re: THE NSAKEY (jerome)
Re: some information theory (Tim Tyler)
encrypt cc (Neela Datta)
Re: Random and pseudo-random numbers (Eric Lee Green)
Re: Random and pseudo-random numbers (Tim Tyler)
Re: Random and pseudo-random numbers (Tim Tyler)
Re: some information theory ("Steven Alexander")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Date: Wed, 08 Sep 1999 21:45:33 GMT
"Trevor Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>This only makes sense if there is a revocation mechanism for the primary
>key. Do you see such a mechanism?
Don't include the primary key in the next release of Windows. Yes, it
is a far-from-perfect revocation mechanism, but if software that can
run on the earlier versions can't identify itself as "Windows"
software, for example, one could obsolete a version fairly well.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: THE NSAKEY
Date: Wed, 8 Sep 1999 13:45:25 -0700
jerome <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> All this thread is very 'personnal' and is very few related to
> cryptography. Moreover it is unlikely that one of you can
> convince the other part.
>
This is called a CONTRADICTION. Stop. Karl M
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Wed, 08 Sep 1999 21:37:39 +0200
Eric Lee Green wrote:
>
> [EMAIL PROTECTED] wrote:
> > So requiring the user to doodle on the keyboard, or play with the mouse,
> > probably is unavoidable, I think.
>
> Won't work here, alas. The machine may actually be at an ISP (for
> co-hosting), where I cannot doodle on the keyboard or play with the
> mouse, or it may be hidden in a wiring closet because it's an Internet
> server that perhaps doesn't even have a keyboard and mouse (think Cobalt
> Qube). In any event, other than my initial state I don't have to be
> "truly" random (and I seriously question whether you can get such a
> thing, even measuring cosmic rays with a geiger counter doesn't produce
> truly random numbers), I need to be unpredictable. Which is almost, but
> not quite, the same thing
If the computer is on the internet; you could record the IP packets that
arrive and the timing between them. An ethernet card is also a nice
source of 'random' information.
Hi!,
Thomas
--
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: NSAKEY as an upgrade key (Was: NSA and MS windows)
Date: Wed, 08 Sep 1999 21:01:03 +0200
"Trevor Jackson, III" wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Thomas J. Boschloo ([EMAIL PROTECTED]) wrote:
> > : Microsoft's explanation "Why is a backup key needed?" is bogus (they
> > : claim it would be needed for when the building in which it is kept is
> > : destroyed by a natural disaster, LOL).
> >
> > Well, while keeping two copies of the key would solve that, two copies of
> > the same secret key won't help if one key is _compromised_. For that, a
> > second key, to which the corresponding secret key is stored _elsewhere_,
> > would serve a useful backup function.
>
> This only makes sense if there is a revocation mechanism for the primary
> key. Do you see such a mechanism?
MS could issue a patch when the first key was compromised.. They do that
all the time ;-)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Source code
Date: Wed, 08 Sep 1999 20:52:13 GMT
In article <[EMAIL PROTECTED]>,
Erick Stevenson <[EMAIL PROTECTED]> wrote:
> Greetings. I need source code for the highest exportable algor's. Can
> anyone help me with this? VB, C++, Java whatever is fine.
Can I ask something?
DID YOU TRY? I managed to add Serpent, Twofish, CAST, Blowfish, RC5 to my
peekboo program (see below) in under 2 hours (testing/looking for stack
holes)....
I think you should just hunt down online code and DO IT YOURSELF.
If you are seriously stuck on something ask, but please don't ask for 'gimme
code now so I can stick it together market it as 'ultra-safe' make oolas of
money and hold no clue'.
Tom
[1] Peekboo Message Encryptor, http://people.goplay.com/tomstdenis/pb.html
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: some information theory
Date: 08 Sep 1999 21:53:43 GMT
Encryption is not normally done on random appearing data, and if it was,
compression would not work.
Don Johnson
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: THE NSAKEY
Date: Wed, 08 Sep 1999 20:59:47 GMT
In article <7r66nd$t1u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
> Nonsense. First of all, I don't have a "job" (other than my grad
> student position at UC Berkeley), and even if I did, I wouldn't pull
> any punches for my employer, no matter who.
>
> Right now, showing independent thought is precisely my job.
Oh geez... and you are not in trouble with are three letter friends ?
(hehehehehe)
> Is there a reason we can't debate the technical issue on its merits?
> If my reasoning is flawed, tear it apart. Trying to attack the messenger
> because you don't like the message he's bringing is rather pointless.
K, where can I read about the 'merits' of the nsakey? I actually want to
know (and don't care to read the other huge thread). Any websites or is the
situtation easy to explain?
> Just for the record, I'm not an "employee" of Bruce Schneier.
> I have done some consulting for him (as a consultant, not an employee),
> but not lately. My main relationship to Counterpane is that I've
> done a lot of research with those folks. And no, noone at Counterpane
> has ever tried to take advantage of our relationship in any way.
argggg.... facts.... no!!!! wild speculation will forever rule this group!
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: THE NSAKEY
Date: Wed, 08 Sep 1999 21:02:36 GMT
In article <7r6e28$2df6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Maybe you haven't followed the whole thread it seems Mr Wagner is now
> claming he was never an empoyee of Mr Bruce only that he work as a
> contractor. So I guess any we should consider the information as bogus.
> Why would David Wagner lead us astray. Unless there is a remore possiblity
> of a future job. Nay he wouldn't do that. Silly the thoughts that cross my
> mind.
Drop it.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Wed, 08 Sep 1999 21:12:08 GMT
In article <7r6ium$38k$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Ah, but here's something to think about. When you compress, you are in
> fact placing more information into a block. So instead of 8 bytes of
> plaintext information in a 64-bit block, you could be getting 10, for
> example. Of course, it you could also be packing in 12. The result
> could be, theoretically of course, that if you know the n characters,
> where n is less than the total number of characthers compressed into
> 64-bits AND you don't have access to the compressed text, a
> known-plaintext attack is now more difficult. So, perhaps compression
> does add some security. Of course, I could be wrong and I don't
> consider it a major factor in creating a secure environment. The main
> purpose of compression is still to make files smaller so there's less to
> transmit.
See below.
> > 2) Is it not true that no matter what compression algorithm (C for
> this
> > example) H(M) will always equal H(C(M))? If so then the message is no
> more
> > complicated after compressing with 'one-to-one huffman' or deflate, or
> lz78,
> > or lzss, or ...
>
> Hmm, I did not know that. This is just direct compression, no added
> headers, correct? I would assume that a header would change the HASH.
Well the headers are not considered part of the user message. They are part
of the sent message. I think I pointed out that you don't encrypt known
headers? hmm ok. Well the actual 'compressed content' has no more
information then the message it was before. Just because you fit 23 chars in
one DES block, you still only have a MAX of 64-bits of information (not 23 *
7 = 161 bits). It should stand that breaking any method of this nature
expands LINEARLY with the amount of work used to ENCODE (compress+encrypt)
the message.
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory
Date: Wed, 08 Sep 1999 22:57:35 GMT
In article <7r6hva$2cl$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>If I am not wrong, the following statement is true:
>
>1) There is no method of INCREASING or DECREASING the entropy of a message M
>(outside of adding/removing information).
>
>If that is true, then no matter what function you employ (be it ROT13,
>compression, etc...) the actual secret message (before being encrypted) will
>always have H(M) bits of 'information'.
>
>I am trying to figure this out to shut DS up for once. I still don't believe
>compression before encryption increases security in REAL cryptosystems. I
>still believe that it can slightly make things more complicated, but it's
>SOLE job is to make M shorter (by removing redundancy).
I see you have been mislead by your silent Crypto Gods. Let me give you
an example that maybe some one so brain washed as you can understand.
Lets say I have a random file ( lets just say a crypto god found one for me).
I want to send it to my son since he lost his copy of this random file and
used it for a one time pad.
Lets say the NSA has been monitoring the encryption messages I send my
son (lots of luck). Lets say my son only has a weak encyrption system left
on his hard dirve and it only has a 8 bit key. I could use PKZIP and sent the
message. But then the clever NSA tries all 256 possible key patterns and
they find one that is a valid PK zip file. It passes the CRC check and has
"PK" as its first two bytes. Well they can pat themselves on the back
becasue they can be pretty damn sure they know which key I used.
and they know what the file I sent them was. They may not no why I sent it
but they are dam sure it is the one I sent.
However since I try to keep at least one step ahead. I use may huffman
compression prograam. THe NSA is pretty sure I used it and after trying
all 256 bit keys and doing all 256 decmpressions though know that one
is the one I sent but they haven't got the foggest idea which file it was.
aad they my sit around scratching there asses trying to figure out
what was sent. And they may even worry that I changed my encryption
method or maybe since it was sept 8 was secretly conspired to do
an extra encryption or something. The thing is they don't know what
the hell I sent or why.
I hope this was not over your head little one.
>
>2) Is it not true that no matter what compression algorithm (C for this
>example) H(M) will always equal H(C(M))? If so then the message is no more
>complicated after compressing with 'one-to-one huffman' or deflate, or lz78,
>or lzss, or ...
>
>
>(btw I make the assumption that the encryption and compression are both fully
>invertable.) Tom -- damn windows... new PGP key!!!
>http://people.goplay.com/tomstdenis/key.pgp (this time I have a backup of the
>secret key)
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Wed, 08 Sep 1999 21:18:48 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> <snip>
> > But if your initial randomness is smaller than the keys you generate, then
> > brute-force search over the smaller pool of possibilities for the initial
> > randomness will do you in. To make 1024-bit keys, you *need* 1024 bits of
> > true randomness to start from, and 2048 bits is better.
>
> Not necessarily; in fact, probably not.
>
> If the 1024 bit key is an RSA key, for example, then in fact we
> don't expect or require 1024 bits of entropy. No RSA key would
> ever be attacked by brute force - factorization is much faster.
> It is only necessary to have as much entropy as would make a
> brute force search over the entropy state at least as hard as
> factorization. I leave it to more numerically inclined types
> to make claims about how many bits that is.
>
> For generating many keys, of course we need more entropy. But
> it isn't as simple as saying we need X bits of entropy times
> N keys. With a hash obscuring relationships between the PRNG
> outputs, we can get by with less. I will not be so bold as
> to try to say how much...
Here's a fact:
To brute force a N bit RSA key you need: Y = N/2, E = Y / ln Y, so you need E
effort (or trials) to break it). This is an estimation (no math flames
please).
If you are making 512 bit primes you will need to make about 177 512 bit
numbers before (if I did it right). So each prime requires ABOUT 90624 bits
(181248 bits total).
(2^512 / (2^512 / ln 2^512) / 2)
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Neela Datta <[EMAIL PROTECTED]>
Subject: Encrypt Credit Card number
Date: Wed, 08 Sep 1999 15:03:31 -0700
Reply-To: [EMAIL PROTECTED]
I am workig on a ecommerce application and have to write c ode in
JAVA to encrypt credit card number filled in by a customer in a HTML
form and then store it in database and then again decrypt it back.
I am using Informix database and am looking for some simple reversible
algorithms to do that. I am stuck with using JDK1.1 so I can't use JCE.
Can anyone tell me some very simple algo?
Thanks,
Neela
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: some information theory
Date: Wed, 08 Sep 1999 21:41:31 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>I am trying to figure this out to shut DS up for once. I still don't believe
>compression before encryption increases security in REAL cryptosystems.
You are basically right that the "real" information in a message
doesn't change under compression. But the redundancy that compression
removes does facilitate ciphertext-only attacks.
Since the security of "REAL cryptosystems" is gauged not against the
most difficult attack - ciphertext-only - but against stronger
attacks, such as known-plaintext, you are right that compression
generally won't increase the security level of an application _from
that point of view_. But that doesn't make it _irrelevant_ to
security.
I'm not sure about Bruce Schneier's performance in making this
distinction clear in his writings, but I suspect this is the point
you're missing here. The problem with Mr. Scott's scheme is not that
trying to adapt compression to encryption is a bad idea, but that he
is trying to eliminate redundancy at a very high level (making
brute-force search maximally difficult) while increasing it at a low
level (treating the all-zero symbol as special).
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: THE NSAKEY
Date: 8 Sep 1999 22:09:13 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 08 Sep 1999 21:01:08 GMT, Tom St Denis wrote:
>>
>> http://www.counterpane.com/cpaneinfo.html lists d.wagner as a part of
>> counterpane personnel and b.scheiner is the president of counterpane.
>>
>> i don't take position in this debat, i simply show that cryptography
>> is a small world and it isen't exactly fair to say that an employee
>> and his president arent 'attached'.
>
>I think you should have confirmed this before spreading rumour... You guys
>are very unprofessional (no wonder though this is sci.crypt).
can you explain ?
counterpane site lists d.wagner as a part of the personnel. d.wagner said
he worked for counterpane. counterpane and d.wagner are both authoritative
in this field. it isn't a rumor.
but i fully agree that is sci.crypt and this thread doesn't belong to here.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: some information theory
Reply-To: [EMAIL PROTECTED]
Date: Wed, 8 Sep 1999 23:07:08 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: If I am not wrong, the following statement is true:
: 1) There is no method of INCREASING or DECREASING the entropy of a message M
: (outside of adding/removing information).
: If that is true, then no matter what function you employ (be it ROT13,
: compression, etc...) the actual secret message (before being encrypted) will
: always have H(M) bits of 'information'.
I think you're wrong. Encryption algorithms /can/ systematically add
information to the message they encrypt. The quantity of information
added can't exceed the size of the cryptography program, plus the size of
the key - but it is there nonetheless.
/Only/ if you measure the information content (i.e. complexity in this
context) of a message relative to a descriptive language that contains the
particular encryption system used as language primitives (that thus need
very little information to describe) is your statement anywhere near
correct.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Talk is cheap, but using a modem can get expensive.
------------------------------
From: Neela Datta <[EMAIL PROTECTED]>
Subject: encrypt cc
Date: Wed, 08 Sep 1999 15:25:39 -0700
Reply-To: [EMAIL PROTECTED]
test
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Wed, 08 Sep 1999 16:24:40 -0700
"Thomas J. Boschloo" wrote:
> If the computer is on the internet; you could record the IP packets that
> arrive and the timing between them. An ethernet card is also a nice
> source of 'random' information.
The timing of incoming requests is in fact one of the sources of entropy
that I use, but that is only a few bits worth of entropy. This has to
run on various systems such as Solaris, HP/UX, etc., where there is no
standard way of accessing the ethernet card directly, so I cannot use
many of the more "obvious" sources of entropy. Also note that timing of
incoming requests IS available to the attacker, who presumably could use
it to gain knowledge of the current state of the PRNG, so other sources
of entropy must also be mixed in here.
Current state of things:
2^128 possible keys into the block cipher (one entropy pool)
2^128 possible inputs into the block cipher (another entropy pool)
These pools are assumed to be secure (i.e., if somebody can access those
values, then the game is already open, the machine has already been
compromised -- the whole point here is to keep someone from compromising
the machine, not to frustrate someone who already has compromised the
machine).
Thus there are 2^256 possible states that the block cipher can operate
upon. Hmm, RC6 does not maintain internal state between blocks (i.e.,
each block operates independently of all others). Hmm, what happens if
we maintain a pool for the output using, say, MD5 or some similar
algorithm, to use prior state to permutate the output more? Does that
give us any additional help here, given that the attacker is not going
to know what numbers have been previously generated in this particular
application?
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Reply-To: [EMAIL PROTECTED]
Date: Wed, 8 Sep 1999 23:22:11 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
: : To make 1024-bit keys, you *need* 1024 bits of
: : true randomness to start from, and 2048 bits is better.
: If you want 1024 bit keys - and you have 1024 bits of true randomness -
: what more could you possibly ask for?
To answer my own question - if you need to generate more than one key,
then the more bits the merrier (up to 1024 x n where n is the number of
keys you require - more bits than that would be overkill).
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
If it's God's will, I want to be in it.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Reply-To: [EMAIL PROTECTED]
Date: Wed, 8 Sep 1999 23:19:32 GMT
Eric Lee Green <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> [EMAIL PROTECTED] wrote:
:>
:> : To make 1024-bit keys, you *need* 1024 bits of
:> : true randomness to start from, and 2048 bits is better.
:>
:> If you want 1024 bit keys - and you have 1024 bits of true randomness -
:> what more could you possibly ask for?
: Well, one rarely has 1024 bits MORE true randomness within the next <n>
: seconds that you're trying to generate an RSA prime pair with. (You may
: need to test quite a few 1024-bit numbers before finding some primes).
If these 1024-bit numbers are primes then they're /extremely/ far from
being random, and most of the 1024 bits of supposed randomness are being
wasted - as large primes occur /very/ sparsely.
You started this thread though - I suppose you know what you want ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The bigger they are, the harder they hit you.
------------------------------
From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Wed, 8 Sep 1999 16:36:42 -0700
David A. Scott said:
<snip>
> Lets say the NSA has been monitoring the encryption messages I send my
> son (lots of luck). Lets say my son only has a weak encyrption system left
> on his hard dirve and it only has a 8 bit key. I could use PKZIP and sent
the
> message. But then the clever NSA tries all 256 possible key patterns and
> they find one that is a valid PK zip file. It passes the CRC check and has
> "PK" as its first two bytes. Well they can pat themselves on the back
> becasue they can be pretty damn sure they know which key I used.
> and they know what the file I sent them was. They may not no why I sent it
> but they are dam sure it is the one I sent.
> However since I try to keep at least one step ahead. I use may huffman
> compression prograam. THe NSA is pretty sure I used it and after trying
> all 256 bit keys and doing all 256 decmpressions though know that one
> is the one I sent but they haven't got the foggest idea which file it was.
> aad they my sit around scratching there asses trying to figure out
> what was sent. And they may even worry that I changed my encryption
> method or maybe since it was sept 8 was secretly conspired to do
> an extra encryption or something. The thing is they don't know what
> the hell I sent or why.
<snip>
The only security gained here is from the fact that the file will no longer
have a predictable header. If the NSA is somehow able to find plaintext,
they will try all 256 keys and they will have the file just as with the
PKZIP example. Otherwise they will still just have 256 random messages.
However, if they have reason to believe that your son is using one of the
256 possible messages(without plaintext they don't know which one is the
real one) as a OTP key they can still try each one against the messages that
are being encrypted using the OTP. In the case of sending random files,
this would add security. However, if you are sending messages that are not
random the cipher is not very much stronger.
-steven
------------------------------
** 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
******************************
