Cryptography-Digest Digest #135, Volume #14 Fri, 13 Apr 01 12:13:00 EDT
Contents:
Re: Endianness of MARS (Mok-Kong Shen)
Re: Ethernet & Encryption (Mok-Kong Shen)
Re: Black & white .gifs? (Ben Smith)
Re: RSA modulus size and bits (Paul Schlyter)
Re: RSA modulus size and bits (Mok-Kong Shen)
Re: Black & white .gifs? (Mok-Kong Shen)
Re: Endianness of MARS ("Tom St Denis")
Re: RSA modulus size and bits (Michael J. Fromberger)
Re: Graphical representation of a public key (or fingerprint)? (Mok-Kong Shen)
Re: RSA modulus size and bits ("Tom St Denis")
Re: Ethernet & Encryption ("Trevor L. Jackson, III")
Re: XOR TextBox Freeware: Very Smooth. ("Trevor L. Jackson, III")
RSA CRT key? (massimo piccinetti)
Re: XOR TextBox Freeware: Very Smooth. (Lissi)
Re: NSA-Endorsed Schools have a Mediocre Internet Presence (Mok-Kong Shen)
Re: Elliptic Curves (DJohn37050)
The 13th...:) ("Frog2000")
Re: RSA CRT key? (Doug Stell)
Re: I got accepted (Mok-Kong Shen)
Re: XOR TextBox Freeware: Very Smooth. ("Sam Simpson")
Re: Dynamic Substitution Question ("B. E. Busby")
Re: Endianness of MARS ("Brian Gladman")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Endianness of MARS
Date: Fri, 13 Apr 2001 15:08:30 +0200
Brian Gladman write:
>
> MARS and Rijndael are essentially byte oriented ciphers that do not exhibit
> endian properties in a direct way.
Dumb question: Does anyone have a list of modern processors
(names of popular manufacturers) that employ big and small
endians respectively? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Ethernet & Encryption
Date: Fri, 13 Apr 2001 15:14:36 +0200
Tom St Denis wrote:
>
> Heck I don't know what some of them mean to this day.
A little bit ironic for a crypto group reader nonetheless.
M. K. Shen
------------------------------
From: Ben Smith <[EMAIL PROTECTED]>
Subject: Re: Black & white .gifs?
Date: Fri, 13 Apr 2001 23:17:28 +1000
On Thu, 12 Apr 2001, Stephen wrote:
> Does anyone know where I can find a supply of black & white .gifs on the
> net, so I can use steganography on them?
> Any help would be great thanks!!!
A friend of mine has a brilliant (if idiosyncratic) comic site -
http://www.geocities.com/needleandthreadcomic
He's also a keen amateur cryptographer, so would probably enjoy the steg
aspect of his art.
ben
--
Always - what does that mean?
Forever - what does that mean?
It means we'll manage
-- Tricky, Christiansands
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: RSA modulus size and bits
Date: 13 Apr 2001 14:13:54 +0200
In article <9b4nck$hvu$[EMAIL PROTECTED]>, Full Name <[EMAIL PROTECTED]> wrote:
> What does one exactly mean by a 1024-bit RSA modulus? More precisely,
> must such a modulus have its 1024th bit necessarily set to 1?
Yes. And preferably a few additional bits after that should be
set to 1 too .... see below.
> If not, how much leeway does one have when choosing a 1024-bit modulus?
> That is, how many leading zero bits is one to tolerate?
None! A "1024-bit modulus with one leading zero bit" is really a
1023-bit modulus; a "1024-bit modulus with two leading zero bits" is
really a 1022-bit modulus -- etc etc.
The point here is this: If your original cleartext is E0 and your
decrypted cryptotext is E1, and if you do:
C = E0 ^ e mod n
E1 = C ^ d mod n
then you'd expect that E1 = E0, but in reality E1 = E0 mod n
Of course if E0<n then E0 = E0 mod n and E1 = E0 as expected.
But if E0 >= n there will be problems: E1 will then be different
from E0. There are two different ways to cope with this:
1. Make sure that E0 never becomes >= n. This means n should be as
large as reasonably possible, i.e. at least its highest bit should be
set to one. If your cleartext is ASCII characters which will have
their high bits set to zero, this will be enough to ensure that E0
always is smaller than n. And if your cleartext is some data smaller
than the keysize which is to be padded with random bytes (a common
situation when dealing with digital signatures), then pad the highest
bytes and set the highest bit to zero to ensure that E0 always is
smaller than n. Finally, if your cleartext is binary data where the
highest bit(s) can be one, then you must select a modulus n with
enough initial bits set to one to ensure that E0 always is smaller
than n.
2. Don't bother trying to make n always larger than E0. Instead
check E1, the result of the decryption: if E1 is correct, you've
succeeded. If not, try to add n to E1 repeatedly until either E1
becomes correct or until E1 overflows above the key size -- in the
latter case you've either used the wrong key, or else the encrypted
data has become corrupted. This method of course requires that there
is a way to determine whether a decryption produces correct data or
not, i.e. the cleartext binary data must then have some structure
which makes an integrity check possible.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RSA modulus size and bits
Date: Fri, 13 Apr 2001 15:25:19 +0200
Chenghuai Lu wrote:
>
> I think, the 1024th bit of modulus must be 1 because the modulus is the
> multiplication of two prime numbers( they are odd ).
In the context of the post you were referring to, bits
are counted from right to left.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Black & white .gifs?
Date: Fri, 13 Apr 2001 15:30:02 +0200
Ben Smith wrote:
>
> A friend of mine has a brilliant (if idiosyncratic) comic site -
> http://www.geocities.com/needleandthreadcomic
>
> He's also a keen amateur cryptographer, so would probably enjoy the steg
> aspect of his art.
I suppose that some painting software helps for stego
purposes, though I have no experience with such software.
(One needs no 'reference' pictures, if the pixels are
determined by PRNG.)
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Endianness of MARS
Date: Fri, 13 Apr 2001 13:36:40 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Brian Gladman write:
> >
>
> > MARS and Rijndael are essentially byte oriented ciphers that do not
exhibit
> > endian properties in a direct way.
>
> Dumb question: Does anyone have a list of modern processors
> (names of popular manufacturers) that employ big and small
> endians respectively? Thanks.
Intel: Little
Motorola: Big
MIPS: Both.
That's the general rule of thumb. Other processors like the Alpha and SPARC
... I dunno!
Tom
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: RSA modulus size and bits
Date: 13 Apr 2001 13:20:02 GMT
In <cPCB6.363$[EMAIL PROTECTED]> "Tom St Denis"
<[EMAIL PROTECTED]> writes:
>> In <[EMAIL PROTECTED]> Chenghuai Lu <[EMAIL PROTECTED]>
>writes:
>>
>> >I think, the 1024th bit of modulus must be 1 because the modulus is
>> >the multiplication of two prime numbers( they are odd ).
>>
>> >"Michael J. Fromberger" wrote:
>> The oddness of the primes has nothing to do with the high-order bit of
>> their product. If you multiply two arbitrary nonzero _even_ numbers,
>> whose bit-lengths sum to 1024, you'll still get the 1024th bit set.
>> (This would not be an RSA modulus, of course)
>Unless someone magically finds an even prime greater than two? ehhehee
Such a prime would be quite odd indeed! :)
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
"Heaven is right where you are standing, and that is the place to train."
-- Morihei Ueshiba
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Graphical representation of a public key (or fingerprint)?
Date: Fri, 13 Apr 2001 15:55:48 +0200
Michael Schmidt wrote:
>
> Maybe I haven't expressed myself clear enough in the first place.
> I'm looking for the other way round: Finding a distinct graphical
> representation of a binary value (the public key or its fingerprint).
>
> I'm thinking about the following scenario:
> Just as I compare now the PGP fingerprint of a communication parter's e-mail
> with the PGP fingerprint that I had received before printed on his business
> card, I would like to compare graphical representations rather than the
> fingerprint hex strings. A typical PGP fingerprint today has a length of 20
> byte. It appears quite unattractive and error-prone to completely compare it
> for each e-mail. I think that comparing graphical representations is simply
> more intuitive for humans.
>
> But, of course, the graphical representation has to meet certain
> requirements:
>
> - If the representation acts as a fingerprint (i.e. it compresses data
> like a hash), it has to be as collision-resistant as possible.
>
> - If the representation just represents the original (uncompressed) value,
> it has to show an immense value space, yet it has to be easily
> distinguishable for humans.
> This approach sounds less feasible, but it could be applied to the
> (numerical) fingerprint rather than the original value.
I guess that your idea is in principle related to a scheme
that lets users choose one of a number of figures/faces in
lieu of a password. (IBM has a patent that is general enough
to cover the said scheme, as I learned from a post
long time back.)
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RSA modulus size and bits
Date: Fri, 13 Apr 2001 13:59:27 GMT
"Michael J. Fromberger" <[EMAIL PROTECTED]> wrote in message
news:9b6ue2$bkh$[EMAIL PROTECTED]...
> In <cPCB6.363$[EMAIL PROTECTED]> "Tom St Denis"
> <[EMAIL PROTECTED]> writes:
>
> >> In <[EMAIL PROTECTED]> Chenghuai Lu <[EMAIL PROTECTED]>
> >writes:
> >>
> >> >I think, the 1024th bit of modulus must be 1 because the modulus is
> >> >the multiplication of two prime numbers( they are odd ).
> >>
> >> >"Michael J. Fromberger" wrote:
> >> The oddness of the primes has nothing to do with the high-order bit of
> >> their product. If you multiply two arbitrary nonzero _even_ numbers,
> >> whose bit-lengths sum to 1024, you'll still get the 1024th bit set.
> >> (This would not be an RSA modulus, of course)
>
> >Unless someone magically finds an even prime greater than two? ehhehee
>
> Such a prime would be quite odd indeed! :)
Arrg Pun attack!
Tom
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Ethernet & Encryption
Date: Fri, 13 Apr 2001 14:13:05 GMT
Latyr Jean-Luc FAYE wrote:
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote :
> > Two brief comments:
> >
> > First, you have not addressed the possibility of replay or
> denial-of-service
> > attacks. The combination of the two are especially pernicious given the
> > assumption that the secret keys are erased "when transmission is
> complete". An
> > attacker can kill off any session by replaying an end-of-session message.
>
> How can I secure this aspect ?
For point to point communication one uses a counter, and for out of order
delivery a window around the counter. Messages that fall behind the window are
ignored as replays. Messages that fall within the window are accepted.
Messages that fall ahead of the window advance the window and are accepted.
>
>
> > Second, it appears the nodes need to posses the central authority's public
> key
> > prior to the start of communication. It cannot be authenticated over the
> > network. IMHO this assumption should be explicit.
>
> I am sorry for my english but what the meanning of IMHO ?
A common net abbreviation: "In My Humble Opinion".
>
> The nodes do not have a central authority public key should they ?
Then how can they authenticate messages they get from the central authority? If
they discover the authority across the network, and node can masquerade as the
authority and compromise the system.
> If yes
> can I imagine the same public key at the start is never use then all nodes
> broadcast their own public key ?
Please amplify/rephrase this question, as I don't know how to respond.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR TextBox Freeware: Very Smooth.
Date: Fri, 13 Apr 2001 14:16:52 GMT
Anthony Stephen Szopa wrote:
> Either way, at no time is the original text ever written to disk. In
> both cases the original text is merely stored in RAM.
You wish. On a busy machine anything not explicitly locked down may be
written to disk. Have you performed the requisite research to determine
how to lock down memory and make it unswappable? Have you defeated the
debugger's crashdump capability, which typically writes all of memory,
locked or not, to disk?
Invincible ignorance marches on....
------------------------------
From: massimo piccinetti <[EMAIL PROTECTED]>
Subject: RSA CRT key?
Date: Fri, 13 Apr 2001 16:28:36 +0200
Hello,
can you tell me where i can find
the documentation of the algorithm ([Mil76])
to convert a RSAPrivateKey (modulus + private exponent only)
to a RSAPrivateCRTKey (modulus, exponent, p, q etc..)
thanks
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Lissi <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR TextBox Freeware: Very Smooth.
Date: Fri, 13 Apr 2001 16:27:47 +0200
On 13 Apr 2001 the suspect [EMAIL PROTECTED] said:
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message [snip]
Tom, please. Not again an endless thread whith ASS' unusable
snakeoil (he's in my killfile anyway). Set f'ups, ASS isn't
able to and x-posts without sense or reason.
F'up set to alt.hacker
Lissi
--
Life ain't fair, but the root password helps.
- BOFH
RTFFAQ: faq.althacker.org
PGP-Fingerprint:
F119 52A9 A520 B1C5 28B7 BDFE 2B72 9E38 479E 31CC
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NSA-Endorsed Schools have a Mediocre Internet Presence
Date: Fri, 13 Apr 2001 16:36:13 +0200
Tom St Denis wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> >
> > Frank Gerlach wrote:
> This thread is OT.
It appears that your criteria of on/off topic have
recently changed a bit. I personally wellcome that.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 13 Apr 2001 14:45:20 GMT
Subject: Re: Elliptic Curves
The papers are in the white papers section of the research section at
www.certicom.com
Don Johnson
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: The 13th...:)
Date: Fri, 13 Apr 2001 11:05:02 -0400
Hello...A prime day indeed. :)
--
http://welcome.to/speechsystemsfortheblind
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: RSA CRT key?
Date: Fri, 13 Apr 2001 14:58:17 GMT
On Fri, 13 Apr 2001 16:28:36 +0200, massimo piccinetti
<[EMAIL PROTECTED]> wrote:
>Hello,
>can you tell me where i can find
>the documentation of the algorithm ([Mil76])
>to convert a RSAPrivateKey (modulus + private exponent only)
>to a RSAPrivateCRTKey (modulus, exponent, p, q etc..)
Instead of discarding the primes, P and Q, and using only the
private exponent, D, the primes are retained and two related key
components are computed. These are the multiplicative inverses
of P and Q, P1 and Q1, using Euclid's Theorem, such that
(P*P1) (mod Q) = 1 and (Q*Q1) (mod P) = 1.
P1 = inverse of P: P1 = (P)^(Q-2) (mod Q)
Q1 = inverse of Q: Q1 = (Q)^(P-2) (mod P)
The private exponents (mod P-1) and (mod Q-1) are also computed.
Private Exponent D = 107: = 7 (mod 10) = 11 (mod 16)
The CRT method private key is:
[N, P, Q, P1, Q1, D (mod P-1), D (mod Q-1)]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: I got accepted
Date: Fri, 13 Apr 2001 17:01:14 +0200
Tom St Denis wrote:
>
[snip]
> I'm disapointed that some questions go unaswered here that
> should be answered though...
Don't forget that people in the group are not paid for
what they do. There is no obligations for them to answer.
Even challenges offering monetary rewards seem to have
no effects.
M. K. Shen
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR TextBox Freeware: Very Smooth.
Date: Fri, 13 Apr 2001 16:08:33 +0100
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> XOR TextBox is similar to its predecessor, XOR Utility Version 1.1,
> that simply performs the universally available logical XOR process
> on two files chosen by the user and outputs the resulting file.
>
> The difference is that XOR TextBox provides a textbox control for
> input and output. This textbox control can be used in two ways.
>
> First, a user can type text directly into the textbox and run the XOR
> process on this text and another file, outputting the resulting file.
>
> Or secondly, a file that has previously been through the XOR process
> using XOR TextBox can be reprocessed again with XOR TextBox and the
> result displayed directly into the textbox for viewing.
>
> Either way, at no time is the original text ever written to disk. In
> both cases the original text is merely stored in RAM.
>
> http://www.ciphile.com
>
> Downloads Currently Available web page
> VB6 Downloads web page
I downloaded your software, encrypted some text with the random passphrase
"Q8XUYZ�3P_R". Booted into DOS an searched the swap file and this same
passphrase appears in its entirety.
Explain? ;)
(Machine: An aging P166 w/16Mb RAM running (just ;) Win95)
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: "B. E. Busby" <[EMAIL PROTECTED]>
Subject: Re: Dynamic Substitution Question
Date: Fri, 13 Apr 2001 08:22:55 -0700
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> newbie wrote:
>
> > If it was published, give me just one reference. I will be glad to know
> > it.
>
> You published it here in sci.crypt.
Statutory rejection requires written publication.
> > > > You may patent my idea if you want.
Nope -- only an inventor is able to apply for a (US) patent.
> > >
> > > Where can I get some of what you are smoking? No one can patent
anything that
> > > has already been published. And no one can publish anything that is
obvious.
> > > "Your" idea is both published and obvious.
I think you meant no one may _patent_ something obvious.
>
>
The text of 35 USC �102 (statutory bars to patentability) and 103
(obviousness)
are appended hereinafter.
CITE 35 USC Sec. 102
01/06/97
EXPCITE TITLE 35 - PATENTS
PART II - PATENTABILITY OF INVENTIONS AND GRANT OF PATENTS
CHAPTER 10 - PATENTABILITY OF INVENTIONS
TEXT Sec. 102. Conditions for patentability; novelty and loss of right
to patent
A person shall be entitled to a patent unless -
(a) the invention was known or used by others in this country,
or
patented or described in a printed publication in this or a
foreign
country, before the invention thereof by the applicant for patent,
or
(b) the invention was patented or described in a printed
publication in this or a foreign country or in public use or on
sale in this country, more than one year prior to the date of the
application for patent in the United States, or
(c) he has abandoned the invention, or
(d) the invention was first patented or caused to be patented,
or
was the subject of an inventor's certificate, by the applicant or
his legal representatives or assigns in a foreign country prior to
the date of the application for patent in this country on an
application for patent or inventor's certificate filed more than
twelve months before the filing of the application in the United
States, or
(e) the invention was described in a patent granted on an
application for patent by another filed in the United States
before
the invention thereof by the applicant for patent, or on an
international application by another who has fulfilled the
requirements of paragraphs (1), (2), and (4) of section 371(c) of
this title before the invention thereof by the applicant for
patent, or
(f) he did not himself invent the subject matter sought to be
patented, or
(g) before the applicant's invention thereof the invention was
made in this country by another who had not abandoned, suppressed,
or concealed it. In determining priority of invention there shall
be considered not only the respective dates of conception and
reduction to practice of the invention, but also the reasonable
diligence of one who was first to conceive and last to reduce to
practice, from a time prior to conception by the other.
CITE 35 USC Sec. 103
01/06/97
EXPCITE TITLE 35 - PATENTS
PART II - PATENTABILITY OF INVENTIONS AND GRANT OF PATENTS
CHAPTER 10 - PATENTABILITY OF INVENTIONS
TEXT Sec. 103. Conditions for patentability; non-obvious subject matter
(a) A patent may not be obtained though the invention is not
identically disclosed or described as set forth in section 102 of
this title, if the differences between the subject matter sought
to
be patented and the prior art are such that the subject matter as
a
whole would have been obvious at the time the invention was made
to
a person having ordinary skill in the art to which said subject
matter pertains. Patentability shall not be negatived by the
manner in which the invention was made.
(b)(1) Notwithstanding subsection (a), and upon timely election
by the applicant for patent to proceed under this subsection, a
biotechnological process using or resulting in a composition of
matter that is novel under section 102 and nonobvious under
subsection (a) of this section shall be considered nonobvious if -
(A) claims to the process and the composition of matter are
contained in either the same application for patent or in
separate applications having the same effective filing date; and
(B) the composition of matter, and the process at the time it
was invented, were owned by the same person or subject to an
obligation of assignment to the same person.
(2) A patent issued on a process under paragraph (1) -
(A) shall also contain the claims to the composition of matter
used in or made by that process, or
(B) shall, if such composition of matter is claimed in another
patent, be set to expire on the same date as such other patent,
notwithstanding section 154.
(3) For purposes of paragraph (1), the term ''biotechnological
process'' means -
(A) a process of genetically altering or otherwise inducing a
single- or multi-celled organism to -
(i) express an exogenous nucleotide sequence,
(ii) inhibit, eliminate, augment, or alter expression of an
endogenous nucleotide sequence, or
(iii) express a specific physiological characteristic not
naturally associated with said organism;
(B) cell fusion procedures yielding a cell line that expresses
a specific protein, such as a monoclonal antibody; and
(C) a method of using a product produced by a process defined
by subparagraph (A) or (B), or a combination of subparagraphs
(A)
and (B).
(c) Subject matter developed by another person, which qualifies
as prior art only under subsection (f) or (g) of section 102 of
this title, shall not preclude patentability under this section
where the subject matter and the claimed invention were, at the
time the invention was made, owned by the same person or subject
to
an obligation of assignment to the same person.
>
>
>
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Endianness of MARS
Date: Fri, 13 Apr 2001 17:05:16 +0100
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Brian Gladman write:
>
> > MARS and Rijndael are essentially byte oriented ciphers that do not
exhibit
> > endian properties in a direct way.
>
> Dumb question: Does anyone have a list of modern processors
> (names of popular manufacturers) that employ big and small
> endians respectively? Thanks.
Intel champion the little-enders and Motorola the big-enders. Some
processors now offer a choice.
Unfortunately the Motorola 68k family messed up an otherwise perfect big
endian numbering scheme by chickening out and numbering bits within bytes
(and words) from the bottom up (i.e. little endian).
They paid for this inconsistency later when they introduced bit field
instructions since they were then forced to return to a consistent big
endian scheme. In consequence the bits in MC68k bit field operations are
numbered from the top of words downwards whereas bits in other instructions
are numbered from the bottom of words upwards :-(
Brian Gladman
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
