Cryptography-Digest Digest #928, Volume #8 Mon, 18 Jan 99 20:13:02 EST
Contents:
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: Practical True Random Number Generator (Mok-Kong Shen)
Re: Contents of server gated certificates (Dick Perkins)
Re: On the Generation of Pseudo-OTP ("Trevor Jackson, III")
Re: On the Generation of Pseudo-OTP (Frank Gifford)
Re: Cayley-Purser algorithm? (Darren New)
Re: Trying to find simple, yet effective implementation of crypto... (Darren New)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: On the Generation of Pseudo-OTP (R. Knauer)
Re: Metaphysics Of Randomness (R. Knauer)
Re: On the Generation of Pseudo-OTP ("Trevor Jackson, III")
An idea for an Encryption Algorithm ... thoughts please. ("Rats")
Re: Cayley-Purser algorithm? (Derek Bell)
Re: long numbers math - how to ? ("Erik Ungern")
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
Re: Trusts (Dale R Worley)
Re: A further descent in Nullism (Dale R Worley)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 18:46:34 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 18 Jan 1999 12:09:55 -0600, Jim Felling
<[EMAIL PROTECTED]> wrote:
>I had said that if a 'real' number such as pi is used as a OTP source it
>must be evaluated as to its statistical behavior in the 'locality' that the
>data is drawn from as it is guaranteed to have good statistical properties
>only over the whole of its decimal expansion and not over any finite
>subregion however large.
The original specification for using digit expansion included
provision for some scheme to decorrelate the sequence. Thus far there
have been three recommendations, namely, CRC, LZ77 and Latin Square.
Antiskewing, assuming skew is present in the selected sequence, can be
accomplished securely with known methods such as described in RFC
1750.
>Someone then brought up the excellent point that
>this is also true of a TRNG. My above comment is in response to that
>point.
I do not see that. A TRNG begins with a first random bit and continues
like that generating a random sequence. I must be missing something,
because I see no relationship between the way a TRNG works and the
digit expansion of a transcendental constant like pi.
The main point is that whatever the output of the TRNG, it is a random
output because it is one of the possible sequneces of given length
that is equiprobable with all other sequences. There is no
characteristic of the sequence per se that makes it random or
non-random. It is random because it is generated from a TRNG, and that
is sufficient to make it proveably secure.
What makes a RNG unsecure is when it disobeys its prime directive,
namely to be capable of outputting all possible sequences of a given
length equiprobably. If a RNG outputs only a partial group of
sequences, like a seeded PRNG, then the cryptanalyst can use that to
break the cipher eventually.
>We must (due to our computing methods) evaluate it over a large and
>finite subset, and thus should take pains to assure ourselves that that
>subset has appropriate statistical behaviors.
That is not a problem if the starting point for the digit expansion is
different for each cipher. In that case the pads behave as you
describe right below for a TRNG.
>With a TRNG we are
>effectively sampling from a continuous spectrum and thus avoid the problem
>of potential analysis of the 'space' from which we draw our numbers. Were we
>able to chose in a repeatable way a completely arbitrary starting point in
>the number being used and generate digits from that point we would be free
>of that, but we possess no such algorithm( we possess a digital expansion
>algorithm, but it will balk at giving us digits starting at an arbitrary
>2^(2^(2^1000)) digit number simply due to the amount of storage such a
>humongeous number will entail.
But that was what the proposal for the digit expansion generator
required. Anyway, a starting point the size 2^128 should keep the
cryptanalyst busy checking out all the possible offsets.
>Continuous processes are free of this limit
>and therefore in my opinion do not need to comply to a condition specifying
>'good behavior' in the subset being evaluated.
That seems to be saying that a TRNG does not suffer from that problem.
Do you agree that a digit expansion generator started at arbitrarily
large offsets behaves the same as a TRNG in that regard?
BTW, what statistical tests would you perform to validate a sequence?
Bob Knauer
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power and magic in it."
--Goethe
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Practical True Random Number Generator
Date: Tue, 12 Jan 1999 20:27:56 +0100
R. Knauer wrote:
> >I don't see why the modified version is better than the original.
>
> You are introducing symmetry into the measurements, and now the
> direction of time does not matter - so systematic errors such as the
> decay of the radioactive source over time are cancelled and cannot
> cause bias in the bitstream.
Sorry, being not a physicist, I find it difficult to understand
the 'direction of time'. Isn't it that time is uni-directional?
Or could you refer to literature on perhaps the reversal of the
direction of time? Thanks in advance.
M. K. Shen
------------------------------
From: Dick Perkins <[EMAIL PROTECTED]>
Subject: Re: Contents of server gated certificates
Date: Sun, 17 Jan 1999 21:46:00 +0000
In article <[EMAIL PROTECTED]>, Eric Norman
<[EMAIL PROTECTED]> writes
>Paul Rubin wrote:
>
>> So can you load new SGC roots into the browsers???
>
>Well if you can't, then why bother with the certificate
>extension at all? Why not just wire the public key into
>the code?
>
There must be some mechanism to prevent unauthorised people outside the
US from using strong crypto. Just hard wiring Verisign's root ceriticate
into browsers would seem to result in a monopoly position. I'm very
surprised to hear that there's nothing cryptographic in these
certificates.
Dick Perkins
------------------------------
Date: Mon, 18 Jan 1999 15:06:17 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Terry Ritter wrote:
> I'm not willing to concede this. It seems to me that the result of
> any reversible operation (1:1 with the same number of unique values in
> the domain and range) will still possess the randomness properties.
> And an operation which reduces the range may also have those
> properties.
This appears to be a fundamental issue. I.e., if I have a set of messages
where the messages are long (L) and there are a small number of such
messages (N) then the "randomness" of each message is based on the number
of them rather than the length of them.
If the messages are selected with equal probability, then each encodes
log(N) bits of information rather than log(L). If we mess with the
messages in some deterministic manner, producing a characteristic hash
value, we'll want the hashes to be of length Log(N).
Any such deterministic algorithm leaves the amount of information in the
hash the same as the amount of information in the original messages. The
hash algorithm does not impose additional correlations upon the mesages
that are processed.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: On the Generation of Pseudo-OTP
Date: 18 Jan 1999 14:28:10 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Mon, 18 Jan 1999 12:09:55 -0600, Jim Felling
><[EMAIL PROTECTED]> wrote:
>
>>Continuous processes are free of this limit
>>and therefore in my opinion do not need to comply to a condition specifying
>>'good behavior' in the subset being evaluated.
>
>That seems to be saying that a TRNG does not suffer from that problem.
>Do you agree that a digit expansion generator started at arbitrarily
>large offsets behaves the same as a TRNG in that regard?
I would disagree. How would you prove that a digit expansion can look
like a TRNG? What properties would you use for the proof? What properties
would you have to overlook?
You would have to prove that if the cryptographer managed to learn all
but one digit of the sequence (someone on the inside gave away most of the
sequence, for example), that it is IMPOSSIBLE for him to determine the one
unknown digit. [Let's assume a normal-sized message of around 10KB too...]
By definition, a TRNG is immune from this attack. But a digit expansion
might not be. Since it's generated by an algorithm, you would need proof
that it is intractable. Saying that it is equivalent to factoring is still
much weaker than a TRNG, even if the work space might be 2^4096.
I understand you aren't advocating an algorithm to create a TRNG, but a
TRNG is something which has so many requirements that you have to have the
whole thing. Any _subset_ of the TRNG properties should be able to be made
into an algorithm, but having all the properties together is another matter.
-Giff
--
[EMAIL PROTECTED] Too busy for a .sig
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Cayley-Purser algorithm?
Date: Mon, 18 Jan 1999 20:16:12 GMT
Ray Girvan wrote:
> Also, if the work was done while on work experience, is she in
> any position to decide whether it should be patented or published?
> Work done on company time usually belongs to the company.
Well, that would depend on what she signed with the company, at least in
the USA. Generally, in the US, the individual is the inventor. You sign
over to the company not the invention but an exclusive license to use
it. In return for this, you get paid something (aka "good and valuable
consideration"). If she didn't sign any contracts, then the invention is
hers to do with as she will, if she cares to fight it in court if the
company cares to fight it in court.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Trying to find simple, yet effective implementation of crypto...
Date: Mon, 18 Jan 1999 20:58:58 GMT
Tim Mavers wrote:
> what to do). Since I don't want anyone knowing my protocol (it's a very
> basic one, but if known by all, malicious acts can be done).
Can people do malicious acts if they know the protocol? Or just if they
can use the protocol and you can't tell it's the wrong person using it?
A nice way to sign something is to have each client have a secret, and
append to each message sent a few random bytes (otherwise ignored), then
generate a hash of message+randombytes+clientsecret and append that to
the message. The server knows each client's secret, and the clients each
know the server's secret, so everyone can tell efficiently if the
messages are coming from the right people. This doesn't prevent some
attacks (like replay attacks) unless you timestamp messages or some
such, but it may prevent the need for you coming up with a more secure
encryption, depending on what your needs are. The advantage is that
hashes tend to be much faster than full-blown encryption, particularly
public-key encryption.
Doing real encryption is probably a better idea if what you're sending
around is actually important, in the sense that it'll cost money in ways
that are hard to detect before it's too late.
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"You could even do it in C++, though that should only be done
by folks who think that self-flagellation is for the effete."
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 21:24:17 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 18 Jan 1999 15:08:45 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> If you can compute a number or manipulate it by algorithmic means,
>> then you have introduced some degree of non-randomness because of the
>> procedural nature of the computation.
>I believe this statement to be false. Can you substantiate it?
Yes, as has been shown by some trivial examples, the statement above
is not correct in all cases - it depends on the kind of computation
you are talking about.
For example, XORing a sequence with 111...1 does not change the
randomness of the sequence, but bit-wise ANDing it with 111...1 does
ruin the randomness.
So why is the statement correct under some conditions and not others?
Bob Knauer
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power and magic in it."
--Goethe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On the Generation of Pseudo-OTP
Date: Mon, 18 Jan 1999 21:31:10 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 18 Jan 1999 15:06:17 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Any such deterministic algorithm
What other kind of algorithm is there but a deterministic algorithm?
Or are you thinking of something like Chaitin's Omega?
Bob Knauer
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power and magic in it."
--Goethe
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Mon, 18 Jan 1999 21:17:48 GMT
Reply-To: [EMAIL PROTECTED]
On 18 Jan 1999 14:35:23 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>The point at which the unicity point of the cryptographic system
>becomes smaller than -- or becomes uncomfortably close to, depending
>on your degree of paranoia -- the length of the message.
>"Uncomfortably close to," can, of course, encompass a whole myriad
>of numbers. If you're *really* paranoid, the point at which the
>key is smaller than the message.
Is it correct to say that the considerations of this subthread you
posted are entirely based on the concept of Unicity Distance?
I thought your central thesis was that all small messages were secure
with any decent "random" key.
Bob Knauer
"Whatever you can do, or dream you can, begin it. Boldness has
genius, power and magic in it."
--Goethe
------------------------------
Date: Mon, 18 Jan 1999 15:08:45 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
R. Knauer wrote:
> If you can compute a number or manipulate it by algorithmic means,
> then you have introduced some degree of non-randomness because of the
> procedural nature of the computation.
I believe this statement to be false. Can you substantiate it?
------------------------------
From: "Rats" <[EMAIL PROTECTED]>
Subject: An idea for an Encryption Algorithm ... thoughts please.
Date: Tue, 19 Jan 1999 11:04:53 +1300
There are 256 chars in the ASCII set. 256 -> 8 bits (a byte).
Use a Seed to scramble the 256 chars and get an initial condition for a code
wheel.
Extract a byte of data from a stream and encrypt it using the code wheel.
Create another code wheel using the first code wheel and encrypt the next
byte extracted from the stream.
Repeat until data is encrypted.
I guess depending on how the intitial conditions are being setup and how the
code wheel is created from the previous code wheel would decide how secure
the method is.
Any thoughts and comments.
Thanks in advance.
Rats
------------------------------
From: [EMAIL PROTECTED] (Derek Bell)
Subject: Re: Cayley-Purser algorithm?
Date: 18 Jan 1999 22:28:48 -0000
[EMAIL PROTECTED] writes:
> Bruce you say that because of your prejuiduces.
I suspect that Bruce has seen so many stories that were based on
exagerrated media reports, he may be just a bit cynical of another story in the
papers that doesn't contain much technical detail.
Personally, I think there may be something in it, as Dr. Michael Purser
has experience in crypto; he used to give lectures on crypto here in TCD's
maths dept; I think he was also involved with Baltimore Technologies.
> But the sad truth of the matter is if was good I think the
>NSA would have been able to keep the lid on it.
Like they did with RSA? :-)
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: "Erik Ungern" <[EMAIL PROTECTED]>
Subject: Re: long numbers math - how to ?
Date: Tue, 19 Jan 1999 00:31:44 GMT
From: Erik Ungern <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Erik j Ungern <[EMAIL PROTECTED]>
Subject: Factoring Software
Date: Sunday, January 17, 1999 1:03 PM
Hi!
There is a high powered number theory/factoring version of basic located
at
http://www.vector.co.jp/common/dos/prog/basic/ubasic/00_index.html
You will need to unzip 5 files. The instructions are in UBHELP.XXX and
print about 90 pages in English.
The site is Japanese and the descriptions of the downloadable files are
partially garbled, but the downloads themselves are fine.
Have
fun,
Erik
Ungern
[EMAIL PROTECTED]
Rx Video wrote in message ...
>Hello,
>
>I'm looking for some information on how to implement the long numbers
>calculations. I have some ideas of my own, but I'm sure there are some
>better solutions. If anybody knows of some articles on the subject, or
>has tried to do it, please, let me know. I'm looking for conceptual
>(theoretical) solutions.
>Sincerely yours,
>
>Martin
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Tue, 19 Jan 1999 00:40:09 GMT
Ed Gerk wrote:
> [EMAIL PROTECTED] wrote:
> > Here are issues I've been speaking about:
> >
> > * Presenting an adversary with less ciphertext than the unicity
> > distance of the secrecy system does _not_ ensure that he can
> > obtain no useful information from the ciphertext.
> >
>
> Bryan:
>
> One may try to be quaint and say that just detecting ciphertext is a useful
> information that the attacker can obtain -- however, I may send bogus messages
> with random letters once in a while and even that modicum is not granted.
No quaintness here. See the quote from Shannon in my post of
Jan 8.
Sending bogus messages is a non-issue. Each of them also has
an /a priori/ probability and Shannon's model still applies.
> However, this is all besides the point of my original e-mail. To which I would
> like to refer to. Our dialogue was:
>
> |Ed Gerck wrote:
> |> 1. First, I wish to point out that Theoretically-Secure Cryptographic
> |> Systems (hereafter TSCS) do not depend on key-length for secrecy --
> |> in their design region. In fact, Shannon already showed 50 years ago
> |> that a TSCS does not depend on key-length when one works within the
> |> system's "unicity distance".
>
> |Bryan replied:
> |Staying within the unicity distance only ensures that
> |more than one possible decryption exists. A cryptanalyst
> |may still get large amounts of useful information.
>
> A system that carries a one-bit message "yes" or "no" and is encrypted by XOR
> with a one-bit secret-key is theoreticallt secure. Even though the attacker
> may know that I can send either "yes" or "no". So, in its design region of
> only one bit, the system as I exemplified is theoretically secure. The
> attacker cannot decide what was sent.
>
> This contradicts what you replied at the least possible level -- one bit of
> key-length, which was the design region.
Huh?? That's an example of theoretically secure system (in the
sense of perfect secrecy). Nothing is shown to follow from unicity
distance (which isn't even mentioned or calculated).
> Perhaps, my four words "in their design region" went unnoticed by you. But,
> they are clearly there -- also implicity, when I wrote "within the system's
> "unicity distance". Again, your comments must not ignore what you want to
> comment .. the text as I wrote it.
"In their design region" is implicitly in what Shannon proved????
Shannon didn't use any undefined nonsense like that.
My quote clarifies what's really in Shannon's paper. If we have not
reached the unicity distance of a cryptogram, then more than one
plausible solution exists. Does that imply an attacker can get no
useful information from the ciphertext? No it does not.
> The bottomline here is that key-length is NOT what can define if a system is
> theoretically secure or not -- but its unicity. A system can have very low
> key-length, in fact just one bit, and be theoretically secure. But, I guess I
> said that already ;-)
Bad bottom line. If unicity defines theoretic security why would
we need this "design region" nonsense? I think Shannon got it
right when he characterized the security of a secrecy system by
the information an attacker can gain from the ciphertext.
> > * If ciphertext contains no information about the corresponding
> > plaintext, we have perfect secrecy. Perfect secrecy is a strictly
> > stronger condition than lack of unique solution.
>
> You are venturing into a slippery slope. Of course, the ciphertext must
> contain information about the corresponding plaintext, otherwise you could
> not decipher it. The question is how much can you gather from it.
A perfect secrecy system has the property that mutual information
in the plaintext and ciphertext is 0. The mutual information in
the plaintext and key is also 0. The mutual information in the
plaintext and the pair (ciphertext, key) is the entire entropy of
the plaintext.
> However, you will NOT find ONE occurrence of the word "perfect" or "perfect
> secrecy" in my message -- nor in the full text at
> http://www.mcg.org.br/unicity.txt. So, I must assume you are confusing
> "theoretically secure systems" with "perfect secrecy".
No, I am _distinguishing_ perfect secrecy from a weaker condition.
Never did I claim Ed talked about perfect secrecy; I listed it under
the issues that I was talking about.
I brought up perfect secrecy because I find it relevant to the
discussion. A system in which an attacker cannot get enough
ciphertext to cover the unicity distance necessarily has a
form of theoretical security - namely that the attacker cannot
get all of the information in the plaintext. A system with
perfect secrecy has a much stronger form of theoretical
security: an attacker cannot get _any_ of the information in
the plaintext. Of course both of these assume the Shannon
model in which the attacker does not have any key information.
> And, I guess that you are now reading more than what I wrote, while before
> you were reading less -- as when you missed that I wrote my four words "in
> their design region".
Of course I read more than Ed wrote. I've cited and quoted some
of it too.
> > * The unicity distance of ASCII-encoded English under DES is greater
> > than one DES block.
>
> As I prove in http://www.mcg.org.br/nrdes.txt and use in
> http://www.mcg.org.b/unicity.txt, DES unicity cannot be larger than one block
> because DES is not a random cipher over more than one block. If you disagree,
> plas contradict my proof in nrdes.txt.
Fair enough. The first major error is the incorrect assertion
of how Shannon defined unicity distance. Shannon in fact defines
it as "the number of intercepted letters" (page 692) such that the
equivocation of the key becomes nearly zero. Ed's text assumes
the analyst has one or two 8-byte blocks that decrypt into
8-byte English strings. He the claims a unicity distance less
than the amount of intercepted text, which is wrong since the
unicity distance is, by definition, the amount of intercepted text.
> Accordindgly, I observed that the basic assumption used by Shannon to define
> and calculate unicity is not valid over more than one block of DES.
Agreed. Multiple block of DES are not a reasonable approximation to
a random cipher.
> To say
> otherwise is to use a formula where it is not valid -- rubbish in, rubbish
> out.
>
> So, what you are saying contradicts the application region of the formula --
> nothwithstanding the good company you may be with when you cite that. So, this
> is more of a "literature mistake" and I undesrtand you were just perfunctorily
> requoting.
Nonsense. I claimed that the unicity distance of ASCII/English
DES is more than one block. Applying the random cipher model to
just one block shows that we do not yet expect a unique solution,
and therefore the unicity distance is more than one block.
Also, note that on page 699 Shannon explains why the random
cipher has the _smallest_ expected unicity distance of any cipher
for a given message space and key space. If the random cipher
model fails, that could make the unicity distance larger, but not
smaller. One can easily prove that unicity distance is at least
H(K)/D, since at this point the number of intercepted letters is
the same as the entropy, measured in letters, of key and
plaintext.
--Bryan
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Dale R Worley)
Subject: Re: Trusts
Date: Tue, 19 Jan 1999 01:00:27 GMT
In article <[EMAIL PROTECTED]> Anonymous <[EMAIL PROTECTED]> writes:
They claim that this is secure because it's
infeasible to spoof a TCP/IP session, ie mount a
man-in-the-middle attack by replacing the exchanged
DH-keys on-the fly.
Well, surely it's *possible* to do a man-in-the-middle attack, since
(obviously) if you've been watching all the packets flying back and
forth since the beginning of the TCP/IP session, you know the state at
both ends of the connection. But it's a lot *harder* to do that than
it is to eavesdrop on the packets as they go by -- not only do you
have to have the power to substitute your packets for the real ones,
but the tap has to actively interpret the packets and generate the
spoof packets (compute-intensive, for DH and for de- and re-encrypting
packets), rather than just recording them. My guess is it's a useful
increment of security given the application, but not to be fully
trusted. But since the system (obviously) has no way to truly
authenticate the people on each end, it's no weaker than it appears to
be.
Dale
Dale Worley [EMAIL PROTECTED]
--
Your mind is your principal weapon.
------------------------------
From: [EMAIL PROTECTED] (Dale R Worley)
Subject: Re: A further descent in Nullism
Date: Tue, 19 Jan 1999 01:02:42 GMT
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED]
(wtshaw) writes:
As this project goes downhill, at least numerically speaking, enter base
18, also convenient for this sort of thing. The same rules generally
apply, but with 18 characters of 26 used, leaving 8 for optional null
use. Two digit handy transposition sizes are implemented, 10 and 20
digits. Oh, the name....Balsas10/20.
It seems like you might get even better security by going to base 2,
using one digit for the plaintext and the other as a null.
Dale
Dale Worley [EMAIL PROTECTED]
--
Take nothing by force that you don't want.
------------------------------
** 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
******************************
