Cryptography-Digest Digest #737, Volume #12 Fri, 22 Sep 00 05:13:00 EDT
Contents:
ANNOUNCE> New VB Cryptography Book ([EMAIL PROTECTED])
Re: Tying Up Loose Ends - Correction (Benjamin Goldberg)
Every heard of this device? NT Sentinel ("[EMAIL PROTECTED]")
Re: CDMA tracking (was Re: GSM tracking) (Jerry Coffin)
Re: IBM analysis secret. (Jerry Coffin)
Re: t (John Savard)
Re: Simple hash function (wtshaw)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: XOR (John Savard)
Re: t (John Savard)
Re: t (John Savard)
Re: t ("Douglas A. Gwyn")
Re: Revilo P. Oliver: Cryptanalyst? ("Douglas A. Gwyn")
Re: t (Runu Knips)
Re: t (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Proper way to intro a new algorithm to sci.crypt? (Mok-Kong Shen)
Re: IBM analysis secret. (Roger Schlafly)
Again a topic of disappearing e-mail? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: ANNOUNCE> New VB Cryptography Book
Date: Fri, 22 Sep 2000 02:32:03 GMT
John Wiley & Sons has recently published Richard Bondi's "Cryptography
for Visual Basic: A Programmer's Guide to the Microsoft CryptoAPI" that
includes the source code for CryptoAPI COM wrappers. Bruce Schneier,
author of the best-selling "Applied Cryptography", has kindly endorsed
it by saying that "this is essential reading for anyone who needs to
understand Microsoft�s CryptoAPI, its strengths and its limitations."
You can review the open source code and documentation at
www.geocities.com/richardbondi.
Best,
Richard Bondi
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 22 Sep 2000 03:02:58 GMT
SCOTT19U.ZIP_GUY wrote:
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >Tim Tyler wrote:
> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >> : If my message is over one hundred bytes, do you think
> >> : that I need to care about wasting 5 bits?? [...]
> >>
> >> At worst, this can reduce the size of keyspace by a factor of 32.
> >
> >Sorry, I don't understand. What do you mean by 'keyspace'
> >here? This is the message space. The message gets longer
> >by 5 bits. There is no information in the above of how
> >big the key is. Do I loose or gain security by, say,
> >always appending 5 0's to the ciphertext?
>
> I thought we are talking about compressing then ecnrypting.
> If you always add 5 zeros or any other fixed amount of bits
> after a compressed string or any file for that matter which is
> then encrypted. The attacker know what the last few bits are
> and throws out keys that don't match. So if the last five bits
> of a file are known then it means you reduce your key space by
> 5 bits.
Reducing the message space by x bits does *not* reduce the keyspace by x
bits... How much the keyspace is reduced depends on the unicity
distance.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Every heard of this device? NT Sentinel
Date: Thu, 21 Sep 2000 20:40:25 -0700
Northern Telecom Sentinel
Model # NTA005
Data Encryptor 2400 - 64Kbs
Thanks,
Mike
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: Thu, 21 Sep 2000 21:44:41 -0600
In article <[EMAIL PROTECTED]>, roger_95073@my-
dejanews.com says...
[ ... ]
> What if I (accdentally or deliberately) disconnected the battery
> in Vegas, and then reconnected when I got home. Then the phone
> would report that I had been in Vegas?
I'd have to look back to be sure -- the phone I was looking at has
both volatile and non-volatile memory. Offhand, I don't remember
which of these this particular data is stored in. Obviously enough,
if it's stored in the volatile memory, then removing all power will
destroy the contents, but if it's in the non-volatile memory,
removing power won't. As I said, I honestly don't remember which it
gets stored in though.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: IBM analysis secret.
Date: Thu, 21 Sep 2000 21:52:02 -0600
In article <8qe653$3gp$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Hi,
>
> I remember once reading about that IBM knew about differential analysis
> when analyzing DES 10 years before it was "discovered" by the science
> community, and kept it a secret for the count of the NSA.
>
> Now when I'm checking it up, it does not seen to be right at all.
It seems likely to be true to some degree or other. IBM had been
working on various ciphers under the Lucifer project, and most of
them prior to DES were/are subject to differential cryptanalysis.
DES appears to have been designed quite carefully to resist
differential cryptanalysis. What's somewhat less clear is exactly
who did the re-design to make it resistant -- TTBOMK, both the NSA
and IBM have been quite adamant that IBM designed the S-boxes, but
it's less clear whether they re-designed them after discovering
differential cryptanalysis on their own, or whether the NSA told them
about the attack and they re-designed it then, or whether they NSA
simply advised them that a re-design of a particular nature would
help it resist an attack they didn't know about yet.
In any case, it certainly appears that _somebody_ involved in the
design of DES knew about differential cryptanalysis long before it
became public knowledge. The only part that may be open to question
is whether the original discovery was by IBM, or NSA or exactly what.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: t
Date: Fri, 22 Sep 2000 04:40:47 GMT
On Thu, 21 Sep 2000 16:34:39 GMT, "John R."
<[EMAIL PROTECTED]> wrote, in part:
>> But the plot is cliched. I can guess how the book begins. Something
>> like:
>> T
>> NNT
>> NF
>> TOT
>> TOF
>> FOT
>> TIT
>> FIT
>> FIF
>> TET
>> FEF
>> TAT
>> LTR
>> LNNTR
>> LNFR
>> LTOTR
>> LTOFR
>> LFOTR
>> LTITR
>> LFITR
>> LFIFR
>> LTETR
>> LFEFR
>> LTATR
>> TALFOTR
>> NLLTAFROTR
>> NLFOFR
>> NLTIFR
>> NLTEFR
>> NLFETR
>> NLTAFR
>> NLFATR
>> NLFAFR
>Now, I am new to all this, and was wondering if someone could explain,
>or point me in the direction to understand it.
Each of these lines of text is a true statement. They're designed to
make it possible to figure out what the characters mean.
Thus, the original part
T
NNT
NF
makes sense if T stands for true, F stands for false, and N stands for
negation, as represented by ~ in Boolean algebra.
I then went on to introduce the basic operators: A for AND, O for OR,
I for implication, and E for equivalence (not XOR).
However, one can't really do much of consequence without parentheses,
and so I denoted ( and ) by L and R respectively.
So after the quoted part, I defined A, O, I, and E by showing all the
cases where they produced a true result. Then, I repeated everything I
said so far, but with parentheses around it, showing that nothing is
changed by them.
Then, I indicated what parentheses are for by showing that the two
statements
True and ( False or True )
and
not ( ( True and False ) or True )
... whoops.
Should have been
True or ( True and False )
and
not ( ( True or True ) and False )
instead:
TOLTAFR
NLLTOTRAFR
are both true.
Finally, with parentheses, I listed the false cases of the truth
tables for A, O, I, and E.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple hash function
Date: Thu, 21 Sep 2000 22:03:00 -0600
In article <[EMAIL PROTECTED]>, Jerry Coffin
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > dexMilano wrote:
> >
> > > I'm loloking a very simple/fast hash function to identify if a record in a
> > > table has been modified since last check.
> >
> > Hash functions are practically always approximate -- that is, you just
> > might get a false positive or negative.
>
> At least as usually used, a hash can only be wrong in one direction.
> The strings might be different even if the hashes are the same, but
> they strings are definitely different if the hashes are different.
>
A hash may indicate changes, but might not do so. Depending on the hash,
it might take little difference in inputs to get the same outputs, or a
trivial change can be made to almost guarantee a change in output as two
grossly different inputs might be necessary to see identical outputs. A
good hash will be like the latter.
--
A Pangram: 57) *The Codebreakers often views juxaposed
cryptological maze quests.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 22 Sep 2000 04:52:14 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
>> >Tim Tyler wrote:
>> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> >> : If my message is over one hundred bytes, do you think
>> >> : that I need to care about wasting 5 bits?? [...]
>> >>
>> >> At worst, this can reduce the size of keyspace by a factor of 32.
>> >
>> >Sorry, I don't understand. What do you mean by 'keyspace'
>> >here? This is the message space. The message gets longer
>> >by 5 bits. There is no information in the above of how
>> >big the key is. Do I loose or gain security by, say,
>> >always appending 5 0's to the ciphertext?
>>
>> I thought we are talking about compressing then ecnrypting.
>> If you always add 5 zeros or any other fixed amount of bits
>> after a compressed string or any file for that matter which is
>> then encrypted. The attacker know what the last few bits are
>> and throws out keys that don't match. So if the last five bits
>> of a file are known then it means you reduce your key space by
>> 5 bits.
>
>Reducing the message space by x bits does *not* reduce the keyspace by x
>bits... How much the keyspace is reduced depends on the unicity
>distance.
>
There was nothing in the previous message to suggest what you
claimed. What was in the message was if you know what certain bits
are. Then that can reduce the key space.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 22 Sep 2000 04:50:28 GMT
On 21 Sep 2000 13:24:32 -0700, [EMAIL PROTECTED] (Gregory G Rose)
wrote, in part:
>In article <[EMAIL PROTECTED]<,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]< wrote:
><<<An alternative - which I've not seen discussed on this forum - would be
><<<to use an encryption device which is capable of encrypting variable
><<<length bitstrings, and is not confined to multiples of 8 bits. I
><<<attribute this idea to David Scott.
>There is nothing new in this idea. Shame on you,
>John, egging him on like that.
I quite agree that that is not a new idea; it's Tim Tyler who made
that claim.
>The MD4 hashing algorithm specification is written in terms of
>arbitrary bit strings, which are padded
>unambiguously with a single '1' followed by as
>many zeros as are required. This document dates to
>the early 80's IIRC, anyway, long before D.A.S.
>was around. The real inventor is shrouded in
>history or NSA/GCHQ, but Ron Rivest clearly has a
>better claim.
I think that this, used for padding to even bytes, was out there long
before hash algorithms. For example, computer programs to translate
ASCII to Morse Code represented . by 01000000, - by 11000000, .. by
00100000, .- by 01100000, and so on at least from the dawn of the
microcomputer era. (That way, one takes the first bit as 0=dot,
1=dash, shifting left to get succesive bits, but stopping when
10000000 is reached.) And originality wasn't claimed even then; I'm
quite sure such techniques are as old as the IBM 650.
But that is a separate idea from that of just doing the encryption on
bit boundaries. Doing binary encryption which is not confined to
groups of 8 bits, of course, could be said to date back to Sir Francis
Bacon, since he used 5-bit characters, but that would be stretching
too far.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: XOR
Date: Fri, 22 Sep 2000 04:53:18 GMT
On Thu, 21 Sep 2000 23:10:36 -0700, Nikica Guscic <[EMAIL PROTECTED]>
wrote, in part:
>Hey... what would be an standard attack on an binary XOR encription.
Depends what the encryption is XORing the message with. Because that
is where the real cipher is.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: t
Date: Fri, 22 Sep 2000 04:54:43 GMT
On Thu, 21 Sep 2000 19:20:28 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Didn't you see the result of the decompression being
>done in this thread? That's only the beginning of the
>gigabyte, of course :-)
But that was really Douglas Gwyn's message that I decrompressed.
The original message probably decompresses to something entirely
different. But I see the name "Tinky Winky" in there somewhere.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: t
Date: Fri, 22 Sep 2000 04:52:03 GMT
On Thu, 21 Sep 2000 22:12:42 GMT, Darren New <[EMAIL PROTECTED]> wrote,
in part:
>Actually, as long as they're made of matter and not antimatter, there are
>experiments one can do to make the distinction. I don't remember the
>details, tho. Something about beta decay or some such.
True; K-mesons.
But it's easier to cheat and send a circularly polarized radio wave.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: t
Date: Fri, 22 Sep 2000 02:39:46 -0400
John Savard wrote:
> I then went on to introduce the basic operators: A for AND, O for OR,
However, at that point you deviated from the plan of the book,
which was to define (contextually) each new symbol in a single
"expression" (isolated sequence of symbols, 1 per page).
> However, one can't really do much of consequence without parentheses,
Wrong, haven't you heard of "Polish notation"?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Revilo P. Oliver: Cryptanalyst?
Date: Fri, 22 Sep 2000 03:06:13 -0400
John Savard wrote:
> However, the other day, I happened across a web site devoted to his
> works. In his biography there, it was noted that during the war he
> worked for a "highly secret cryptographic agency of the War
> Department" during World War II.
Whose War Department? It's clearly either a pseudonym or the result
of parents' warped sense of humor; the main question is who wrote
under that name (if a pseudonym it may have been more than one person).
You can't believe everything you read on the Web; among other
bibliographical information given for RPO is that he was a founder of
the John Birch Society, which seems not to be true. It could be an
elaborate hoax.
------------------------------
Date: Fri, 22 Sep 2000 09:21:30 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: t
lala wrote:
>
> t
This NG is really surprising me... such a big thread about such
a silly (aborted ?) posting...
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: t
Date: Fri, 22 Sep 2000 10:04:07 +0200
John Savard wrote:
>
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Didn't you see the result of the decompression being
> >done in this thread? That's only the beginning of the
> >gigabyte, of course :-)
>
> But that was really Douglas Gwyn's message that I decrompressed.
>
> The original message probably decompresses to something entirely
> different. But I see the name "Tinky Winky" in there somewhere.
The sum of this thread is going to be the goal result
of decompression giving one gigabyte.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Fri, 22 Sep 2000 10:27:24 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Benjamin Goldberg) wrote:
> <[EMAIL PROTECTED]>:
>
> >SCOTT19U.ZIP_GUY wrote:
> >> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >> >Tim Tyler wrote:
> >> >> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >> >> : If my message is over one hundred bytes, do you think
> >> >> : that I need to care about wasting 5 bits?? [...]
> >> >>
> >> >> At worst, this can reduce the size of keyspace by a factor of 32.
> >> >
> >> >Sorry, I don't understand. What do you mean by 'keyspace'
> >> >here? This is the message space. The message gets longer
> >> >by 5 bits. There is no information in the above of how
> >> >big the key is. Do I loose or gain security by, say,
> >> >always appending 5 0's to the ciphertext?
> >>
> >> I thought we are talking about compressing then ecnrypting.
> >> If you always add 5 zeros or any other fixed amount of bits
> >> after a compressed string or any file for that matter which is
> >> then encrypted. The attacker know what the last few bits are
> >> and throws out keys that don't match. So if the last five bits
> >> of a file are known then it means you reduce your key space by
> >> 5 bits.
> >
> >Reducing the message space by x bits does *not* reduce the keyspace by x
> >bits... How much the keyspace is reduced depends on the unicity
> >distance.
> >
>
> There was nothing in the previous message to suggest what you
> claimed. What was in the message was if you know what certain bits
> are. Then that can reduce the key space.
I was dealing in fact with both points. My end of file
and random filling lengthens the input to the encryption
and hence that of the ciphertext. That percentage of
increase in length for transmission is negligible
in general. That was the content of the first follow-up
answering to your posting. Do you still have question
to that? Subsequently, Tim Tyler put up the issue of
keyspace, which is entirely strange in this context. So
I argued that it should be the message space. But I
also thought about what could be leading him to the
matter of 'keyspace' at all. One very faint chance could
be, I imagine, that he was thinking about the fact that
if a single key is used to encrypt, then there could be
a problem if too much materials get processed with that.
But in my case only a tiny little more addition is
present. So I constructed an simple example to show that
couldn't be the case. (Simple because one doesn't have
to meddle with encryption, but just append something.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Proper way to intro a new algorithm to sci.crypt?
Date: Fri, 22 Sep 2000 10:42:21 +0200
Mack wrote:
>
> >Albert Yang wrote:
> >>
> >> Can anybody give me a quick run-through of the proper way to introduce a
> >> new algorithm to Sci.crypt?
> >
> >I think it is conceivable that responses you have got
> >are not very satisfactory for your original need. Thus
> >I'll try a bit on my part to see if I could eventually
> >do better:
> >
> >Give a good English description of your algorithm.
> >To ease comprehension, you may do it in two phases.
> >In the first phase, give a concise sketch, indicating
> >what you think are the specically interesting
> >features of you cipher. In the second phase, give
> >sufficiently detailed elaborations such that
> >a third person with good programming experiences
> >can independently do an implementation. If you
> >employ some constants, explain exactly how you have
> >obtained these, so that others may reproduce them
> >and hence it is clear that there are no backdoors
> >behind these constants. (Don't follow the very bad
> >examples of DES and AES in this connection!) If
> >something is well described in an easily accessible
> >paper, it is sufficient to simply provide a reference
> >and assume that the reader knows it. Soruce codes
> >need not be provided and are in fact undesirable
> >for bandwidth reason. To better illustrate some
> >intricate points, you could use some short pieces
> >of pseudo-code. Never post examples of ciphertext
> >with challenges for others to crack. Nover vaunt
> >that your cipher is unbreakable or that your ideas
> >are genious or revolutionary, for these are
> >certainly illusions stemming from one's own limited
> >knowledge.
>
> But then noone will pay any attention to it. Better to
> be an infamous newbie wacko than an un-noticed
> blip in the sci.crypt postings.
>
> Of course if you really get a NEW idea and write a
> scientific paper about it, then you could try posting
> to sci.crypt.research.
>
> That is the moderated version of sci.crypt. It hasn't
> seen much activity lately.
>
> But be forwarned the standard there is VERY HIGH.
> Slight errors may disqualify it from being posted.
> Also anything that smells the slightest of snake-oil
> or advertising will probably be file 13ed.
What I said is for the author to consider how to best
formulate his post so that the article is easily
understandable and results in as little unnecessary
debates due to misunderstanding as possible. It does
not suppress anything! It is all subjected to the
author's subjective judgement how well his paper
corresponds to my recommendations. If e.g. an author
claims and himself firmly believes his cipher to be
indeed the single best of the world that can ever
exist and considers therefore that my recommendation
in this connection is not applicable, then be it.
M. K. Shen
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: IBM analysis secret.
Date: Fri, 22 Sep 2000 01:31:36 -0700
Jerry Coffin wrote:
> DES appears to have been designed quite carefully to resist
> differential cryptanalysis. What's somewhat less clear is exactly
> who did the re-design to make it resistant -- TTBOMK, both the NSA
> and IBM have been quite adamant that IBM designed the S-boxes, but
> it's less clear whether they re-designed them after discovering
> differential cryptanalysis on their own, or whether the NSA told them
> about the attack and they re-designed it then, or whether they NSA
> simply advised them that a re-design of a particular nature would
> help it resist an attack they didn't know about yet.
Don Coppersmith talked about this at Crypto 2000 last month. He said
that he created the S-boxes, but was a student intern and claimed
not to know the details of various maneuvering by higher-ups at
IBM and NSA. Eg, he claims not to know how the final S-boxes were
chosen.
He said they knew about differential cryptoanalysis in the sense
that the cipher should resist attacks where the inputs differ by
one bit. (This is not quite saying that they knew how to carry
out such an attack to break a cipher.)
The strangest part of Don's talk was that he implied that the
diff. crypto. info was a security leak from the NSA. He didn't have
a security clearance but felt a duty to keep his mouth shut about
it. He seemed not to know whether he was supposed to be told or not.
There were others at IBM on the project who had clearances. It
seems likely that NSA gave them classified info on how to choose
S-boxes. If Don was making the S-boxes, then he had to be told
somehow. Don implied that the leak was unauthorized, but it seems
just as likely to me that the leak was authorized.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Again a topic of disappearing e-mail?
Date: Fri, 22 Sep 2000 10:56:01 +0200
The following is in the ACM Technews:
Email users will soon be able to erase the messages they send
from the recipient's hard drive using software called SafeMessage
that a company called AbsoluteFuture is releasing today.
SafeMessage destroys messages within a certain amount of time
after the recipient opens them, erasing all footprints on PC
hard drives and computer servers, says AbsoluteFuture CEO Graham
Andrews. Law enforcement officials worry that criminals and
terrorists will use SafeMessage to conceal their communications,
arguing that fighting crime effectively in the digital age
requires email tracing. Meanwhile, privacy advocates applaud
the new software. One oil executive says he uses a beta version
of SafeMessage to prevent rivals from accessing his messages.
http://www.usatoday.com/usatonline/20000920/2662888s.htm
M. K. Shen
------------------------------
** 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
******************************
