Cryptography-Digest Digest #572, Volume #13 Sat, 27 Jan 01 18:13:00 EST
Contents:
Generating RSA Keys ("Adam Smith")
Re: 32768-bit cryptography (SCOTT19U.ZIP_GUY)
Re: How many bits of security can a password give? (Splaat23)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: 32768-bit cryptography ("Paul Pires")
----------------------------------------------------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Generating RSA Keys
Date: Sat, 27 Jan 2001 22:17:44 GMT
Hello! This is sort of an extension from my quest for RSA implementation in
VB, but on a different note than my last message. I got an excellent big
number package for VB, and have implemented a signature scheme pretty well,
or at least it works with the small numbers that I have.
I need to know how to generate LARGE (512+ bit) RSA keypairs. I know the
algorithm, but not really sure how I can computer D without brute forcing
it...anyone know where I can get this stuff?
Thanks!
Adam Smith
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: 32768-bit cryptography
Date: 27 Jan 2001 22:11:27 GMT
[EMAIL PROTECTED] (Paul Schlyter) wrote in <94vbcu$5v7$[EMAIL PROTECTED]>:
>In article <[EMAIL PROTECTED]>,
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
>> Actually DES was easily crackable with custom circuits back in
>> the early 70's at a rate much shorter than a day so where have you
>> been.
>
>How much shorter than a day? An hour? A minute? Let's assume
>10 minutes....
>
>> Also it appears if anything Moore's law may be a conservative
>> estimate and that computing power is increasing much faster so you
>> may be alive when such a dumb blind search is possible in the
>> nonblack world.
>
>OK, then let's make a conservative estimate and use Moore's law:
>
>You claim DES was crackable by a brute-force key search in approx.
>10 minutes back around 1970, i.e. some 372 months ago.
>
>Computing power doubles every 18 month's if we're conservative and
>use Moore's law instead of some other law which predicts a faster
>rise in computing power. Thus in 372 months, computing power has
>increased by AT LEAT approx. 1.6 million -- probably much more,
>according to your claim.
>
>Which implies that today, DES is crackable by brute force in
>approx. 10_min/1.6_million = 0.4 milliseconds --- or less !!!!!
>
>Now, tell me where I can find the hardware which can crack DES
>by a brute-force key search in just 0.4 milliseconds ....
>
>.... or admit that you were wrong!
>
Talk to the folks at Fort Meade I think they can help
you if you have a valid need. But don't hold you breath
they will most likely consider you need not valid.
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: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Sat, 27 Jan 2001 22:26:49 GMT
Those work factors look not right. Ideal passwords (i.e. random ones)
have exponential work in 'n', not polynomial. I could be wrong, though.
You are definately right, however, about most passwords being less than
ideal. As I see it, each ASCII byte only has 95 different possiblities,
including symbols. That's only 6.56 bits per byte of entropy. But even
that's far off for most password, even random looking passwords. A
random password that has the full 6.56 bits of entropy would need 2-3
symbols. Most random looking passwords use only one. So even random
looking passwords, unless truly generated with every element equally
likely, will have < 6.56 bits per byte.
Now, non-random passwords have far less entropy. Most have a word or
two, which, in English, means 1.3-1.7 bits per byte with no
capitalization, plus <1 bit with capitalization (most will capitalize
first letter).
All of these attacks, especially ones that use rule-based trial
generation, can be sped up with offline precomputation of guesses,
which is a parallelizable op anyway. Storage would be mean (6 TBs for
all 8 byte ASCII passwords), but not impossible.
Moral: 8 byte passwords are not sufficient to protect against offline
attacks. Use longer passwords. Or use hiding techniques that can not be
offline verified by an attacker.
- Andrew
In article <94vg0l$ec9$[EMAIL PROTECTED]>,
Rex Stewart <[EMAIL PROTECTED]> wrote:
> In article <94nd0c$o0m$[EMAIL PROTECTED]>,
> Splaat23 <[EMAIL PROTECTED]> wrote:
> > In your crypto class you learn[ed] that entropy is the
> > measure of randomness. Tom is just making sure you know
> > that the familiar log2((num of possibilities) ^ (num of elements))
> > formula only applies when all possibilities are equally likely.
> >
> > But you are right, entropy is more commonly discussed
> > when something has entropy _less than_ what might
> > be expected. For example: log2(26^8) = 8 * log(26)
> > is the entropy of a random lowercase password,
> > but 8*1.3 is the [generally accepted, to within
> > a margin of error] number of bits of entropy of English.
> >
> > - Andrew
> <snip>>
>
> I have found, in the real world, passphrazes tend to be somewhat
> less than ideal. Even with trained and motivated users (ignoring
> the ones who are unbelievers) I have devised algorythms that will
> extract a passphrase with considerably less effort than what the
> user would expect. Using upper and lower case, numbers and
> special characters in passphrazes between 8 and 14 characters
> (the standard advice given nowadays for networks) I found
> most user passphrazes could be extracted with
> about 6.4*(n-1*5)^2) work, rather than the (n^6.4)^2 work
> the users would hope for. Using a rule based
> attack (for instance, if the previous two characters
> are uppercase/numeric then this one is likely to also be
> uppercase/numeric also) that imitates how humans remember
> things provides a great deal of leverage. I am sure the
> attacks could be refined even further - but I ran into
> problems with slowing the attack down because it took
> to long to compute the next guess.
>
> --
> Rex Stewart
> PGP Print 9526288F3D0C292D 783D3AB640C2416A
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 22:42:09 GMT
On Fri, 26 Jan 2001 23:08:54 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt "John A. Malley"
<[EMAIL PROTECTED]> wrote:
>[...]
>Now I'm spending time trying to understand Mr. Ritter's statement about
>the additive PRNG and the canonical PRNG model in L'Ecyuer's paper,
>
>"Unfortunately, this model does not completely fit an Additive RNG, at
>least in the sense of providing insight as to which RNG values are
>going to be correlated,"
>
>which threw me, since L'Ecuyer addresses the additive PRNG in that paper
>but never says anything about it differing in any sense from the
>canonical model in the paper.
As far as I can recall (after so many words in so many directions), I
had two things in mind with that comment.
First, it seems to me that a mapping from state S through G to output
symbols does not really capture the action of an Additive RNG. The
feedback polynomial has to be a primitive mod 2, and most designers
use a trinomial, so that only 2 element values need be selected and
added. The distinction is that only 2 elements from S are involved at
any one time, out of perhaps 10,000. Any information one has about
that result is useless until we encounter one of those elements again,
some time later.
Next, the issue of correlated values is related to the particular
feedback polynomial used. Each time the RNG takes another step, "new"
values are selected. These may be independent, both with respect to
each other, and with respect to all previous values, until we reach
the point where we have used one of the values before. At that time
we get a result which is still unknown, because the other value in the
addition is unknown, but certainly is "correlated" to a previous
output. This is the correlation with respect to a in a + b = c, and
in a + d = e. This is the beginning of the linear relationship which
eventually becomes solvable in any RNG. That is why I use a
"jitterizer" stage to isolate RNG output.
The point is that if there is to be "correlation" in the selection of
Shuffle elements, that is how the correlation will occur.
---
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: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 22:42:26 GMT
On Sat, 27 Jan 2001 10:41:46 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>[...]
>I suppose you have a different and problematical concept
>of the (THEORETICAL) OTP. The bit sequence of OTP is by
>definition/assumption unpredictable. If a 'claimed' OTP
>uses a predictable bit sequence and consequently is weak
>as you said, then it is by definition NOT an OTP, though
>snake-oil peddlers used to call that OTP.
OK, then, in practice, there can be no OTP at all, since, in general,
it will be impossible to prove in practice that any bit sequence
actually is unpredictable.
Clearly we can't compare a cipher which is designed to work in
practice to one which cannot. Yet that was exactly what you tried to
do.
>Some people in
>crypto groups even object to use the term pseudo-OTP to
>designate that kind of stuff.
Usually the objection is to using an obvious pseudo-RNG and calling
the result an OTP instead of a Stream Cipher.
>(Once I got flames for having
>employed the term pseudo-OTP.) We should take care not to
>be contaminated in our terminology by the slangs of
>snake-oil peddlers. (Of course they could complain, because
>anything used 'one-time' is OT, but that's evidently outside
>our present concern.)
>
>BTW, my argumention in the previous follow-up could be
>simplified a bit. One does not have to use the big sequence
>S. It suffices to pick one arbitrary balanced block and
>feed repetitions of it to the algorithm. Basically, the
>argument boils down to the trivial fact that a PRNG has a
>finite period, while the theoretical OTP has, by definition,
>an infinite period. Hence there is no chance that the former
>can compete with the latter.
Had you actually read my "Revisited" article, you would have found the
statement:
"This of course does not
mean that Dynamic Transposition cannot be attacked:
Brute-force attacks on the keys are still imaginable, which
is a good reason to use large random message keys."
I am discussing a cipher which functions in practice, not some
theoretical thing whose only use is to confuse and confound.
You appear to be discussing perfection which can never occur in
practice.
---
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: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 22:42:46 GMT
On Sat, 27 Jan 2001 13:18:29 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Sat, 27 Jan 2001 10:41:46 +0100, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote, in part:
>
>>I suppose you have a different and problematical concept
>>of the (THEORETICAL) OTP. The bit sequence of OTP is by
>>definition/assumption unpredictable. If a 'claimed' OTP
>>uses a predictable bit sequence and consequently is weak
>>as you said, then it is by definition NOT an OTP, though
>>snake-oil peddlers used to call that OTP.
>
>This is true.
>
>But Terry Ritter isn't talking about fake OTPs based on algorithmic
>PRNGs, as far as I understand it.
>
>He is saying that even what people acknowledge as "real" OTPs, where
>the key has been generated by physical randomness, aren't provably the
>'theoretical OTP', because you can't prove a particular physical
>random noise generator to be perfect.
Right.
>That is not, in itself, untrue. Physical random number generators can
>have bias, for example.
Hmmm, "not, in itself, untrue." My, what an interesting way to say
that I was, in fact, absolutely right. I suppose that would be a
"condemnation by faint praise."
More concisely, my position is simply "correct."
>However, it his his insistence that this is a major concern, and more
>specifically the implication that this makes the proof that the
>theoretical OTP is unbreakable _irrelevant_ to physically realizable
>OTPs, that I fear strikes many as simply bizarre.
First of all, I am getting pretty tired of you deciding what strikes
"others." Who put you in charge of tracking the body public or
knowing what others think?
Next, the issue is not "bizarre," the issue is "proof of strength."
As far as I can see, there is no advantage for anyone in messing with
the various problems of an OTP in practice unless the goal is to have
a real cipher with a mathematical proof of strength. That is why
people want to use the OTP. The fact that the proof they seek does
not apply unless they can also prove unpredictability -- which is
generally unprovable -- is not "irrelevant," but is instead exactly on
point.
>Because, whether or
>not that is his intention, it makes it sound as if he is worried about
>the NSA having a cryptanalytic attack which enables them to predict
>the roll of a die or the flip of a coin.
If that's what it sounds like to you, then you aren't listening. In
fact, it seems to me that there is a lot of not listening on purpose.
The OTP issue is not security in practice but "proof of strength."
Perhaps you can even bring yourself to recall that I have said that
various techniques could be used to build pads which could be very
strong in practice, but there could be no *proof* of that. Does that
ring a bell, or shall I quote past messages in elaborate depth?
>In VENONA, not only did the NSA exploit pads used twice, but they even
>made use of the bias of numbers generated by hand by typists 'at
>random', so they did come closer to doing that than anyone might have
>expected.
>
>While precautions are needed in using the raw output of a simple
>physical RNG, there are still limits to what constitutes reasonable
>concern.
I think there are limits to what constitutes reasonable discussion,
and you are close to the edge.
---
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: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 22:42:59 GMT
On Sat, 27 Jan 2001 05:46:44 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Sat, 27 Jan 2001 04:51:04 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>Of course not. Dynamic Transposition is a permutation cipher. It
>>does not emulate huge substitution tables.
>
>>That said, for the keyspace it uses -- permutations -- Dynamic
>>Transposition can traverse the full keyspace.
>
>>In contrast, for the keyspace the modern block cipher uses -- emulated
>>huge substitution tables -- no design can touch more than the tiniest
>>fraction of that keyspace.
>
>At least I now know my point has been understood, and I don't need to
>explain the mathematics of it again.
I believe it was I who explained to you that DES was not unable to
select just "some" possible keys, but instead was not able to select
virtually all of them. Shall I go back and quote in depth?
>What remains in dispute, though, is my claim that what you have said
>here, although true, is in no way a valid argument in favor of Dynamic
>Transposition.
Let me see; before, you were arguing (with wrong numbers) that the
argument was not true. Now that I have shown the unarguable numbers,
it's suddenly true, but not a valid argument. Hmmm.
Have you already decided on the conclusions, such that any argument
which does not reach them must be "in no way a valid argument"?
The Real Argument
It appears to me that one advantage of having a combinatoric sort of
encryption is to support mathematical analysis.
Dynamic Transposition is based on balancing and permuting data, and it
is specifically intended to support any possible permutation. As a
consequence, what we know about the theoretical distribution of
permutations may apply, at least approximately, in actual practice.
This stands in direct contrast to the OTP, whose theoretical results
generally do not apply in practice.
Modern block ciphers are based on substitution: they emulate huge
keyed substitution tables. But since that structure represents a
truly immense keyspace, they actually key only a tiny -- almost
infinitesimal -- fraction of it. As a result, we cannot apply what we
know about the distribution of substitution tables, because only a
very tiny number of presumably specialized tables are actually
realized. The modern block cipher simply does not begin to approach
the associated mathematical model.
>As you've noted, one small error causes people to neglect what is
>valid, and this is why I'm pounding on this one point - I believe I'm
>not the only one who would see this error, but most of the others have
>already stopped paying attention to your work.
Is it just me, or is it really strange to have the belief that you
know what others think and what others are doing and why?
>Essentially, my argument is that it doesn't matter to an Opponent what
>you are "attempting" to emulate. All that matters is what your cipher
>does or does not do.
Essentially, your argument is a "Red Herring." Since the position you
attribute to me is not the reason I think this feature is beneficial,
showing that it is wrong is simply irrelevant.
>Neither a block cipher nor transposition provides all possible
>substitutions of input blocks to output blocks.
A transposition does not provide all substitutions? What is wrong
with this picture?
Since a substitution cipher *does* substitutions, it is not entirely
unreasonable to expect it to do all of them.
Since a transposition cipher does *not* do substitutions, it is quite
*un*reasonable to expect that.
With such an argument, you are being unreasonable, as well as
irrelevant.
>Both a block cipher and transposition provide several alternative
>paths for any plaintext block to become any ciphertext block, unlike
>simple XOR, which provides only one.
Actually, transposition is a block cipher. It just is not a
conventional block cipher based on emulating huge substitutions.
>Transposition is 'exhaustive' in the sense that it provides every
>transformation in a particular tidy closed set of transformations. But
>that isn't even a strength: that is a weakness, just as it would have
>been a weakness if DES was a group.
Worse and worse.
The issue of the groupiness of DES concerns multiple ciphering with
DES alone (e.g., Triple-DES). If DES had been a group, then multiple
ciphering could not have added strength, and would not have expanded
the keyspace. The reason strength can be added in this way is that
the cipher did not provide it in the first place.
Since Dynamic Transposition provides all of its strength in the
original design, it does not need to be multiple ciphered with itself.
And, indeed, multiple ciphering with itself alone will not provide
additional strength. (I just note that we could design a Dynamic
Transposition cipher with a real keyspace of tens of thousands of
bits, were that to be desirable.)
How is being too strong suddenly a weakness, and how is this any sort
of reasonable argument at all?
>Suppose that, between the two transpositions, I inserted an S-box,
>that changed under the control of a good PRNG with each round, of the
>form:
>
>0000 -> 0000 1111 -> 1111
>
>0001 -> 0100 0111 -> 1011
>0010 -> 0010 1011 -> 1110
>0100 -> 1000 1101 -> 0111
>1000 -> 0001 1110 -> 1101
>
>0011 -> 1010
>0101 -> 0110
>0110 -> 1100
>1001 -> 0011
>1010 -> 0101
>1100 -> 1001
>
>In other words, I'm substituting small portions of the block with
>other substitutes that have the same number of 1 bits.
>
>Now I'm producing substitutions of input block to output block that
>can't be reached by transposition alone. Have I _weakened_ the cipher?
Since that does not describe "the cipher" -- Dynamic Transposition --
it would be hard to say whether it was "weakened" or not.
But in a 3-level system consisting of transposition -> substitution ->
transposition, arbitrary substitutions *do* weaken the last
transposition level, if the substitution outputs are not bit-balanced.
If your position is that Dynamic Transposition is bad because we can't
multi-cipher with itself alone and gain strength, well, by gosh! I
guess you got me. (I note that the current design is internally
limited to "only" a 992-bit keyspace. But I guess that is not enough,
since multiple ciphering has somehow become so important.)
What I think is that you have this idea for a cipher of your own --
not Dynamic Transposition at all, but using transposition -- which you
would really prefer to discuss but just have not done so. The result
is that it gets tangled into the discussion of Dynamic Transposition
in ways that are difficult to separate. Don't do that. If you want
to discuss your design, put it out in a forthright manner.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 27 Jan 2001 14:44:17 -0800
Splaat23 <[EMAIL PROTECTED]> wrote in message news:94vdk8$cem$[EMAIL PROTECTED]...
> God I love that section in _AC_! I was actually laughing when I read
> about the "thermodynamic" limitations in brute-forcing long keys. Kinda
> convinced me that for a 256-bit keyed block cipher, for all eternity,
> will be seure against a brute-force attack. Which reminds me of an
> interesting question about RC6. Gonna post it now.
That AC example was persuasive for me.
This is an important point when viewing predictions about extending
current capability to future ability. Rarely is any thought put into how
the example given should be scaled. Some are like the old "ant the
size of a person argument" Strong enough to lift a car? hardly,
more like too weak to hold itself up. I can't count how many times
I've seen someone (otherwise bright) say "Just think, if you we the
size of an ant, falling off of a countertop would be like falling 500
feet!" No, you'd be falling three feet regardless of how big you were.
There is a reason why Elephants don't jump.
Part of the problem
is this supposed "Moore's law". That's a really bad name. It should
be: "Moore's conjecture" or "Moore's speculation" or maybe even
"Moore's WAG". Isn't this named after Gordon Moore? Partner to
Andy Grove & the late Dr. Robert Noyce and co-founder of Intel?
If my memory serves me right, he's the finance and business
developement guy. Bob Noyce was the tech brains and Andy was
the operational spark plug.
BTW MKS: W.A.G. That's "Wild Ass Guess".
Paul
>
> - Andrew
>
> In article <94vcm7$bic$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > > [EMAIL PROTECTED] (Paul Schlyter) wrote in
> <94c05u$fgv$[EMAIL PROTECTED]>:
> > >
> > > >In article
> > > ><Pine.OSF.4.10.10101201749250.2394-
> [EMAIL PROTECTED]>,
> > > >
> > > >> On Fri, 19 Jan 2001, Paul Pires wrote:
> > > >>
> > > >>> 1024 bit cryptography (If you are talking symmetric) will never
> be
> > > >>> broken
> > > >>
> > > >> Pfffft!
> > > >>
> > > >> Computing power doubles every 18 months or so. Brute force is
> all you
> > > >> need if you have enough power. Within your lifetime, 3xDES will
> be
> > > >> completely crackable.
> > > >
> > > >Lemme see here -- 1xDES is barely crackable now (it can be done on
> > > >custom-built hardware for perhaps $100,000 which is allowed to run
> > > >for a few days on each brute-force key search). If computing power
> > > >doubles every 18 months, then 3xDES will be equally crackable in
> > > >56*18/12 = 84 years. I'm 51 years now, so by then I'll be 135
> > > >years... <g>
> > > >
> > > >Someone who now is 16 years now will be 100 years in 84 years. Not
> > > >very many people live until they are 100 years.... <double g>
> > > >
> > > >And anyone younger than 16 years probably don't know much about
> > > >encryption at all....
> > > >
> > > >Finally: is it reasonable to assume computing power will continue
> to
> > > >double every 18 months also for the next 84 years? We are fast
> > > >approaching the physical limits of microelectronics, so unless
> there
> > > >will be a breakthough in e.g. quantum computing, Moore's law won't
> > > >hold that long.
> > > >
> > >
> > > Actually DES was easily crackable with custom circuits back in
> > > the early 70's at a rate much shorter than a day so where have you
> > > been.
> > > Also it appears if anything Moore's law may be a conservative
> > > estimate and that computing power is increasing much faster so you
> > > may be alive when such a dumb blind search is possible in the
> > > nonblack world.
> >
> > And when this hapens computers won't run on electrons or be made of
> matter.
> >
> > Tom
> >
> > Sent via Deja.com
> > http://www.deja.com/
> >
>
>
> Sent via Deja.com
> http://www.deja.com/
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
** 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
******************************
