Cryptography-Digest Digest #930, Volume #10 Wed, 19 Jan 00 15:13:01 EST
Contents:
Re: RSA survey (Bob Silverman)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Bob Silverman)
Re: Help -Perl encryption (Paul Rubin)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Bob Silverman)
Re: LSFR (Mike Rosing)
Re: RSA survey ("Michael Scott")
Re: Is this stream cipher secure? (Paul Koning)
Re: LSFR (Scott Nelson)
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: RNG for OTPs during WWII ("Douglas A. Gwyn")
Re: Triple-DES and NSA??? ("Douglas A. Gwyn")
Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?) ("Douglas A. Gwyn")
Re: Blowfish & pi. (Dan Day)
Re: Beginners questions re-OTPs ("Douglas A. Gwyn")
Re: New Crypto Regulations ("John E. Kuslich")
Re: Java's RSA implimentation (larry)
Re: LSFR ("r.e.s.")
Re: New Crypto Regulations ("Douglas A. Gwyn")
Re: how to encipher ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Date: Wed, 19 Jan 2000 17:57:49 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (NFN NMI L.) wrote:
> <<A 1024 bit modulus is more than enough.>>
>
> When 512-bit moduli can be cracked by large corporations with enough
funds?
> Sorry. I want strength that will keep messages secure until I'm in
the cold,
> hard ground. Better too much than too little. Just you wait.
It never ceases to amaze me how much nonsense gets spouted by people
who are totally ignorant of the subject they are discussing.
Do you have any idea of how much harder 1024 bits is than 512?
Do you know the SPACE requirements for 512 bits? Do you know the SPACE
requirements for 1024 bits?
No? They how can you make ANY statement regarding whether 1024 bits
is sufficiently secure???
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Wed, 19 Jan 2000 18:09:00 GMT
In article <8637ni$7ii$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> In article <862sm9$vdb$[EMAIL PROTECTED]>,
<snip>
>
> I concur. But for the same reason I would never use a random
> EC curve
Huh? This is the first time I have *ever* seen anyone suggest that
a random curve is undesirable. In fact most experts I know suggest
that random curves are more desirable than structured curves precisely
because they have less structure to attack and exploit.
Please tell us why you have this belief.
> I could not see using a random prime.
Again, why? Please tell us what you think is wrong with randomly chosen
primes.
> RSA relies on
> this approach since primes are not "studied" ahead of use.
I can't understand what you are saying here. What does it mean to
"study" a prime? Also, what is the antecedent of the word "this"
in the phrase "this approach"?
>
> --
> The only vote that you waste is the one you never wanted to make.
> RICO- we were told it was a necessary surrender of our civil
liberties.
> Asset Forfeiture- the latest inevitable result of RICO.
> http://www.ciphermax.com/book
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Help -Perl encryption
Date: 19 Jan 2000 18:21:22 GMT
In article <85vvi2$1fl$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I'm looking for help in setting up an encryption system for a shopping cart
>in perl.
>
>It is for use after an SSL connection in order to keep the info safe on the
>server and when being collected over ftp.
>
>Once the information arrives on the ssl server I need to set a perl script
>to encrypt it using a strong system
Pipe the info through PGP with a public key, the private key for which
is stored off-system. In perl, you'd just say
open (OUT, "|pgp -e [whatever]") || die "pgp exec failed";
...
print OUT "name: $name\n creditcard: $card\n"; # or whatever
Of course then you have to install pgp, for example from www.pgpi.com.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Wed, 19 Jan 2000 18:24:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> There are many advantages of ECC over RSA. See my PKS '99 paper.
>
> Montgomery gave a talk at RSA 2000 on doing the matrix reduction on a
connected
> machine. Montgomery is one of the best in this area.
True.
Consider however:
Solving the matrix for a 1024 bit RSA key will take 6 x 10^6 times as
long as solving one for 512 bits and will require ~10 Terabytes of
memory to hold the matrix. That's about 100,000 machines each with
100 Mbytes of memory.
It took a Cray (roughly equivalent to 5 to 8 Pentium 500's) 10 days
to solve the matrix for RSA-512.
While I readily believe that one could probably get several hundred
PC's working in parlallel to solve the matrix, I also know that these
will NOT yield linear speedup. This has been proven repeatdly in many
experiments in many contexts involving large linear algebra problems.
And the speed improvement will fall off even further from linear as
more machines are added. Suppose a set of 1024 machines gives
a 350 fold speed improvement. Doubling the number of machines might
then yield only a 500 fold improvement over 1 machine.
The problem is that coupled matrix solving DOES NOT SCALE WELL.
Even if one could somehow get a 1000 fold speed improvement over a
CRAY, solving the matrix for 1024 bits will still take 60,000 days
(164 years!) Note that 1000 x Cray = 6000 to 8000 PC's *IF* linear
speedup can be achieved. I would be surprised if one could get more
than 10% efficiency from each machine if one hooked together 10,000
PC's. I would expect to need "about" 100,000 PC's to get "about" 1000
fold faster than a CRAY.
I do believe that one can get a parallel matrix solver that can handle
a 512-bit modulus in reasonable time. But it will NOT scale to the
point where one can do 1024-bits in reasonable time.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Wed, 19 Jan 2000 12:22:39 -0600
Rob Largent wrote:
> Now that you've triggered my curiosity about this, do you have
> any references on how to determine if the tap values for large bit
> value LFSR's are indeed maximal? I've always just trusted the
> tables.
It just has to be a primitive polynomial. That means it's both
prime and has "order" 2^n-1. To check if a polynomial is primitive
you first see if it's prime (really easy) then you take x to the
power of each factor in 2^n-1 modulo the polynomial and see if you
get 1. You need all the combinations of all the factors too since
all orders are possible.
Berlekamp might have some explanations, check his books out.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Date: Wed, 19 Jan 2000 18:55:00 -0000
Bob Silverman <[EMAIL PROTECTED]> wrote in message
news:864tui$f5a$[EMAIL PROTECTED]...
> It never ceases to amaze me how much nonsense gets spouted by people
> who are totally ignorant of the subject they are discussing.
>
> Do you have any idea of how much harder 1024 bits is than 512?
> Do you know the SPACE requirements for 512 bits? Do you know the SPACE
> requirements for 1024 bits?
>
In their recent paper on Cryptographic key sizes, Lenstra & Verheul
www.cryptosavvy.com (page 21) conclude that "Combining these observations we
conclude that the NFS memory requirements do not explicitly have to be taken
into account when extrapolating NFS run times to future processors and
larger RSA moduli or field sizes", where NFS is the number field sieve
algorithm, and the factoring method of choice for RSA moduli.
Which I think means that they think that SPACE doesn't matter.
Mike Scott
> No? They how can you make ANY statement regarding whether 1024 bits
> is sufficiently secure???
>
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is this stream cipher secure?
Date: Wed, 19 Jan 2000 13:17:03 -0500
Salvatore Sanfilippo wrote:
>
> Hi all,
> I'm writing an opensource ecrypted shell and I need to know if the stream
> cipher that I implemented is secure (or how much is secure).
It seems ok. But why? If you really want a stream cipher, RC4 is
a lot faster than what you describe. And any block cipher (in a mode
other than ECB) will do nicely too, though stream ciphers may be a bit
faster. (Then again, who cares for remote login?) You could keep
the keying procedure you mentioned and use it with those other
ciphers.
paul
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: LSFR
Reply-To: [EMAIL PROTECTED]
Date: Wed, 19 Jan 2000 19:27:06 GMT
On Wed, 19 Jan 2000 Rob Largent <[EMAIL PROTECTED]> wrote:
>Hi Scott,
>
>This is interesting. I showed your post to my wife who
>is also an engineer. She works on finding patterns in
>data (she usually looks at hex dumps). Here response after
>4 seconds was that it was funny that all the others bit lengths
>that use four taps (e.g., 102 bits) had the properties of having
>the last two taps (e.g., 36 & & 35 for 102 bits) being either
>consecutive number or varying in value by 2 or 3 (e.g., taps
>101 & 99 for 128 bits)--and--that none of them seemed to have
>just a single tap number stuck way out at number 5 as you
>have indicated is correct for 102 bits.
>
>"102,101,36,35 isn't maximal length - probably
>should have been 102,101,36,5 which is maximal."
>
>Do you have any idea why 102 seems to be unusual?
>
There are lot's of maximal length LFSR's
The patterns you are seeing in the table have
more to do with the search methods employed than the
LFSR itself.
>
>Now that you've triggered my curiosity about this, do you have
>any references on how to determine if the tap values for large bit
>value LFSR's are indeed maximal? I've always just trusted the
>tables.
>
The usual method described is to use finite field mathematics
to determine if the polynomial corresponding to the LFSR
is primitive. Personally, I find that answer particularly
annoying. If you actually research it, you'll discover
that even advanced texts on the subject don't go into much
detail on how to do it. And the reason they don't is because
it's a very hard problem. Also, along with all the good stuff,
there is unfortunately a lot of incorrect stuff.
Here's a good link for testing primitive polynomials.
http://www-ftk.fernuni-hagen.de/~rieke/primitiv/test.phtml.en
Note that Andreas Rieke, Ahmad-Reza Sadeghi und Werner Poguntke's
paper "On Primitivity Tests for Polynomials" was published in 1998,
and I would distrust anyone who steers you toward reference
materials printed before that.
I wrote a program which uses a different method.
It's slower, but probably easier to understand.
(note, I said easier - not easy)
You can get a copy from my ftp site
ftp://helsbreth.org/pub/helsbret/random/
the executable (lfsr.exe) runs on pc,
but the source (lfsr_src.zip) should be ANSI C
compliant.
The method it uses is to check that after 2^n-1 shifts,
the LFSR returns to it's initial state, and that it
doesn't return to that state at any other time.
My program can also search for LFSR's with the minimum
number of taps (the 'permute' search method)
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Wed, 19 Jan 2000 19:33:53 GMT
wtshaw wrote:
> Cuba is another problem we created, or rather allowed to fester.
The US has a habit of picking the wrong side in civil wars,
usually supporting a corrupt established regime instead of
its opponents. At the time of the Cuban revolution, as in
VietNam, our official argument was that the insurgents had
Communicst backing. Of course! The Communists knew how to
win friends. By opposing the insurgents we actually helped
establish Communism in those places. Really stupid!
Anyway, it is also counterproductive to try to lend so-called
"humanitarian aid" to a country whose leadership we oppose.
The more aid we send, the more comfortable (relatively) the
population is, so the more they support their leaders (who
get the credit for any improvements). If we really want the
population to rise up and overthrow, for example, Sadaam
Hussein, we should make sure that they feel miserable under
his rule. In the long run, such a policy reduces death and
suffering. (A major problem with US foreign policy is that
nobody is thinking in terms of principles or the long run.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: RNG for OTPs during WWII
Date: Wed, 19 Jan 2000 19:36:56 GMT
Paul Rubin wrote:
> Bayard Randel <[EMAIL PROTECTED]> wrote:
> >Just out of historic interest, would anyone happen to know what sort of RNGs
> >would have typically been used by either Allied or Axis forces for OTP
> >keystream generation ? dice, playing cards ?
> Winterbotham discussed this in "The Ultra Secret". I vaguely recall
> that dice were used, but I'm not sure.
There were several methods used by the various OTP generators.
For example, one of them mixed the typographic "slugs" and
typeset them in oblivious order to print the 2 copies of the pad.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Wed, 19 Jan 2000 19:43:03 GMT
Bruno Wolff III wrote:
> Except for limiting the keysize to 56 bits. This may have been done to allow
> them to break it with special purpose hardware that would not typically been
> available to most entities wanting to break messages encrypted with DES.
That's essentially right. They didn't want it to be
too easy for the Bad Guys(tm) to use encryption that
would be truly unbreakable in an emergency, but at
the same time they didn't want the authorized
(non-classified) US usage to be readily crackable by
Bad Guys within the design lifetime of DES (10 yr).
The only reason DES got renewed past its original
design lifetime was that there was no suitable
alternative at the time. AES is trying to fix that.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mispronounce words. (OT Re: How to pronounce "Vigenere"?)
Date: Wed, 19 Jan 2000 19:48:00 GMT
Paul Gover wrote:
> I was told by a foreign friend that the normal rule for English is that
> the emphasis is on the third syllable of the word. Hence the normal
> pronunciation of omnipotent. It's always amused me how much better
> foreigners' understanding of English is than native speakers'.
Apparently not!
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Blowfish & pi.
Date: Wed, 19 Jan 2000 19:50:03 GMT
On Sat, 15 Jan 2000 06:30:38 GMT, XTR <[EMAIL PROTECTED]> wrote:
> Problem when to initialize P-array and S-array, that is,
>by taking fractional part of pi.
>After taking correct values for P[0] and P[1], the fractional
>part of pi goes all 0.00000....
>I'm using Turbo C++3.0, and the 'double' gives 64 bits datatype.
>
>Any better tip to overcome this?
The simplest thing to do would be to either grab any of the
many, many pages on the internet that provide the digits of pi
to some ungodly number of digits, OR just start with the
initialization array that any number of publicly available
Blowfish source codes already have set up for that very purpose.
Links to full Blowfish source(s), and places to find the digits
of pi, can all be found at the main Blowfish web page at:
http://www.counterpane.com/blowfish.html
A table of the value of pi already laid out for use in a C-language
Blowfish implementation is at the same site at:
http://www.counterpane.com/constants.txt
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Beginners questions re-OTPs
Date: Wed, 19 Jan 2000 19:51:28 GMT
John Savard wrote:
> If methods 1 or 2 work, it isn't an OTP.
It could be, just not an optimal one.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Wed, 19 Jan 2000 12:54:21 -0700
In a last ditch effort to get back on topic, and to avoid "so's yer old
man arguments":
My original point was based on the notion that this is a constitutional
republic with well established traditions that specify that laws are to
be made by the Congress and enforced and executed by the Executive.
These crypto regulations seem to have their basis in an emergency
executive order and based on treaty arrangements made by State
Department officials who may have exceeded their authority in binding
the US government to a set of international "arrangements" with regard
to the control of the sale of munitions.
I suggest that the Congress should re-establish it's rightful authority
to set the law of the land by merely passing a law prohibiting the US
government from regulating encryption period (except as to protect
national secrets relating to encryption used by our government).
If our present chief executive had any respect for our constitution, he
would see to it that passage of this kind of law were not necessary.
He has, however, shown a remarkable lack of respect for our laws and was
in fact impeached for this failure. Therein lies the problem.
JK
JPeschel wrote:
>
> "Douglas A. Gwyn" [EMAIL PROTECTED] writes:
>
> >To the extent that people think a democracy is desirable,
> >the US ideal of government that promotes individual rights
> >has already died.
>
> This is, of course, pessimistic nonsense.
>
> Joe
>
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (larry)
Subject: Re: Java's RSA implimentation
Date: Wed, 19 Jan 2000 20:01:26 GMT
On 19 Jan 2000 14:53:29 +0100, [EMAIL PROTECTED] (Paul Schlyter)
wrote:
>In article <863m2q$abe$[EMAIL PROTECTED]>,
>Bill Unruh <[EMAIL PROTECTED]> wrote:
>
>> In <862upd$vr$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>>
>>> Is anyone aware of any effort to analyse the RSA implementation in Java;
>>> specifically focusing on key generation.
>>
>> ??? Java is a language, much like C in many essentials. It is up to you
>> to code what you want it to do.
>>
>> >Does Java use a table of primes? If so, how big is the table?
>>
>> No, Java does not. But you can enter a table of primes if you wish. And
>> you can encode a prime testing routine in Java just as you can in C.
>>
>>> Otherwise how good is it's prime number generation routines ie. what is
>>> the probability of a generated number not being prime.
>>
>> I do not know that Java has a "prime number generating routine". but you
>> can code one up in Java.
>> Jus tread the code in any RSA implimentation.
>
>One difference between C/C++ and java is that Java is now getting a
>standard bignum class, which may contain prime number generating
>code. C/C++ never had that, and probably never will.
>
>--
>----------------------------------------------------------------
>Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
>Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
>e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
>WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
One big concern I have is that Java bignums (BigInteger objects) are
"immutable". They can't be altered once created. If you do something
like "A=A+1", a new object is created (with the new value of A), and
the old object (with the old value of A) becomes garbage, but remains
lying around in memory until the garbage collector decides to recycle
it (i.e. until who knows when).
So the problem is, private key material kept in BigIntegers can't be
wiped out when no longer needed. It sits in memory for an
undetermined and potentially long time. Long enough to make being
swapped out to a pagefile rather likely (or long enough for a memory
sniffer to find it). If someone can get that pagefile, they can get
the private key.
If I need to have private key material in memory, I prefer it to be
for the shortest duration of time possible. If it's in a Java
BigInteger, I have no way to restrict how long it stays in memory.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Wed, 19 Jan 2000 11:55:48 -0800
"Mike Rosing" <[EMAIL PROTECTED]> wrote ...
: Rob Largent wrote:
: > Now that you've triggered my curiosity about this, do you have
: > any references on how to determine if the tap values for large bit
: > value LFSR's are indeed maximal? I've always just trusted the
: > tables.
:
: It just has to be a primitive polynomial. That means it's both
: prime and has "order" 2^n-1. To check if a polynomial is primitive
: you first see if it's prime (really easy) then you take x to the
: power of each factor in 2^n-1 modulo the polynomial and see if you
: get 1. You need all the combinations of all the factors too since
: all orders are possible.
:
: Berlekamp might have some explanations, check his books out.
The discussion triggers my curiosity too, in another way:
--
If LFSR is generalized to mod B addition with say n registers holding
base-B digits, are there known taps to produce maximum cycle-length?
Example ("Running keys" like [4902846718]39202...):
Taking B=10, n=10, registers labeled (0123456789); tapping (01) produces
the simple "decimal chain-addition" of some pencil & paper ciphers:
initialize x(0),x(1),...,x(9); then x(i) = x(i-10) + x(i-9), i=10,11,...
Is the cycle structure known for this example? Are there other taps
instead of (01) that will tend (or be guaranteed) to give a longer cycle?
Are any taps known to be maximal?
(David Wagner kindly posted some pointers on these questions a while back,
but I fear my math hasn't proved adequate to generalize the bit-register
LSFR theory referenced in the literature.)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: New Crypto Regulations
Date: Wed, 19 Jan 2000 20:02:02 GMT
"John E. Kuslich" wrote:
> If our present chief executive had any respect for our constitution, he
> would see to it that passage of this kind of law were not necessary.
> He has, however, shown a remarkable lack of respect for our laws and was
> in fact impeached for this failure. Therein lies the problem.
No, he was impeached because the Republican party thought they
could profit politically from the situation.
A contributing factor to the unconstitutional imposition of laws
by the Executive is the failure of the Federal courts to enforce
the intent of the Constitution. Reading Supreme Court transcripts
doesn't encourage one to think that they would make the right
decisions anyway..
Congress is supposed to be responsive to the public in that the
legislators would be replaced if they didn't do a good job. But
that requires an informed and intelligent public, which is hard
to get when the entrenched government controls the news media
and the schools.
I.e., I don't think that working "within the system" is going
to solve the problem any time soon.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how to encipher
Date: 19 Jan 2000 15:07:38 -0500
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>> If I were programming this for a course (write a programme to
>> calculate a^b mod n which does not have any intermediate results larger
>> than n), I would redo it. But, as it works as is... so be it.
> Cleaned up programme. QBasic. Adding a+b mod n has been replaced with an
> add(a,b,n) function which does not use any intermediate results larger
> than n (using (a+b) mod n would calculate a+b and then reduce modulo n,
> and if a,b are large enough, the intermediate result, a+b could be
> almost as large as 2n).
Final note:
A much simpler ADD function to add a and b mod n (a,b both between 0 and
n) without having a result larger than n and which works with unsigned
integers (as well as signed) (and so does not use negative numbers is):
======
FUNCTION add& (a&, b&, n&)
IF a& >= (n& - b&) THEN add& = a& - (n& - b&) ELSE add& = a& + b&
END FUNCTION
======
(The intermediate, n&-b& is non negative.
The comparison tests, without actually calculating it,
whether a+b is as large as n.
If it is, then one uses a-(n-b).
In this case, n-b is between 0 and n as is a-(n-b)
(no intermediate result larger than n, nor negative -
so this works with unsigned integers).
If, on the other hand, a+b is not so large as n, then a+b is itself
the desired result.)
------------------------------
** 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
******************************
