Cryptography-Digest Digest #854, Volume #10 Thu, 6 Jan 00 12:13:01 EST
Contents:
Re: Unsafe Advice in Cryptonomicon (Mok-Kong Shen)
Re: Identifier anonymization (John Bailey)
Re: Please Comment: Modified Enigma (Mok-Kong Shen)
Re: Square? (Mok-Kong Shen)
Re: Square? (Mok-Kong Shen)
Re: Please Comment: Modified Enigma (Mok-Kong Shen)
Re: Please Comment: Modified Enigma (Mok-Kong Shen)
Can CRC16 become 0? (Arjan)
Re: simple block ciphers (Tom St Denis)
Re: crypto papers (Tom St Denis)
Re: Please Comment: Modified Enigma (Mok-Kong Shen)
Re: Wagner et Al. (Tom St Denis)
Re: Miller Rabin alg--which is the right one? (Bob Silverman)
Re: Can CRC16 become 0? (Doug Stell)
Re: Truly random bistream (Mike Rosing)
Re: CryptoAPI international keylengths (Pascal Scheffers)
CryptoAPI international keylengths (Pascal Scheffers)
Re: simple block ciphers (Anton Stiglic)
Re: Unsafe Advice in Cryptonomicon (Steve K)
Re: RSA encrypt (Frank the root)
Re: Truly random bistream (Tim Tyler)
Re: How about this for a "randomly" generated bitstream? (Tim Tyler)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Unsafe Advice in Cryptonomicon
Date: Thu, 06 Jan 2000 14:20:58 +0100
John Savard wrote:
>
> <[EMAIL PROTECTED]> wrote:
>
> >This would mean sort of renascence
> >of the classical devices. Or am I speculating on an entirely wrong
> >track?
>
> There are two problems.
>
> Mechanical devices make noise, and that can be interpreted and
> analyzed.
I fairly doubt the 'quality' (usability) of such materials as
compared to electromagnetic emissions. Acoustic signals could, I
suppose, be more easily overloaded through a noise generator
(e.g. playing disco music) and thus become difficult to detect.
Anyway, there can be devices that are practically silent and such
that the noise gives no useful information at all, i.e. the
noise has no specific relation to the characters being encrypted.
>
> It is difficult to devise a mechanical device that would produce a
> sufficiently strong cipher to be secure today.
I meant to introduce one mechanical component into the system,
the rest of the system could all consist of the modern ones. That
component hence need not be particularly strong by itself.
> Putting a digital computer inside a sealed box with walls of, say, 1/2
> inch thick (12mm) solid aluminum is just so much easier. How to
> communicate plaintext to it without that plaintext existing outside
> the sealed box in any electrical form is, however, a problem.
I suppose it is most advantageous to have a mechanical encryption
component as the first component in enciphering (and the last
component in deciphering). For example, keying in through a mechanical
rotor device with the output of that further processed by components
that do have electromagnetic emissions.
M. K. Shen
=================================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Identifier anonymization
Date: Thu, 06 Jan 2000 13:15:57 GMT
On Wed, 05 Jan 2000 16:22:12 -0500, Al Wang <[EMAIL PROTECTED]> wrote:
>
>Hi all,
>
>I'm looking for a process by which to take a set of 9-digit identifiers
>for a data set, and to anonymize them, so as to generate a new set of
>unique strings.
What you want is very close to how the crypt() function works in Unix
to produce the password file. The subtlety is in using the salt.
The salt spoils the simple 1:1 relation between the input identifier
and the anonymized version, but the way its solved is by using a
second identifier (your system name) to find the original salt,
embedded in the password. If variations on that process can be used,
you have a well established model.
Rather than spend a lot of time explaining this all, I will leave it
at that. If you want more explaination just ask.
John
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 14:27:11 +0100
[EMAIL PROTECTED] wrote:
>
> I wonder if someone can comment on the strength of the following simple
> cipher: Extend the enigma algorithm by variable rotor permutations. Each
> rotor permutation would be part of the key.
>
> A simple physical implementation (assuming you are a spy in a hostile
> land who must not import any suspicious electronic or mechanical
> devices) would be a circle of paper for each rotor.
Such devices were used in the old times. In the more recent period,
a device of that kind that was used and that I happened to have
played with was one using a (user choosable) set of circular metallic
plates with the pairs of corresponding alphabets on them. One
encrypts/decrypts by employing the choosen plates periodically in
sequential order. The plates are rotated and through a window one
can see the relevant pair of characters. A key determines which
set of plates out of a large number are to be used. Specifically,
the device I have seen (during WWII) was for transcribing the
Chinese telegraphic code (each Chinese ideograph has a public code
consisting of 4 decimal digits). The 'inventor' obtained a patent
and the device was sold for public use. Shortly afterwards, however,
the Chinese government banned its use, for pretty the same reason as
underlying nowadays key-escrows, Wassenaar Agreement etc., (which can
thus be said to have a fairly long historical justification).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Thu, 06 Jan 2000 14:26:19 +0100
Tom St Denis wrote:
>
> > It appears certain that any block cipher with sufficiently reduced
> > number of rounds can be cracked. Hence the question: Why are block
> > ciphers with (designed) variable, instead of constant, number of
> > rounds not very common? With that parametrization an algorithm
> > could adapt to the future advances of analysis techniques at least
> > to some reasonable extent and hence survive.
> You can always add more rounds to most ciphers. It simply requires
> more round keys and more rounds of course. You could [as demonstrated
> in the RC5 paper] encode the keysize/rounds in the ciphertext packet.
I meant most algorithms like DES have a 'fixed' number of rounds
and the normal users have no (practical) 'possibility' of using
more rounds. It would have been much better, if the number of rounds
is 'designed' to be user-choosable (to some extent).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Square?
Date: Thu, 06 Jan 2000 14:26:29 +0100
Tom St Denis wrote:
>
> > But frankly, I wouldn't suggest using a cipher as new as either Square
> > or Rijndael for production purposes unless it were absolutely
> necessary.
> > What's wrong with Triple-DES or Blowfish?
>
> With that line of thinking I was wondering why you didn't suggest RC4?
> It's simple, compact and fast....
That line of thinking is certainly not wrong. At least before
AES was started, one read very very often in the literature how very
extremely valuable it is to use an algorithm that has withstood
decades of attempted analysis efforts by a large number of
the best cryptologists. That that seemingly 'unaminous' opinion
appears to have subjected to some modifications recently is something
I haven't yet been able to fully comprehend. (Some who voiced that
opinion are apparently themselves very actively engaged in works to
replace the time-honoured best algorithms.)
To your question proper, my answer would be: One doesn't dispute
over tastes and colours (free translation of a Russian (?) proverb).
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 14:27:19 +0100
Albert Yang wrote:
>
> Enigma is a joke to crack for my desktop.
I am afraid that you exaggerated a bit. Turing would have covered
his face with his hands.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 14:27:29 +0100
John Savard wrote:
>
> Making a rotor machine with the rotor wirings a part of the key is a
> good idea.
>
> But using an Enigma, with the fatal weakness of not enciphering a
> letter to itself, is a bad idea.
A systematic effort to make good use of the lessions (both positive
and negative) learned from the diverse rotor systems seems still be
very rewarding even today. Are there researchers actively doing that
kind of work?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Arjan)
Subject: Can CRC16 become 0?
Date: Thu, 06 Jan 2000 13:26:19 GMT
Hello,
Probably a simple question for the guru's here:
If the CRC16 of a NON-ZERO block of data is calculated, is it possible
the result is 0?
I need to know this to test if a piece of memory (including the CRC16
itself) is empty or not. I do a CRC16 check on the data for validity
checking, but the CRC16 of a block of 0's is always 0. If this is the
only case where the CRC16 becomes zero, I could use it to check if the
memory device is empty.
Thanks in advance,
Arjan
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: simple block ciphers
Date: Thu, 06 Jan 2000 13:23:47 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> Hi Tom,
>
> Given enough ciphertext, you can pretty much guess what p is
> (since all the ciphertexts will be between the values 1 and p-1).
> If you use it as a block cipher, you'll get quiet a few ciphertexts.
> So for reasonable use, you can consider p to be known.
A large num of C though... since we get
a = 2^72/ln 2^72 = ~2^66.35
b = 2^64/ln 2^64 = ~2^58.52
c = a - b = ~2^66.34
So in the case where 8 byte blocks are encrypted with a 72-bit prime
modulus there are c possible prime moduli. Obviously just checking
them all is not a happening thing.
> Now, a problem beleived to be hard is given a prime p, a generator
> g and an element y, find x such that g^x = y mod p (this is the DH
> problem). The basis (the generator g) is fixed! In your case, the
> base is not fixed, this changes the problem (the problem is not
> equivalent to the DH problem) I can't think of any usefull type of
> attack right now do.
>
> Now, some notes on the algo. Firstly, why do you choose e to be
> prime?
> Secondly, if you want d to exist, you must have gcd(e, p-1) = 1
> (unless you work in some sub group of order q, and in that case
> q has to be big enough for security reasons).
> Thirdly, if in fact you realy want e to be prime, then you realy
restrict
>
> the possible amount of e's, since you have to have gcd(e,p-1) =1
> and e is prime, e would have to be a factor of p-1. (If you know the
> factorization of p-1, it's probably an easy search...).
Thanks for pointing that out. I actually realized why it didn't work
[at first I was using random e values]. When I posted it, that was
just off the top of my head. I am teaching myself number theory [with
the help of Michael Froberger]. In the current source code I am
playing with I do the GCD instead of a prime.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: crypto papers
Date: Thu, 06 Jan 2000 13:25:08 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Steve K) wrote:
> On Thu, 06 Jan 2000 03:13:20 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >Goto
> >
> >http://www.dasoft.org/tom/
> >
> >For papers related to crypto...
> >
> >Tom
> >--
> >[EMAIL PROTECTED]
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> Just downloaded the PB2 source again. It is just me (starting to
> learn something), or did "peekboo.c" suddenly get squeaky clean and
> really well commented?
Along the way I have been cleaning the source, but I think you are just
understanding more of it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Please Comment: Modified Enigma
Date: Thu, 06 Jan 2000 14:38:05 +0100
[EMAIL PROTECTED] wrote:
>
> My scheme would still be complex and timeconsuming ( I do not propose it for
> the battlefield), mainly at the rotor construction time (you must be quite
> precise..), but it would be usable. Instead of playing with 256 pieces of
> paper (RC4) , you just have to rotate the circles..
You could do pre-computations of the permutaions, which means
effectively choosing among some pre-fabricated rotors using a key,
or do computations 'on-the-fly' with the key to construct the
specific rotors for the specific message at encryption time. There
isn't much 'essential' difference in my humble view.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Date: Thu, 06 Jan 2000 13:29:23 GMT
In article <851b4d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> In article <851144$o$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom St
Denis) wrote:
>
> >You just don't get it
>
> You mispelled "I just don't get it".
Aparently so.
> >If you can't protect against trojans
>
> You most certainly can protect against trojans. I administer NT
servers
> and am well protected against trojans. First you need a secure
room...
>
> >Why bother bloating the code to try and protect against them.
>
> Because PGP protects itself from all trojans that are not specifically
> designed to defeat PGP, and PGP and windows NT security work together
to
> protect PGP from all trojans including trojans specifically designed
to
> defeat PGP if the trojan fails to get administrator rights. This is
> most certainly worth doing.
>
> >I clear the stack and encrypt the keyfile. That's about all I can
do.
> >That's all I do.
>
> Why bother? By your logic clearing the stack and encrypting the
keyfile
> are a waste of time.
First, I encrypt the keyfile so that others who have access to the
keyfile can't easily read them. It lets you put the file on a floppy
disk as well.
Second, if the values are in memory, they can be hacked out. No matter
what. I could for example replace the windows system files when you
are not looking...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Miller Rabin alg--which is the right one?
Date: Thu, 06 Jan 2000 15:04:13 GMT
In article <sq1d4.853$15.4442@news>,
"Miryadi" <[EMAIL PROTECTED]> wrote:
> Hello, all
>
> Cormen's "Introduction To Algorithm" page 843 mention that:
> for any odd integer n>2 and positif integer s, the probability that
> Miller_Rabin (n,s) error is at most 2^-s, but
>
> Menezes' "Handbook of Cryptography" page 140 mention that:
> for any composite integer n, the probability that Miller_Rabin(n,t)
> declares n to be prime is less than (1/4)^t.
>
> Which is the right one?
NEITHER. But Meneze's is closer to the truth. M-R(n,t) < 1/4^t is
true only for large enough n. But this bound is very WEAK. The truth
is that the probability is MUCH smaller.
See:
Kim & Pomerance
"The Probability that a random probable prime is composite"
Math. Comp. 53 (1989)
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Can CRC16 become 0?
Date: Thu, 06 Jan 2000 14:53:17 GMT
On Thu, 06 Jan 2000 13:26:19 GMT, [EMAIL PROTECTED]
(Arjan) wrote:
>If the CRC16 of a NON-ZERO block of data is calculated, is it possible
>the result is 0?
Yes. If the data block is evenly divisible by the polynomial, the CRC,
remainder, will be 0.
>I need to know this to test if a piece of memory (including the CRC16
>itself) is empty or not. I do a CRC16 check on the data for validity
>checking, but the CRC16 of a block of 0's is always 0. If this is the
>only case where the CRC16 becomes zero, I could use it to check if the
>memory device is empty.
Initializing the CRC to all 0's will render it incapable of detecting
leading zeros. Initializing it wil all 1's will render it incapable of
detecting leading ones.
Therefore, you might consider initializing it to some other fixed
value. Performing a CRC on a zero data block of fixed length will
result in some other fixed value. Of course, real data could also give
you this value, as stated above..
The best paper on the subject of CRCs can be found at the following
UTLs.
ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt
http://www.repairfaq.org/filipg/LINK/F_crc_v3.html
doug
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Date: Thu, 06 Jan 2000 09:46:47 -0600
CLSV wrote:
> I don't think the paper claims that the experiment
> achieves perfect randomness, and that is its power.
> It is an honest report of what can be done with only
> limited resources. And it is quite impressive but there
> is no need to stretch the definition of "proof" and
> "randomness" and claim that the experiment produces
> true random numbers.
We completely agree. What I meant by "proof" was that
you can get measureably random data, which given a definition
of "random" can be tested for. That's "proof" that radioactive
decay creates "random" bits.
But it's surely semantics. Some definitions of random
require infinite time to test for, and then it's impossible
to prove anything. From the perspective of engineering,
it's a reasonable proof: it can be built and tested and
it works for many applications. From a strictly mathematical
sense, the word "proof" may take on too many conoatations
and that's not what I meant.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Pascal Scheffers)
Subject: Re: CryptoAPI international keylengths
Date: Thu, 06 Jan 2000 15:45:34 GMT
> if(CryptGenKey(
> m_hProv,
> AT_KEYEXCHANGE,
> 0x04000000, //2048 bit keypair
> &hKey))
I know, I know, 0400 is 1024, not 2048. It also works with 0x08000000.
------------------------------
From: [EMAIL PROTECTED] (Pascal Scheffers)
Subject: CryptoAPI international keylengths
Date: Thu, 06 Jan 2000 15:42:59 GMT
We are developing an application that uses Microsofts CryptoAPI. The
documentation says that the international version only does RSA512 and
smaller for signing and key-exchange. I think I have the international
version installed...
When I enumerate available algorithms, it reports only RSA512 signing
and keyx.
However. When I generate a new key pair:
if(CryptGenKey(
m_hProv,
AT_KEYEXCHANGE,
0x04000000, //2048 bit keypair
&hKey))
{
printf("Created a signature key pair.\n");
CryptDestroyKey(hKey);
} else {
cout << "could not generate keypair...";
}
It creates a new keypair. With still larger keysizes, it reports an
error.
I can even call CryptSignHash(), which results in a signature of
2048bits.
Is this a bug? Is it a feature? I don't think I should be able to with
the international version. Is it possible that, when I ask for a 2048
bit key, I end up with 512bit random key extended by a 1536bit
non-random part?
Regards,
Pascal.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: simple block ciphers
Date: Thu, 06 Jan 2000 11:27:51 -0500
David A Molnar wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> > Thirdly, if in fact you realy want e to be prime, then you realy restrict
>
> > the possible amount of e's, since you have to have gcd(e,p-1) =1
> > and e is prime, e would have to be a factor of p-1. (If you know the
>
> if a prime e is a factor of p-1, then isn't gcd(e, p-1) = e ?
yes, you are right. If e has to be a prime, it must *not* be
a factor of p-1 so as to have gcd(e, p-1) = 1. This argument thus
doesn't give us much...
------------------------------
From: [EMAIL PROTECTED] (Steve K)
Subject: Re: Unsafe Advice in Cryptonomicon
Date: Thu, 06 Jan 2000 16:29:31 GMT
On Thu, 06 Jan 2000 06:27:57 GMT, [EMAIL PROTECTED] (Steve K) wrote:
And one more technical quibble from Cryptonomicon, about a computer
room with an electromagnet in the door frame, that wipes any media
being carried in or out: OK fine, if the field is strong enough to
wipe media at the distances involved (typically 1-1/2 feet or so) and
through the ferrous materials in the housings & etc. And OK fine, if
the people carrying the stuff out through this field do not notice
that every piece of ferrous metal that comes close to the frame gets
yanked out of their hands.
Oops. Heh heh. OK so the first thing they tried to carry out was the
one thing that really did need wiped.
Clank! "What the-- oh sh*t!"
Plot line saved. Ta daa.
Steve K
---Continuing freedom of speech brought to you by---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP key 0x5D016218
All others have been revoked.
------------------------------
From: Frank the root <[EMAIL PROTECTED]>
Subject: Re: RSA encrypt
Date: Thu, 06 Jan 2000 16:42:18 GMT
Paul Schlyter wrote :
> This also show why small exponents (3, 17 or 65537) are popular in the
> public RSA key: the RSA computation will be much faster for these small
> exponents.
But, because d ( the secret key ) is obtained from the formula "ed mod
Phi(n) = 1", doesn't it offer a possibility to evaluate a approximation
of d? knowning that as much a term is small the other have pretty good
chances to get bigger?
In addition, it is possible to evaluate a approximation of Phi(n)
whitout the primes factors of Phi(n)? Let me explain, if the numbers of
primes not exceding n is asymptotic to n/ln n ( where ln stands for log
in base e ) you can get in Phi(n) all primes number ( who are always
relatively primes to any others ) so get a part of the anwser. Or
better, you can determine ramdoms p and q ( just for experiment purpose
) approximatly the same size that you suppose real p and q are,
<SPECULATION MOD>
Since numbers that have
4382789526587125732758365834757458348657832765834768348732868234587384768237684756872487384678943
as factor are not very more frequent then numbers that have
9847528374582368647843768341028346572817583274815683475832758327468345893275893475893274589347595
as factor,
I would try : Phi(n) ~ (n/fake_p + n/fake_q - 1).
</SPECULATION MOD>
I not sure this would give a fair estimation but in conjonction with a
approximate size of d can this give me reasonnable statisticals chances
to discover d in less then a thousand years? Any idea on possibilities
to estimate Phi(n)?
And didn't knew mod was a commutative operator, tanks for all
explanations. Any suggestion for a mathematics books ( for beguinners
please) on primes numbers ?
Tanks a lot
Frank
--
Ceux qui r�vent la nuit savent des choses qu'ignorent ceux qui r�vent le
jour.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Truly random bistream
Reply-To: [EMAIL PROTECTED]
Date: Thu, 6 Jan 2000 16:46:43 GMT
Dave Knapp <[EMAIL PROTECTED]> wrote:
: (Jim) wrote:
:>Nothing is _absolutely_ random; no clock is _absolutely_ accurate;
:>nothing can go from one level to another _absolutely_ instantaneously;
:>etc; etc...
: And there's no such thing as _perfect_ conductivity...
: And there is no fluid with zero viscosity...
: Oops.
You may /think/ these are errors - due to phenomena such as
superconductivity - but I don't believe it's true.
There's no such thing as _perfect_ conductivity.
There is no fluid with zero viscosity - though I understand *negative*
viscosities are possible under simulation ;-)
Again, the problems include messinesses like cosmic rays, and
uncertainty and lack of precision in the equipment used to measure
and verify the properties being measured.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
'Scuse me while I whip this out.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How about this for a "randomly" generated bitstream?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 6 Jan 2000 16:50:19 GMT
John McDonald, Jr. <[EMAIL PROTECTED]> wrote:
: On Wed, 5 Jan 2000 03:52:54 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Nigel Fitchard <[EMAIL PROTECTED]> wrote:
:>: I would like to get hold of a truly random bitstream - about 2^24 bits long
:>: should be plenty. Does anyone know if such a thing exists for download ?
:>
:>No such thing is known to exist anywhere on the planet.
: While not "truly" random, wouldn't the following be random enough?
"Random enough" - for what?
The original poster did not specify any particular application - and
instead asked for a "truly random" bitstream.
Will your technique produce such a beast? Of course it will not.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Sometimes, the best things in life really suck.
------------------------------
** 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
******************************
