Cryptography-Digest Digest #51, Volume #13 Mon, 30 Oct 00 20:13:01 EST
Contents:
Re: how do you decrypt something encoded by C=M^e(mod N) (Simon Johnson)
Re: [PGP] Twofish, 256bit, and Usenet Posting ("Michael Young")
Re: Calculating the redudancy of english? (Kenny Hutchings)
Re: Searching for a good PRNG (Tom St Denis)
Re: Searching for a good PRNG (Tom St Denis)
Re: how do you decrypt something encoded by C=M^e(mod N) (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: RSA Multiprime (Scott Contini)
Re: Padding scheme? (Tim Tyler)
shared secret signing using a hash... (Tony L. Svanstrom)
Re: Psuedo-random number generator (Tim Tyler)
Re: Searching for a good PRNG (David Schwartz)
Re: ciphertext smaller than blocksize (SCOTT19U.ZIP_GUY)
Re: Psuedo-random number generator (David Schwartz)
Re: XOR based key exchange protocol - flawed? (David Wagner)
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: how do you decrypt something encoded by C=M^e(mod N)
Date: Mon, 30 Oct 2000 23:57:15 GMT
In article <8tkunj$r70$[EMAIL PROTECTED]>,
"Pepitoe" <[EMAIL PROTECTED]> wrote:
> I don't know if im posting in right place, i have very little
knowledge of
> cryptography, but was interested in what i saw on a tv programme last
night
> (ch4 the science of secrecy if anyone english is reading), they gave
C=M^e
> (mod N) as a method of encryption where c is obviously the encrypted
output,
> m is letter's value, n is multiple of keys and e seemed to be just a
chosen
> power. I can understand how to use this to encrypt but i didn't see
how to
> decrypt, and my knowledge of maths so far (not finished a level yet)
doesn't
> let me work it out for my self (its probably simple but im not that
> clever!). So please explain a way to decrypt, if possible e-mail me
> [EMAIL PROTECTED] as i may not get a chance to visit this
newsgroup
> again in time to read any replies.
>
> Thanks for your help
> Pepitoe
>
>
Delighted to be of service.
C=M^e mod n -> is the encryption function as you stated. Now, with out
buring ourselves into a infinite pit of maths, basically, decryption is
the inverse of the encryption. Consider:
If our plain-text value was x, then we encrypt by:
F(x) = X^2+x+1
To decrypt, we would do F(X)*1/F(x) = X
You see what i'm getting at? (note: This construction is insecure). But
this is how RSA works (and it does it securely). Basically, If we do
C^d mod n, we recover m.
D is a constant like e, E cannot be derivied (easily) from D unless the
factors of N are known. If we set E to some prime, we can calculate D
like so:
d=e^(((p-1)(q-1))-1) mod (p-1)(q-1)
n.b. p and q are large primes, and form the factors of N.
So we can now use these trivially to encrypt and decrypt stuff. This is
slash and dash stuff, its in the FAQ, take a look if u please :P.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Young" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: [PGP] Twofish, 256bit, and Usenet Posting
Date: Mon, 30 Oct 2000 19:00:49 -0500
Thomas J. Boschloo wrote in message <[EMAIL PROTECTED]>...
... some wrong speculations about how PGP generates session keys,
and that it "doesn't sound safe".
OK, here's how PGP generates a session key from a passphrase,
when the hash function output is smaller than the required key:
The first segment of the key is generated by hashing the
passphrase and (optionally) a sequence of salt bytes, repeating
that combined byte sequence until some minimum number of
bytes have been hashed. (The hash algorithm, salt bytes,
and an encoding of this minimum number are stored/sent
with anything that will be decoded. PGP6 uses 64k for
the minimum.)
Each subsequent segment is generated by hashing a zero byte,
followed by exactly the same input to the previous hash.
That is, segment N (starting at 0) hashes N bytes of zeroes,
followed by the minimum number of key/salt bytes. The segments
are concatenated (with any excess discarded) to form the key.
The size of the hash function does not matter -- a single
output bit would suffice -- only its resistance to (specific)
related-input output-correlation attacks. I am unaware
of any such practical attacks against SHA-1. Anyone?
------------------------------
From: [EMAIL PROTECTED] (Kenny Hutchings)
Subject: Re: Calculating the redudancy of english?
Date: Tue, 31 Oct 2000 00:18:02 +0000
Simon Johnson <[EMAIL PROTECTED]> wrote:
> How does one calculate the redudancy of english?
>
Well, essentially, I can convey the fact that I want another beer to my
friend across the room while we're watching a film on TV WITHOUT in any
way disturbing the members of the room in between us and thus killing
any atmosphere that might have been built by the film, using a mere wave
of the hand or a carefully measured impact of the empty bottle on the
coffee table. So in that sense, me using the phrase "Could you get me
another beer?" is entirely 100% redundant. I think I could probably
survive sufficiently happily in life on a continuous supply of beer and
movies, at least for a satisfactory length of time, thus I conclude that
ALL English is entirely redundant. I wonder why I'm wasting my time
typing this. Perhaps we should rmgroup the entire news hierarchy and
shut down the servers. Everyone knows those complicated worldly RAID
arrays and 24 hour high-powered NNTP servers could be put to much better
use. I don't have to tell a group full of cryptos that.
> --
> Hi, i'm the signuture virus,
> help me spread by copying me into Signiture File
>
This must be one of those polymorphic Sign(a/i/u)ture viruses or
something.
K.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Tue, 31 Oct 2000 00:08:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
> :> : Tom=E1s?= Perlines 1Hormann <[EMAIL PROTECTED]> wrote:
>
> :> :> I am searching for a good PRNG in software, preferrable for
FREE.
>
> [...]
>
> :> :> Does anybody know a good URL???
> :>
> :> : http://www.fourmilab.ch/hotbits/generate.html
> :>
> :> : :-)
> :>
> :> That may be a good URL - but to save people visiting it
> :> unnecessarily, it is linked to a hardware RNG which you can access
> :> over the web.
>
> : What is your point?
>
> I thought I had expressed it clearly. What is in need of
clarification?
Exactly why are hotbits not a good source of random bits?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Tue, 31 Oct 2000 00:09:36 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
> The point is that this is great for statistical randomness but
useless
> for cryptographic randomness.
Cryptographic purposes was not the OP intent AFAIK. So what's wrong
with my post?
---op post---
Hi!
I am searching for a good PRNG in software, preferrable for FREE. I
know that there is a big discussion going on about where to get
possibly good PRN out of a computer (mouse, thermal noise, etc.)
My only requirement is to not have the user worrying too much with such
stuff. The generation of PRN should be transparent to anybody.
Does anybody know a good URL???
TIA...
---op post---
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: how do you decrypt something encoded by C=M^e(mod N)
Date: Tue, 31 Oct 2000 00:11:59 GMT
In article <8tl1sn$g38$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <8tkunj$r70$[EMAIL PROTECTED]>,
> "Pepitoe" <[EMAIL PROTECTED]> wrote:
> > I don't know if im posting in right place, i have very little
> knowledge of
> > cryptography, but was interested in what i saw on a tv programme
last
> night
> > (ch4 the science of secrecy if anyone english is reading), they gave
> C=M^e
> > (mod N) as a method of encryption where c is obviously the encrypted
> output,
> > m is letter's value, n is multiple of keys and e seemed to be just a
> chosen
> > power. I can understand how to use this to encrypt but i didn't see
> how to
> > decrypt, and my knowledge of maths so far (not finished a level yet)
> doesn't
> > let me work it out for my self (its probably simple but im not that
> > clever!). So please explain a way to decrypt, if possible e-mail me
> > [EMAIL PROTECTED] as i may not get a chance to visit this
> newsgroup
> > again in time to read any replies.
> >
> > Thanks for your help
> > Pepitoe
> >
> >
> Delighted to be of service.
>
> C=M^e mod n -> is the encryption function as you stated. Now, with out
> buring ourselves into a infinite pit of maths, basically, decryption
is
> the inverse of the encryption. Consider:
>
> If our plain-text value was x, then we encrypt by:
>
> F(x) = X^2+x+1
>
> To decrypt, we would do F(X)*1/F(x) = X
>
> You see what i'm getting at? (note: This construction is insecure).
But
> this is how RSA works (and it does it securely). Basically, If we do
> C^d mod n, we recover m.
>
> D is a constant like e, E cannot be derivied (easily) from D unless
the
> factors of N are known. If we set E to some prime, we can calculate D
> like so:
>
> d=e^(((p-1)(q-1))-1) mod (p-1)(q-1)
Not to be super picky... but ...
d = e^(lcm(p-1, q-1) - 1) mod lcm(q-1, p-1)
:-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 31 Oct 2000 00:22:46 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (John Savard) wrote in
>: <[EMAIL PROTECTED]>:
>
>:>Here I am in difficulty in understanding the specifics, but I think I
>:>may be more in agreement with Mr. Tyler here. In fact, this is
>:>precisely the point on which I've found Mr. Scott's bijective scheme
>:>flawed when he converts a compressed file to one with a length that is
>:>an integer number of octets.
>
>: What you fail to understand is that it is not a flaw.
>
>I was under the impression that your original Huffmann compression routine
>exhibited a bias in the final byte, when applied to sets of random inputs
>(e.g. usenet news messages).
Yes I belive you did find a bias based on compressing usenet
messages. But that still does not take away from the fact that
any byte value could have been used as the last byte of compressed
text and that it would still correctly decompress and recompress.
I think this is an artifact of the optimal endings. You could hide
it by using my focused huffman compression but its still there in
one form or the other.
>
>This meant that the last bits were more likely to be zeros than ones.
>
>I tested it to see if this was the case, and observed this effect.
>
>I regard this as a flaw - and it is a problem that John's scheme
>avoids.
>
>After some reflection, I believe the problem is specific to your ending
>method - I don't think other 1-1 methods are necessarily flawed in the
>same way.
John methods are not 1-1 and he changes the distribution by adding
random numbers. The biasis comes in during the coversion of the fintiely
odd files to one of some fixed structure such as 8 bit groupings. If
one looks at fintiley odd files then each in case a file 1 bit longer
allows twice as many files for each bit. In this sense its not biased
however if you look at a ranges of file that your encrypting they don't
increase this way so there are many more with a trailing bit of zero.
Suppose there is a bijective way to end the file that does not have
my biase as you call it. Then there would still be a way to convert
that ending to mine so that all an attacker would have to do is transform
it to one of my endings and look at the last bit there. You can use
my focused or something simailar based on all presvious characters
to slow the check down though if you wished. But the point is no
information is added so what information I have that could be part of
a flaw would still have to exist in some form in another 1-1 bijective
method that fits the file to the same space. Check my focused huffman
the way you did the other one and see if you see the same biass.
>
>:>A file indeed has length as one of its properties. If you add bits to
>:>a file which encode its length, and then encrypt the result, you
>:>haven't added _information_ to the file, but precisely because you
>
>: That is where your logic is wrong. If your add bits to a file you
>: do add information to a file that can be exploited.
>
>This isn't information in the traditional sense of "suprise value".
>Someone with the file already knows how long it is. If you append
>the length of a file to a file 1000 times, that adds precious little
>information that was not already known. John's use of "information"
>is quite orthodox.
>
>:>Thus, I've noted that the standard technique of including length
>:>information in a file before encryption would be, where compression
>:>produces a file with an arbitrary length in bits, but the file is to
>:>be, for whatever reason, padded out to whole bytes before encryption
>:>(presumably for convenience in programming) is: add _exactly three_
>:>bits to the file, to give only the information of the file's length
>:>modulo 8, and then _destroy_ the other "copy" of that information by
>:>padding the file with random bits.
>
>: The fact is this is not needed [...]
>
>That appears to be true. It adds up to 8 bits unnecessarily,
>and requires the use of a genuine random number generator.
>
>Apart from these points, it has the virtue of being quite simple.
>
>:>From his descriptions of his scheme - despite his pleas, I have not
>:>considered it worthwhile to delve into his C code - it appeared to me
>:>that what he was proposing for "Bijective Huffman" was equivalent to
>:>the standard hash function technique of padding with 1000...000. Which
>:>does create a unique encoding, but which is biased [...]
>
>Scott's code is vastly more sophisticated than that.
>
>You can read a description of what he did (without looking at his code)
>by visiting http://members.nbci.com/_XOOM/ecil/compres1.htm
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] (Scott Contini)
Subject: Re: RSA Multiprime
Date: 31 Oct 2000 00:29:13 GMT
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
>
> While a neat thing, I am not all that fond of multiprime moduli. But
>that's just me.
>
A neat thing? Are you kidding me? The so-called "multi-prime" variation
of RSA is an entirely obvious generalization to RSA that every researcher
knew about. Nobody ever patented the idea until Compaq since:
1. It is so obvious it should not be patentable.
2. While it gives some speedups, it opens up the algorithm
to possible new attacks: if a faster special purpose algorithm
than the elliptic curve method is invented, then multi-prime
RSA easily could become insecure.
The only thing more ridiculous than Compaq patenting this is RSA Security
licensing the patent. I guess it is RSA's attempt to find new, faster
ways of doing private key operations while avoiding ECC. However they are
missing many of the other points of the benefits of ECC: smaller key sizes,
less bits that need to be communicated for key exchanges, and somewhat
efficient operation on 8-bit processors without a coprocessor. If you're
concerned about the speed of private key operations, my recommendation
is to use ECC (for security concerns, use a randomly generated curve)
If you're not concerned about the speed of private key operations, then
regular RSA is good enough and more trustworthy for long term security
than this multi-prime trash.
Scott
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Padding scheme?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Oct 2000 00:15:05 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
: SCOTT19U.ZIP_GUY wrote:
:> [EMAIL PROTECTED] (Benjamin Goldberg) wrote in
:> <[EMAIL PROTECTED]>:
:> >After having read some other recent stuff on this group discussing
:> >padding, I realize that a trojan horse type program could use the
:> >random padding as a subliminal channel. To avoid this, the padding
:> >should, instead of being random, be the first bytes and bits from a
:> >cryptographicly secure hash of the message. [...]
:>
:> Yes this might be valuable if the padding is applied in some purely
:> bijective way so that the result is still fully bijective. [...]
: Although it's true that using bits from a hash, rather than bits from a
: TRBG, does create a bijective mapping from the set of messages whose
: lengths are multiples of 8 bits to the set of messages whose lengths are
: multiples of 128 bits [...]
s/true/false/
You've just added a redundant section to the message. A bit like cutting
the first few characters and pastuing them onto the end of the file.
No bijective map is likely to be found there.
: there is no significant difference in security between the original
: 1-to-many mapping and the hash-based 1-to-1 mapping.
You don't rate that ability to reject keys on the basis of their
having appended padding in the form of hash data (that doesn't
match the contents of the message) as a security risk?
Don't expect folks like me or David to agree with that.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Subject: shared secret signing using a hash...
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Tue, 31 Oct 2000 00:42:29 GMT
Sorry for the slightly missleading subjectline, but "me english no good,
me no know how write what me want"... :-)
Basically I'm looking for information (URLs would be fine) about using
hash-algorithms to secure information one way or another beyond the way
that those algorithms usually are used. An example would be "shared
secret signing" where you padd the string you're signing with a string
that is the shared secret, to get the signature; like:
$data = 'this is the string';
$signature = md5_base64 "[this is the secret] $data";
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
on the verge of frenzy - i think my mask of sanity is about to slip
---���---���-----------------------------------------------���---���---
\O/ \O/ �99-00 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Reply-To: [EMAIL PROTECTED]
Date: Tue, 31 Oct 2000 00:18:49 GMT
David Schwartz <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> David Schwartz <[EMAIL PROTECTED]> wrote:
:> : Terry Ritter wrote:
:> [consider true quantum randomness in the offsets between the CPU
:> oscillator and the clock oscillator on a network card. This can be
:> measured in software.]
:>
:> :> Oh, please. Your claim was for "true quantum randomness." If you had
:> :> that sort of randomness you would not need an MD5 checksum.
[snip]
:> If you're involving MD5 any claim for "true randomness" is moot - the
:> result will not be balanced and won't have exactly maximal entropy -
:> even if the inputs are perfectly random.
: Who said anything about being balanced or having exactly maximal
: entropy? I'm talking about having sufficient entropy for cryptographic
: purposes, nothing more, nothing less.
Ah. Whenever "true" gets mentioned in connection with randomness,
I imagine a stream that will not just defeat plausible human attackers -
but will defeat all possible attackers.
If this isn't what you meant by the term, that's fine - now you have said
what you mean.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Searching for a good PRNG
Date: Mon, 30 Oct 2000 16:43:30 -0800
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Schwartz <[EMAIL PROTECTED]> wrote:
> >
> > The point is that this is great for statistical randomness but
> useless
> > for cryptographic randomness.
>
> Cryptographic purposes was not the OP intent AFAIK. So what's wrong
> with my post?
If you're right, this is all off-topic for sci.crypt. I prefer to give
the OP the benefit of the doubt. ;)
DS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ciphertext smaller than blocksize
Date: 31 Oct 2000 00:50:42 GMT
[EMAIL PROTECTED] wrote in <8tl1c9$fkv$[EMAIL PROTECTED]>:
>[snip my statement that the entropy of the key is diffused into the
>plaintext in the creation of the ciphertext]
Actually the word entropy not in your previous message so your
lying plain and simple.
Entropy is more a funtion of the possible message density.
If its one per bit then you have maximum entropy in the shanon
sense. I am not sure where your trying to take this.
But if I have a one bit key. where I multipy by 1 or -1. I still
would not say I physically added information to the file.
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: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Mon, 30 Oct 2000 16:52:07 -0800
Tim Tyler wrote:
> : Who said anything about being balanced or having exactly maximal
> : entropy? I'm talking about having sufficient entropy for cryptographic
> : purposes, nothing more, nothing less.
>
> Ah. Whenever "true" gets mentioned in connection with randomness,
> I imagine a stream that will not just defeat plausible human attackers -
> but will defeat all possible attackers.
That's what I'm talking about. However, that doesn't require that the
random stream have maximal entropy or be unbiased. A billion bits where
one in a thousand is a one is not unbiased and running an MD5 on it
won't keep maximal entropy, but still you have cryptographically strong
randomness that will defeat all attackers.
All you need is some component that no attacker can predict. Even if
that's just one bit and you don't know exactly which bit, you can repeat
the process until you enough bits that they can't be brute forced and
use algorithms like SHA1 and MD5 to ensure that the unpredictability
gets used where you need it.
> If this isn't what you meant by the term, that's fine - now you have said
> what you mean.
I've been quite clear. Some people seem to find it entertaining to
deliberately misrepresent my claims.
DS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: XOR based key exchange protocol - flawed?
Date: 31 Oct 2000 01:04:23 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Mike Connell wrote:
>Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key Pi.
>Xa, Xb are random blocks of data of the same size as the public keys.
>
>1. a -> b : Pa
>2. a <- a : Pb
>3. a -> b : (Xa)Pb
>4. a <- b : (Xb)Pa
>
>Then a and b compute the XOR of Pa,Pb,Xa,Xb.
I don't understand the "MITM attacks" others are posting on your scheme.
If you don't have any way to validate the public key that the other
guy is using, then any authentication protocol you use will be
susceptible to a MITM attack. That's just unavoidable, and is not
a flaw of the authentication protocol.
The point is that secure authentication protocols tell you, at the
end of the protocol run, who you are talking to. An attack is where
the malicious guy Mallet can get you to think you are talking to Alice
when in fact you are really talking to Mallet.
It is NOT an attack if at the end of the protocol you think you are
talking to Mallet and you are correct in this belief. If you send
secrets to Mallet, knowing that it is her that you're sending them to,
well, that's not the fault of the authentication protocol.
In this case, when the protocol completes, I think you always know
the public key of the other person you are talking with. There are
other issues (like replay attacks), but I don't think MITM attacks
is one of them.
Am I missing something?
------------------------------
** 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
******************************
