Cryptography-Digest Digest #764, Volume #9 Thu, 24 Jun 99 20:13:03 EDT
Contents:
Re: Kryptos article ("Douglas A. Gwyn")
Re: one time pad (AllanW)
Re: What is the recommended maximum length of the MIDI cable between sequencer and
controller? ("rosi")
Re: one time pad ("Douglas A. Gwyn")
Re: one time pad (John Savard)
Re: one time pad (John Savard)
Re: one time pad ("Douglas A. Gwyn")
Re: one time pad (AllanW)
Re: Kryptos article ("Douglas A. Gwyn")
Re: one time pad (John Savard)
Re: one time pad (AllanW)
Re: one time pad (AllanW)
Re: one time pad (John Savard)
Re: one time pad (John Savard)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 22:46:53 GMT
Jim Gillogly wrote:
> With any luck my Dundee Marmalade crock will be visible next to my
> elbow. No, I'm not a member of the Dundee Society -- this was a
> case of "If you buy an outfit you can be a cowboy too."
I suspect you're going to have to explain that (and maybe the outfit
reference as well) to many of the readers.
Even though LDC hasn't been with us for many years now, the Dundee
Society seems to live on, or at least have a room reserved for it --
there's a pointer sign for it in the HQ cafeteria.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 22:20:46 GMT
In article <7krli9$jqr$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
> > For a truly random stream, the likelihood of a value
> > appearing at some point in the stream is _independent_
> > of its appearance at other points in the stream.
> > Randomness is qualitative, not quantitative. IOW,
> > either your stream is random, or it's not. There's
> > no "strength" or "percentage" involved.
In the mathematical sense, this is true. However, computers
are not capable of generating truely random numbers without
specialized hardware; AFAIK, this specialized hardware is
not generally available.
> > If there's any ability to find patterns or correlations
> > in the stream, then the key is not random. It may model
> > randomness in some fashion to some degree, but it's
> > still not random.
I disagree. Truely random numbers will occasionally generate
patterns. For instance, pick nine truely random values in
the range [0...255]. The probability of choosing numbers
that correspond to the phrase "sci.crypt" in ASCII is
extremely remote -- 1 in 2^72. However, this value is much
greater than zero.
Depending on what you mean by "correlations," I might agree
with that part of your statement. If any real-world data
which accurately predicts (or even tends to predict) some
of the data in "the stream," then it is not truely random.
> > For most practical purposes, a well written LFSR (for
> > one example) models randomness well enough that
> > breaking such encryption is relatively rare, but it IS
> > still (at least theoretically) possible.
An interesting statement, considering your earlier assertion:
> > either your stream is random, or it's not. There's
> > no "strength" or "percentage" involved.
If there's no "strength" or "percentage" involved, then what
does "well enough" mean?
> > To truly guarantee against any possibility of the
> > cipher being broken, the key stream must be really and
> > truly random.
But life presents few true guarantees. What we need isn't
absolute guarantees, but practical guarantees. And since
computers (in the absence of special hardware which is not
generally available) are not capable of generating data
which is not absolutely random, we can compromise on data
which is practically random.
For this, we generally apply a series of tests to the
pseudo-random stream. For instance, we use distribution
tests to ensure that our pseudo-random stream doesn't
favor one value over another, and we use correlation
tests to ensure that the presence of one value in the
stream doesn't tend to correlate with a later value.
But what we're doing here is measuring our pseudo-random
stream against known weaknesses. It is significant to
note that if we used truely-random data against these
same tests, they would occasionally fail!
> Let me begin by saying this is the first time here, and I am
> quite surprised at how some people participate here. I wish
> my correspondences to remain at the highest technical level
> possible.
I hope you haven't encountered anything else.
> First, in my first post, I used the term "statistical"
> randomness.
Yes. The tests that I mentioned above are all statistical
in nature; we look for known weaknesses and try to prove
that our pseudo-random data isn't subject to it.
> It is a term I received when reading about PI, which is
> supposively the most statistically random sequence of
> digits known to man. By this, it is [meant] that the
> digits are generally well distributed, and that they
> occur approximately as often as each other- that [1's]
> occur as frequently as 2's, which occur as frequently
> as..., you get the idea.
But using any known reference, even the digits of PI,
jeapordizes the OTP algorithm. The reason that a random
stream is useful is that, given N bytes of the stream, it
is impossible to predict what byte N+1 will be. When you
use digits of PI (or a "random number table" or any other
fixed table), this is no longer true.
Suppose that you somehow picked a truely random number
from 1 to 1,000,000. You skip that number of digits of
PI, and then begin using the rest. This is still not
secure because the values are still known in advance.
Once you have found the first digit of the random
sequence, you have elimintated approximately 900,000
possible starting positions; once you have found two
digits, you have eliminated approximately 990,000
possible starting positions, and so on. Or consider the
brute force method: Assume that the random sequence
started with the first digit of PI, and try to decrypt
it. If that fails, try again with the second digit, and
so on. Within 1,000,000 attempts you will succeed.
We can make the search somewhat longer by selecting not
only a random starting position, but also a random
skip-size (i.e. start with digit 100, then skip 2 after
ever digit used, so that we use digits 100, 103, 106,
109, etc.). But the brute-force attack still succeeds
much too quickly.
> When you say that randomness is a quality, I agree. Statistical
> randomness is a measure of the quantities to yield a quality.
But beware of attaching too much importance to any one test.
For instance, the sequence 12345678901234567890 has a 100%
success rate for a distribution test, but very few people
would consider it useful.
> Also, a OTP's strength is entirely found in the fact that
> given a cipher stream only, any plain text stream is an
> equal candidate to be the true plain text.
Yes. That's why OTP is unbreakable if the pad is truely random.
> Now to the point. If we say that a OTP has truly random
> values and that the pad's contents are totally independent
> of each other, then there is the extremely low possibility
> for a series of bits to display a pattern, though the
> pattern may never occur again. For example, there could
> occur a series of BYTE values 0xa7 (or any value) that
> repeats, say, 100 times.
Correct.
> I proposed this ment nothing, until someone disagreed with
> me and advocated I turn to this forum for advise and
> insight.
If the stream came from a truely random source, it would mean
nothing. In fact, such meaningless patterns might help to
thwart attacks by appearing to mean something.
However, real-world algorithms do not have access to truely-
random data, so they must use pseudo-random number streams.
If your pseudo-random number generator creates such a pattern
once, it *WILL* do so again sometime (whenever the "starting
seed" is the same). So here it actually indicates a very
important weakness in the system.
> So I ask you, does it make sense that randomness is a
> requirement, that patterns must be avoided, in building
> a one time pad?
Yes.
> It appeared to me that this individual is correct. For
> example, if you take a long sentence of 100 characters
> and you apply the segment of the pad to it and someone
> guesses that the segment is in fact all 0xa7, then one
> would have to conclude that the proposed candidate is
> indeed the plain text because the odds against it
> appear astronimcal.
But as you pointed out, if the pad was truely random then
each possible output is statistically neither more nor
less likely to be correct. If you guess that the pad has
some particular pattern and the output appears to make
sense, that doesn't in general mean that your guess was
correct.
(One way to calculate the key value is to make guesses
about part of the plaintext, and then calculate backwards
to get the pad. No matter what you want the plaintext to
be, there is some hypothetical pad that will generate
that text.)
On the other hand, a pseudo-random number generator that
happens to create 100 0xa7's in a row would be considered
broken by almost anyone's standard. But using that pad
to decrypt a message also has "astronomical" odds against
generating meaningful plaintext. So if this pad does
happen to generate meaningful plaintext, most people would
assume that they did indeed make a correct guess, and that
the system's pseudo-random number generator was defective.
In real life, such an event is just as likely to mean that
the message was a decoy, and that the senders intended for
the interceptors to be able to decrypt it.
> so I wonder now just how much relationship must occur
> in build a pad. It seems that weak statistical
> randomness must be employed if nothing else but to
> prevent this scenario.
My first-ever "encryption" program simply XOR-ed the
password with the plaintext. Such a scheme has far too
many weaknesses to list here, but the reason that even
my naive little brain realized the biggest weakness so
quickly was due to a coincidence in the ASCII codes.
In ASCII, if you XOR an upper-case letter with 0x20,
you get the equivalent lower-case letter, and vice-versa.
But the value 0x20 also happens to be the character code
for a space. So what I found was that if the plaintext
had several spaces in a row (this is quite common for
program source code, for instance), the encrypted text
clearly showed the password in reverse case. For instance,
if the password was "SECRET" then the weak program would
write "secret" whenever it encrypted six spaces in a row.
My point is, patterns in the pad can indeed create a
weakness in the encryption, even if they are mere
coincidences. Consider the not-impossible case where
the random stream generated a large number of 0's in
a row. For most implementations of OTP, this would cause
the ciphertext to be equivalent to the plaintext!
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: rec.music.makers.synth
Subject: Re: What is the recommended maximum length of the MIDI cable between
sequencer and controller?
Date: Thu, 24 Jun 1999 18:12:18 -0400
What I click is what I see.
My message sent to sci.crypt was not this one, but what I see now
is the attached.
This is definitely a bug at the ISP. What seems to amuse me is
that all others in the thread I checked are on the appropriate
topic.
If anybody else sees this in sci.crypt, please ignore. Thanks.
--- (My Signature)
====================================================
The signature by me is as good as mine by any other.
[EMAIL PROTECTED]
=====================================
Attachment ---------------------------------------
Crease wrote in message <[EMAIL PROTECTED]>...
>On Mon, 21 Jun 1999 19:34:15 -0400, in rec.music.makers.synth "Charles
>McInnis" <[EMAIL PROTECTED]> wrote:
>
>>What would a good quality 186 mile long midi cable go for?
>>
>
>I heard that Guitar Center was blowing out 200 mile cables this
>weekend. : )
>
>>
>>Bill <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]...
>>> bln wrote:
>>> >
>>> > So, if the length of the MIDI cable does matter, what is the
recommended
>>> > maximum length of the MIDI cable between sequencer and controller?
It's
>>> > obvious that the closer the better, but could anybody tell me the
>>maximum
>>> > length that will not cause any timing problems?
>>>
>>> Measurable "timing problems" caused by excess cable length would start
>>> to show up when the total cable length approaches 186 miles, at which
>>> point you'd be seeing delays in the neighborhood of one millisecond. It
>>> would take many times that delay to become noticeable.
>>>
>>> On the other hand, corruption of the MIDI data (missing notes, stuck
>>> notes, assorted weird behavior) will start to show up a long time before
>>> that. MIDI spec dictates that cables should be no longer than
>>> approximately 50 feet. You can get away with longer runs if you're
>>> using really good cable, and you'll get away with less if you're using
>>> lousy cable.
>>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:02:51 GMT
"Douglas A. Gwyn" wrote:
> ... For example, ciphertext
> 0010 is equally likely to be: (plain,key)=(0010,0000) or
> (0001,0011) or (0100,0110).
Furthermore, if you modified the OTP system so that "highly
patterned keys" such as 0000 were never used, the cryptanalyst
could be *certain* that the message was actually (0001,0011)
or (0100,0110), but definitely not (0010,0000). which means that
he has gained information he would not have been able to obtain
if you had left the OTP keys alone. That should illustrate the
folly of pre-filtering the OTP keys to eliminate "patterns".
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:33:44 GMT
Greg Ofiesh <[EMAIL PROTECTED]> wrote, in part:
>Predictability can be hampered by limitations, but it turns out that
>predictability is not an issue. The issue is minimizing patters while
>maximizing message candidates that the opponent must choose from. And
>every message candidate must be given the illusion of having the same
>probability of being correct as the correct message has.
In practice, one doesn't worry about the generator producing all
zeroes, while one also doesn't worry about the recipient being
confused by the OTP + plaintext = ciphertext that looks just like a
different plaintext message...
But this is an interesting question. Can one pre-process the plaintext
(expanding it slightly) so that a pre-conditioned key that is forced
to "look" random still gives perfect OTP encryption?
Yes!
Let's encrypt our ciphertext by using a Wheatstone cryptograph (in, I
believe, the mode normally used for decipherment). This expands the
ciphertext by increasing the size of its alphabet by one, and gives it
the property that no two letters in the ciphertext can be the same.
Hence, our processed "plaintext" has the property that although it is
in an alphabet of N letters, there are only N-1 possibilities for each
individual letter.
Let us now similarly condition a random keystream, chosen from an
alphabet of N-1 letters. Since there are now no repeats in the
resulting keystream, it "looks" random.
How to combine the two? Decrypt both, using a Wheatstone cryptograph
with a different alphabetic sequence from the original one, use the
Vigenere table...
"But that's cheating!" you'll say. Or is it, since I did use a
different alphabet on the deciphering Wheatstone cryptograph...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:22:31 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>On Thu, 24 Jun 1999 00:23:06 GMT, in <7krtp0$mpl$[EMAIL PROTECTED]>, in
>sci.crypt Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>>You can say that EC or IFP encryption cannot guarantee encryption
>"EC"? "IFP"?
>>because it is possible to attack it using various methods. In any of
>>these methods, if successful, the result is certain to be correct
>>because there can only be one solution that fits the puzzle with only
>>the cipher stream in hand.
>Not always. Some techniques can have sufficient keyspace to produce
>every possible encryption for messages of some maximum length.
Since I think "EC" stands for Elliptic Curve, probably IFP is another
public-key method, and of course it is public-key methods that (at
least usually) have the specific weakness cited. Even when the message
has no redundancy, so that any keyspace would be sufficient to create
some ambiguity for conventional encryption.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 22:55:30 GMT
AllanW wrote:
> My point is, patterns in the pad can indeed create a
> weakness in the encryption, even if they are mere
> coincidences. Consider the not-impossible case where
> the random stream generated a large number of 0's in
> a row. For most implementations of OTP, this would cause
> the ciphertext to be equivalent to the plaintext!
Irrelevant. See other postings for explanation.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:09:22 GMT
In article <7ktn6b$aqk$[EMAIL PROTECTED]>,
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
>
> > > How many aeons did you say you had to look through this list?
> >
> > It's irrelevant. The point is that as long as 100 0xa7's in
> > a row is exactly as likely as any other sequence of 100
> > characters, the attacker has no better idea that this
> > particular decryption is valid compared to all the others
> > that his criteria says are plausible.
>
> This is exactly what I disagree with. First, the odds that
> 100 0xa7's would occur are astronomical.
But the odds that the first byte is 0x14, and the second byte
is 0x22, and the third byte is 0x15, and so on ... pick any
numbers as you go .. are equally astronomical. And yet one
(and only one) such sequence is correct.
> Then the fact that a valid candidate would [match] anything
> is astonomical (since they all have 1 in astronomical
> chances). But then you combine the two and you have
> astronomical squared. That has got to give weight, don't
> you think?
This concept has value IF (and only if) it is possible that
the encryption program was faulty; specifically, by having
a PRNG return the same value over and over, and also IF we
know that the sender never bothered to check for this
possibility. This could occur:
* If the programmer was incompetent, believing himself to
know much more about encryption than he really does,
or
* If the PRNG was changed after the program was written,
either by sabotage or accident, or intentionally by
an incompetent programmer.
In either case, the sender would have to accept on blind
faith the proposition that the faulty program was a secure
encryption program, when in reality this was untrue.
OR, the sender could intentionally "break" the program so
that the encryption was easy to crack, in order to plant
disinformation.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kryptos article
Date: Thu, 24 Jun 1999 22:34:46 GMT
Jim Gillogly wrote:
> Each of the systems so far would be solvable by most ACA members
> with sufficient time, if armed with the knowledge that it was in
> fact solvable. A positive mental attitude is a real key to this
> kind of thing.
I agree, and it is a point driven home by MilCryp and the Zendian
problem.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:39:27 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>So what clue does the cryptanalyst have that
>*this* good plaintext is any more correct than it was those zillions
>of other times (in his Methuselah-like lifetime) when he obtained
>good plaintexts that turned out to be incorrect decryptions?
But in real life, our RBG might generate all zeroes because of a short
circuit, and sending out plaintext every time that happened is not a
good idea. There is a problem here, but eliminating a tiny fraction of
"obviously bad" sequences will normally only eliminate a number of
nonsense plaintexts that wouldn't be accepted anyways.
Doubtless, there are ways of really dealing with this problem, such as
conventionally encrypting both the plaintext and the RBG output. I've
been inspired by the Wheatstone cryptograph to propose one way of
combining constrained random bits with constrained plaintext to
maintain the OTP condition, but it's rather silly and limited. I
think, though, that there are things to be found in the mathematics of
quasi-random sequences.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 22:56:40 GMT
[EMAIL PROTECTED] wrote:
> Identical and independent distribution. (Actually this
> doesn't guarantee non-predictability.) Independence [is]
> more inportant.
The truely important thing is non-predictability. But we
must measure "predictability" on a wide scale: just because
we don't know how to predict something, doesn't mean that
it can't be predicted by someone else. So we need to be
omniscient in order to guarantee non-predictibility.
Since only The Internet Oracle is omniscient, and since he
can't be bothered to code our PRNG for us, we must apply
heuristics to ensure that our data doesn't SEEM to be
predictable. Thus our distribution frequencies, our tables
of correlation, etc. While these can prove deficiencies in
many poor PRNG algorithms, it can never actually proove that
some PRNG algorithm is good.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:45:45 GMT
Greg Ofiesh <[EMAIL PROTECTED]> wrote:
> Tell me what you think. If a pure and perfect (okay,
> theoretical) random generator can produce any sequence
> of bits, and no bit is dependent on any other, then
> you could theoretically produce streams of obvious
> patterns.
Yes, once in a very great while.
> And this should produce weaknesses in the pad.
No. Nobody would ever look for such a pattern because
statistically it would occur 0 times during the lifetime
of this planet.
But if someone were to be crazy enough to look for it,
AND by some magic happened to stumble across it, then
everybody would suspect that the algorithm was faulty.
(Consider what would happen if the lottery ping-pong balls
happend to draw numbers 1 - 2 - 3 - 4 - 5 - 6. This is
exactly as likely as any other set of numbers, no more
and no less -- and yet I predict that lottery officials
would refuse to pay any winners while they launched an
investigation that might never end.)
But if someone were to be crazy enough to look for it,
AND by some magic happened to stumble across it, AND
the sender decided to trust the algorithm again anyway:
then it would still be secure.
> Therefore, I put forth that some control must be
> maintained and that the random bits cannot be whole
> random. Furthermore, the controls must have wide margins
> to avoid weaknesses within itself.
Sorry, but for reasons already explained this simply is
not so.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:45:36 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>Let's encrypt our ciphertext by using a Wheatstone cryptograph (in, I
>believe, the mode normally used for decipherment). This expands the
>ciphertext by increasing the size of its alphabet by one, and gives it
>the property that no two letters in the ciphertext can be the same.
>Hence, our processed "plaintext" has the property that although it is
>in an alphabet of N letters, there are only N-1 possibilities for each
>individual letter.
>Let us now similarly condition a random keystream, chosen from an
>alphabet of N-1 letters. Since there are now no repeats in the
>resulting keystream, it "looks" random.
>How to combine the two? Decrypt both, using a Wheatstone cryptograph
>with a different alphabetic sequence from the original one, use the
>Vigenere table...
Here's a simpler example, but with the same defect.
Translate our message and the keystream with the following table:
0: 01
1: 10
Then combine the two by the following rule
+ | 01 10
===========
01 | 01 10
10 | 10 01
and you've used a keystream, constrained that every pair of bits
marked off from the start has a 0 bit and a 1 bit, to perform a true
OTP!
Because, of course, all you were doing was an XOR in disguise.
But there _are_ nontrivial (seeming?) ways of doing this, I believe,
even if I can't whip one up off the top of my head.
After all, many forms of encoding for digital tape recording use the
Wheatstone cryptograph principle, for example. Or something using
error-correcting codes might be genuinely nontrivial.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Thu, 24 Jun 1999 23:51:15 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>Alas, we also *cannot* know whether a pad is "good" or not. Any pad
>we create may have some predictable pattern of which we are unaware.
>No tests can assure us otherwise. We use any pad at all at risk of
>failure when our opponents find something we missed.
>We have no proof because there really *is* no proof. These are not
>just word games. Our supposedly invulnerable OTP might fail and we
>probably would never know, and would go on using that same failing
>cipher, all while claiming it to be invulnerable. *That* is the
>consequence of having no proof.
I suppose, though, that the odds of generating a bit stream by
flipping a coin that happens to match, say, the output of a simple
shift-register or mixed congruential generator - hence leading to my
message being decrypted by a cryptanalyst who didn't realize I was
using an OTP...
are much smaller than the odds of the bit stream I generate, plus my
plaintext, producing a ciphertext that could have been produced by
some other plaintext plus a poor stream cipher.
In fact, the chance is smaller by exactly 1/N, where N is the number
of possible plaintexts. That _is_ as perfect as security gets.
*Nothing* can prevent the cryptanalyst from reading your message by
making a lucky guess, but I can't really call that a weakness in a
cipher method. (Of course, I could just be misunderstanding your
point.)
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
** 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
******************************
