Cryptography-Digest Digest #758, Volume #10 Fri, 17 Dec 99 20:13:01 EST
Contents:
Re: DES as pseudo random number generator (Tim Tyler)
Re: RSA, how to calculate big numbers (Ian Wehrman)
Re: Questions about message digest functions (Tim Tyler)
Microsoft- PKI/E-comm Director Opening ([EMAIL PROTECTED])
Re: Reducing Key Sizes (Keith A Monahan)
Re: ARC4 cipher... (Bill Unruh)
Re: RSA, how to calculate big numbers ([EMAIL PROTECTED])
Re: RSA, how to calculate big numbers ("Dann Corbit")
Re: Deciphering without knowing the algorithm? ("Rick Braddam")
Re: Q: BBS (Terry Ritter)
Re: BBS (Terry Ritter)
Re: Euclid Algorithm ("Miryadi")
Re: RSA, how to calculate big numbers ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Dec 1999 23:12:04 GMT
Markus Eiber <[EMAIL PROTECTED]> wrote:
: As you know one-time-pad is a cipher with perfect secrecy.
: How about a one-time-pad using a DES generated pseudo random number
: sequence?
[...]
: The seed and DES key will be transmitted secure to the recipiant of the
: message and he may decrypt the message after creating the identical pseudo
: random number sequence by adding it to the cipher.
: The security of this cipher depends only on the quality of the pseudo random
: number sequence.
: How secure is it?
About the same as DES used in OFB mode ;-)
OFB is not generally the most secure DES mode. For example, most
DES modes diffuse plaintext information over an entire block. OFB mode
does not diffuse the plaintext information at all.
In other words, it is vulnerable to governmental DES crackers everywhere ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Never eat anything bigger than your head.
------------------------------
From: Ian Wehrman <[EMAIL PROTECTED]>
Subject: Re: RSA, how to calculate big numbers
Date: Fri, 17 Dec 1999 17:34:03 -0600
get on a unix machine, use 'bc'
later,
ian
Bart Peeters wrote:
>
> I have to calculate:
>
> (32567023914^367151)%40000399997
>
> How can I do that?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Dec 1999 23:32:41 GMT
James Felling <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> James Felling <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
A hash with only four used values?]
:> : [...] and maping all values to 1 of 4 values is very resistant to being
:> : worked backward [...]
:>
:> No. It's likely to be trivial to "work backwards":
:>
:> Validate the hashes on a few messages - until the values of all four
:> hashes are known.
:>
:> Then append these four hashes in turn to your target message. One of them
:> will validate as being correct. You don't need the private information
:> about the primes (or whatever) that are used to generate the hash in order
:> to be able to do this.
: Accepted -- though this attack is equivalent to for an n bit hash append
: all 2^N possible hashes to the message and see which one works.
Hang on. I thought you said there were only 4 hash values. Do you
also mean the hash is only two bits long?? If so, why would reverse
engineering the hash be *at all* difficult?
I've been assuming the hashes under discussion are suitable for use in
signing or validating messages - i.e that it is a one-way hash function
which can be generated with a private key, but validated with a publicly
available one.
Your comments don't make much sense in this context. I presume you are
thinking about a hash which is used for something else, and is not
suitable for validating messages?
: In addition if you are given two messages, both of which hash to value
: #4 which message was the valid one?
With a 2-bit hash (or effectively a hash with only two bits of
information), forging messages is pretty trivial - even if the attacker is
just guessing hashes he will succeed about 1 time in 4. Such a scheme
offers precious little security - I'm not sure why it is being discussed.
:> : One must seek to maximize both and remain aware that when it gets down
:> : to it, there are tradeoffs that must occur.
:>
:> Tradeoffs are not required. Collision resistance and security do not
:> pull in opposed directions.
: They do indeed, it is simply that if one posseses a very good hash that
: manages a high level of both, it is hard to improve one without hurting
: the other.
You're talking about practical issues in designing hash functions?
Such difficulties don't appear to exist in principle. A hash function
should be as haerd as possible to reverse, and as resiliant to hash
collisions as is possible, and you /can/ do both at the same time.
If you are talking about engineering difficulties - rather than some
theoretical tradeoff - then it might help to say so at this point.
: I agree that this is mostly an academic argument, but I do feel that at the
: highest end there are definite design tradeoffs here.
I can't think what they might be.
Why would having good resistance to collisions reduce the ability to
reverse a hash?
I see no reason for the reverse tradeoff either.
Considering a hash as a big LUT linking messages and their hashes,
there seems to be no possible problem.
If you mean that there are engineering difficulties in approaching this
ideal. I'm not sure what they might be.
When designing a hash, it seems to me that the collision resistance can
be done first in an ordinary hash, and then a bijective one-way function
applied afterwards.
This seems to neatly separate the difficulty in getting the collision-
resistance property from the difficulty in reversing the operation - and
allows them to be treated as separate design problems, and optimised
independently.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Never trust a skinny cook.
------------------------------
From: [EMAIL PROTECTED]
Subject: Microsoft- PKI/E-comm Director Opening
Date: Fri, 17 Dec 1999 23:40:56 GMT
I hope I am not breaking group etiquette by
posting this here, but I think it is highly
relevant and some of you may be interested...
Microsoft is hiring a group of PKI/Security/
encryption/Decryption people to head up a new
secure e-commerce project. We are hiring
everything from testers to developers and
directors. I have posted the opening below.. if
you are interested you may reply to me at
[EMAIL PROTECTED] Thanks--
PKI E-Commerce Director
PKI? Secure On-line Transactions? E-commerce? Are
we speaking your language? Then join us as the
new PKI E-commerce Director! Our e-Commerce
ventures are just starting to get exciting, and
we are looking for a strategic technical E-
Commerce Director, with a back-ground in Security
(public key) hands-on development and
implementation, to help take our projects
worldwide. Are you ready for mind-blowing
success?- Come join us, we are waiting for you...
The E-Commerce Director will be will be
responsible for the design, development and
implementation of information systems in the E-
Commerce group in support of the Anti-Piracy
Initiative. The Anti-piracy infrastructure
consists of a generic and extensible Clearing
House to support multiple enforcement models and
key delivery mechanisms. A version of Clearing
House to support W2K terminal Services and Office
LVP program has already been developed and is
currently available. The Anti-Piracy team is
planning to continue the development of the
Clearing House to accept other licensing Models
and Products. This will include, but not be
limited to, Software Subscription, rentals, etc.
Core Job Responsibilities:� Perform analysis and
research alternate approaches to determine the
optimal solution for complex business problems.�
Effective scope, expectation and change
management skills are required. Effectively
escalate and manage upward. � Projects will
address complex business/process issues and
require negotiation abilities in identifying
tradeoffs associated with work-flows, resource
management, and timing issues driven by the
competitive nature of the software business.�
Gather requirements; design the system and
application architecture with a focus on
identifying similarities between project
requirements and consolidating them into a set of
core enterprise requirements and functionalities
to reduce costs and time to market � Intra/Inter
team contact, cooperation and co-ordination.
Track and drive external issues and deliverables
from other teams - required for the success of
eCBS projects. � Will be involved in the
leadership, analysis, design, development and
roll-out of system components to support new Anti-
Piracy initiatives and other projects and will
have to drive consensus across business units to
create re-usable components and in the right
priority order.
Requirements/Qualifications� Demonstrated
experience in one of the four areas is required:
eCommerce; Licensing Systems; Manufacturing
Systems; Product Management Systems; or
Clearinghouse Systems.� Must have advanced
understanding of Microsoft products, software
lifecycle methodology and information systems
development� Requires a Bachelors degree or
equivalent with a minimum of 4-6 years of
information systems experience� Experience with
various forms of security models and (unlock) Key
delivery mechanisms will be a strong plus.�
Experience in Transaction Processing, Internet
technologies, Database design is preferred. �
Demonstrated experience in analysis and design of
large information system projects required.� The
ability to work effectively while under continual
deadline constraints and pressure are necessary.�
Must be able to achieve results through an
organization.� Must be able to establish strong
working relationships inside and outside the
company.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: Reducing Key Sizes
Date: 18 Dec 1999 00:00:15 GMT
Scott:
Is your link down? I tried
http://www.helsbreth.org/random/nbitcrc.html
and also a couple other variations to no avail.
Keith
Scott Nelson ([EMAIL PROTECTED]) wrote:
: On Fri, 17 Dec 1999 "Adam Pridmore" <[EMAIL PROTECTED]> wrote:
: >Does anyone know if there are any security issues in symmetric algorithms if
: >the key size is reduced (eg making the last x bits of the key constant),
: >other than reducing the number of available keys. (ie Brute force is still
: >the easiest way to break it).
: >
: >Could this be very dependant on the algorithm chosen?
: >
: Yes, and Yes.
: Most modern ciphers don't have much problem with it.
: (other than the obvious problem that a smaller key size
: is easier to brute force.) I.e. there's no (publicly)
: known way to break IDEA with the top 64 bits being set
: to 0 that's easier than brute force.
: However, many other, less practical attacks do become
: possible with reduced key size. For example, it's
: usually not reasonable to pre-calculate all possible
: encryptions of a particular block, but if the key-size
: is small enough, then it might be. So 32 bit DES is
: not only crackable in a under an hour with a modern PC,
: it's also possible to do a chosen cipher-text attack
: on it that will crack it in a few milli-seconds.
: It's also conceivable with a bad algorithm that reducing
: the key size will have a disproportionate result.
: 3DES normally has about 112 bits of "strength,"
: (2/3 of 168), but reducing 168 bit 3DES to 64 bit keys
: _might_ result in a cipher with only 33 bits of strength.
: It depends on which bits you leave out.
: As a general rule, it's better to duplicate a
: short key into the unused bits, rather than set
: them to 0. Or use something like SHA1 or nbitCRC
: ( http://www.helsbreth.org/random/nbitcrc.html )
: to convert the user key space to the cipher key space.
: Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: ARC4 cipher...
Date: 18 Dec 1999 00:02:03 GMT
In <83ct75$kjj$[EMAIL PROTECTED]> "Andrej Madliak" <[EMAIL PROTECTED]> writes:
> Has anybody heard of
>ARC4 stream cipher (w/128-bit key) and/or about its security and
ARC4 is RC4, with a different name. RC4 is trademark by the former
RSADSI. ARC4 is an algorithm which produces the same output as RC4 for
the same input.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA, how to calculate big numbers
Crossposted-To: alt.security
Date: 17 Dec 1999 19:20:05 -0500
In sci.crypt Bart Peeters <[EMAIL PROTECTED]> wrote:
> I have to calculate:
> (32567023914^367151)%40000399997
> How can I do that?
First, write 367151 in binary=1011001101000101111.
Now consider the sequence (from the right):
a_0=a_1=a_2=a_3=a_5=a_9=a_11=a_12=a_15=a_16=a_18=1
a_4=a_6=a_7=a_8=a_10=a_13=a_14=a_17=0
(the bits of the exponent)
(just the bits) and let me write X for 32567023914.
Consider:
You want x^(a_18*2^18+a_17*2^17+...+a_2*2^2+a_1*2+a_0)
Now for the a_j=0, x^(a_j*2^j)=1 (a factor of 1, nothing to worry
about) but we do need
x^(2^18) (after all, a_18=1).
How to get that?
Well write down:
x_0=x
x_1=x^2=x_1^2=x^(2^1)
x_2=x^4=x_2^2=x^(2^2)
x_4=x^8=x_3^3 etc.
(square x_0 to get x_1, square x_1 to get x_2, square x_2 to get x_3, ...)
Just successively squaring the prior result and ALWAYS as soon as you do
the calculations TAKE THE RESULT MOD 40000399997.
The most you have to do (to get each x_j MODULO 40000399997) is to
multiply two numbers (almost as large as 40000399997) and take the result
mod that number (so the worst you have are number with twice as many
digits as 40000399997, about 2*11 digits: take the remainder after each
squaring and you keep the size of the numbers in check).
We get x^(2^18) as x_18 (just 18 squarings of x_1, and then the next and
then the next). As you do this keep track of the other x_j's.
What do you want again?
x_18*x_16*x_12*...*x_2*x_1*x_0 mod 40000399997
(just the terms where a_j=1)
So you only have to multiply out (at most in this case) 18 items (hint
multiply two of them AND REDUCE MODULO 40000399997 - then multiply by the
next and REDUCE again! That way you keep the numbers from growing too
large).
So ... you have to do about log_2(exponent) squarings (to get the
x_j's) (those are done modulo the modulus to keep things from getting too
large) and then about log_2(exponent) multiplications (multiplying
together the x_j's that have a_j=1: the j'th bit of the exponent is
1: modulo the modulus to keep things from getting too large).
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: RSA, how to calculate big numbers
Date: Fri, 17 Dec 1999 16:21:22 -0800
"Ian Wehrman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> get on a unix machine, use 'bc'
>
> later,
> ian
>
> Bart Peeters wrote:
> >
> > I have to calculate:
> >
> > (32567023914^367151)%40000399997
> >
> > How can I do that?
Did you actually try it? On my machine, it just pegs the CPU and sits
there. I have a feeling BC would never complete this task.
bc 1.04
Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
x = (32567023914^367151)%40000399997
It also seems to chow down more and more memory as it runs.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: Deciphering without knowing the algorithm?
Date: Fri, 17 Dec 1999 18:00:19 -0600
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> wtshaw wrote:
> > He explained that he primarilly an assembly programmer. To him what
he
> > writes makes perfect sense. I remember the struggle to get mayself
to
> > adopt a different programming style years ago, but it does not mean
that
> > what I did before was wrong, as it worked.
>
> Programs have several purposes, only *one* of which is to "work".
Sometimes programs have just three purposes: to work, to work correctly,
and to work immediately. If you work under those requirements for a
number of years, it can be very difficult to adopt a "style" for the
convenience of others, especially if it makes no improvement in the
final product. It can be even harder if the ones who would benefit from
the style were the ones who wrote the code you were having to fix. Old
habits *are* hard to break, and old methods hard to change.
> Another, very relevant in this context, is to communicate with a
> future (maintenance) programmer. Some code is easy for another
> competent programmer to fully comprehend, but much code is awful.
I'm not sure what you consider maintenance programming where
cryptography is concerned. To me the relevant communication would be
with cryptoanalysts and I would make a concerted effort to ensure an
analyst could read my code. What I would do doesn't place a requirement
on anyone else, though.
Any competent programmer, given enough time, should be able to analyze
another programmer's source code and determine what s/he was doing,
assumeing familiarity with the programming language used. Being able to
figure out what the programmer is doing with the code doesn't imply
being able to do a cryptographic analysis of the algorithm.
> There are many books, several of them very good, on programming
> style (as opposed to just getting a program to appear to "work").
Style is useful to me, and can be very helpful. However, no application
of style will prevent or compensate for poor program design or
implementation, or readily identify either one. With or without style,
it always boils down to just getting a program to appear to work --
correctly.
--
Rick
============================
Spam bait (With credit to E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Q: BBS
Date: Sat, 18 Dec 1999 00:27:16 GMT
On 16 Dec 1999 18:43:33 GMT, in <83bbsl$ein$[EMAIL PROTECTED]>,
in sci.crypt David A Molnar <[EMAIL PROTECTED]> wrote:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>> Question: Does this signify anything to the security offered by BBS?
>
>Well, if you start over in a cycle, you will output the same bits,
>and this will be bad. So you should know how long the cycle is for your
>particular instance of the generator. The last part of the BBS paper
>covers methods for determining parameters which yield maximum-length
>cycles. Terry Ritter also has an article in Cryptologia (?) and some
>discussion on his web page as to how to determine the cycle length
>of given parameters.
That article is "The Efficient Generation of Cryptographic Confusion
Sequences" and was published in Cryptologia over 8 years ago. Here is
the overall link:
http://www.io.com/~ritter/ARTS/BIRTHDAY.HTM
The casual explanation of BB&S in most references has been a hot
button for me for some time. If you take the trouble to work through
the actual BB&S article, you find that they have done a lot of work to
guarantee a long cycle length for these constructions. But the
references usually do not include the various checks which make the
scheme BB&S, and instead tell us about a simplified scheme -- which
may or may not be secure, but is *not* BB&S.
I give the general requirements for BB&S in Sect. 4.4, the X^2 mod N
generators:
http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect4.4
Here is the major part:
"N is to be the product of two large distinct primes, P and Q. Both P
and Q are to be congruent to 3 mod 4, and must also be special (p.
378). Prime P is special if P = 2P1 + 1 and P1 = 2P2 + 1 where P1 and
P2 are odd primes. The paper gives 2879, 1439, 719, 359, 179, and 89
as examples of special primes (but 179 and 89 appear to not be
special, while 167, 47 and 23 should be). As yet another condition,
only one of P1, Q1 may have 2 as a quadratic residue (P1, Q1 are the
intermediate values computed during the "special" certification). If
we mark such particular special primes with an asterisk ("*"), we get,
for example: 23, 47*, 167, 359, 719*, 1439*, 2039, 2879*, 4079*,
4127*, etc. Accordingly, N = 719 * 47 fails the additional condition,
because both special primes are particular. Presumably, these
detailed conditions guarantee the existence of long cycles, but they
do not banish short ones. "
I also give a summary of some experimental "BB&S" generators which do
not behave as we would like to believe all possible BB&S systems must
behave in Section 7.2.2:
http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect7.2.2
This is not rocket science, folks. Anybody who can program a computer
can build simple BB&S systems and count their cycles and cycle
lengths. Obviously, we can do this only for *small* BB&S systems, but
BB&S is a scalable *mathematical* structure which we can scale to our
advantage.
The results are indisputable. The only argument which remains is
whether a *possibility* of weakness (caused by a desire to avoid
certifying x[0]) is acceptable in any design which we want to see as
having *proven* security. In my view, such a possibility proves the
contrary, that such a structure may *not* be secure. And this is the
sort of thing the major crypto references choose not to discuss.
>It's an interesting kind of problem - if you implement a BBS in say,
>Scheme, and keep iterating it, you can actually play with a lot of
>different parameters and notice that some work and some don't. and you can
>notice that if n isn't a blum integer, then your least sig bit is not
>particularly random at all...
>From figure 2 in section 7.2:
"For the improper x^2 mod N designs which are covered in Figure 2, P
and Q are "Blum integers" [4; 96: 8], that is, they are primes
congruent to 3 mod 4, but at most one is special as defined in Blum,
Blum and Shub [21: 378]. Note the case of P = 127, Q = 131, which
generates a sizable system with maximum cycle length of 12, and so is
extraordinarily weak. In an improper design, a small increase in the
value of one of the primes can result in a drastic decrease in
strength. "
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: BBS
Date: Sat, 18 Dec 1999 00:27:22 GMT
On Fri, 17 Dec 1999 10:17:23 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Michael Scott wrote:
>>
>> I think that if a cycle can be found, then the modulus can be factored.
>>
>> So the randomness, and non-cycling nature of the generator are both
>> predicated on the difficulty of factoring the modulus, and hence cycling
>> will not be a problem, assumuing factoring the modulus is difficult.
>
>My consideration is the following: I suppose that given any Blum
>integer n, whatever constraints that are placed on it, there may
>always be seeds that lead to very small loops. (See my first post.)
>Let's call these bad seeds (analogous to weak keys). I have the
>impression that such bad seeds are not rare at all.
In a "properly constructed" BB&S structure, short loops are few and
rare. But it is not unusual to find loops on the order of SQRT(N).
>Now a user of
>BBS trusts its well-known high security. Even if he does a number
>of tests on the generator, he may not necessarily hit on the
>bad cases.
This is the reason for scaling the BB&S structure down so that it may
be examined experimentally.
>Then in an actual encryption, with some bad luck, he
>employs a bad seed with catastrophic consequences without his having
>any suspicion on that. Note that any seed ultimately leads to a loop.
>There can be (usually is) an initial unrepeated segment.
That sounds like something somewhat removed from BB&S. In most real
BB&S-like structures, all states are on loops, and there will be at
least 4 "degenerate" (single-state) "loops."
>That
>segment can be quite long, so that, even if the user examines that,
>he may find everything is o.k. and isn't aware that the sequence
>eventually leads to a loop whose length could be as small as 2 or 3.
This is exactly the sort of thing that the real BB&S structure avoids,
albeit at significant cost.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Miryadi" <[EMAIL PROTECTED]>
Subject: Re: Euclid Algorithm
Date: Sat, 18 Dec 1999 07:10:00 +0700
Medical Electronics Lab wrote in message
<[EMAIL PROTECTED]>...
>
>Check out Knuth, "Semi Numerical Algorithms". You'll find several
>implementations and lots of reasons why you should pick one over
>the other for your application.
>
Thanks for the reply.
I know that book. It is mention in Schneier's "Applied Cryptography", but
unfortunately my school's library is not well equipped with good crypto
refferences. :(
Is there any site that give full on-line access to this Knuth's book, or any
other site that explain this topic in detail. I'm having trouble on
determining
the time complexity of Euclid algorithm.
Best Regards
--Yadi--
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA, how to calculate big numbers
Date: 17 Dec 1999 19:50:22 -0500
Dann Corbit <[EMAIL PROTECTED]> wrote:
> Did you actually try it? On my machine, it just pegs the CPU and sits
> there. I have a feeling BC would never complete this task.
> bc 1.04
> Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc.
> This is free software with ABSOLUTELY NO WARRANTY.
> For details type `warranty'.
> x = (32567023914^367151)%40000399997
Heh. That will calculate the number and then reduce it modulo the
modulus. You want to do a few multiplcations/squarings and reduce each
time to avoid getting a number of about 3,859,777 digits! (as this does)
(use UBasic and its MODPOW command and you can handle it)
------------------------------
** 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
******************************
