Cryptography-Digest Digest #179, Volume #10 Sun, 5 Sep 99 09:13:02 EDT
Contents:
Re: Are there any RSA encryption / decryption source in JAVA ? (David A Molnar)
Re: point of a cipher ("Richard Parker")
Re: point of a cipher (Enterrottacher Andreas)
Re: Schneier/Publsied Algorithms (Ralf Stephan)
Re: Second "_NSAKey" (Serge Paccalin)
Re: Alleged NSA backdoor in Windows CryptoAPI (Lincoln Yeoh)
Re: Pincodes (Daniel James)
Re: Graphical Passwords (Mok-Kong Shen)
Re: point of a cipher (Tom St Denis)
Re: arguement against randomness (Tom St Denis)
Re: DES cfb stream cypher and "whitening" or initialization (Tom St Denis)
Re: point of a cipher (Tom St Denis)
Re: arguement against randomness ([EMAIL PROTECTED])
Re: Schneier/Publsied Algorithms (Ralf Stephan)
RE: point of a cipher (Gary)
Re: DES cfb stream cypher and "whitening" or initialization (SCOTT19U.ZIP_GUY)
Re: Description of SQ (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Are there any RSA encryption / decryption source in JAVA ?
Date: 5 Sep 1999 06:00:41 GMT
Dennis To <[EMAIL PROTECTED]> wrote:
> Any one know where I can find source for RSA encryption and decryption
> in JAVA so that I can use it in my school project ?
You could look at Cryptix. Key generation isn't ported to Java yet,
unfortunately.
http://www.cryptix.org/
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 06:25:24 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> So can you clear up how either 'magical compression' or 'w-pcbc'
> actually protect M from the attacker?
It is not uncommon to perform compression on a message before
encryption. I believe that the goal of David Scott's modifications to
Huffman compression is to produce an algorithm for which any input
sequence is not only an acceptable input for decompression, but also
the same sequence that would be output by compressing the
decompression. This property presumably increases the work factor of
a brute force ciphertext-only attack because the attacker can't
validate a trial decryption by simply testing to see if the trial
decryption is a valid input sequence for the decompression algorithm.
David Scott is using "w-pcbc" as an all-or-nothing transform (AONT).
It is my understanding that his primary motive for incorporating an
AONT into his cipher is also as a method of increasing the work factor
of a brute force attack, since an AONT requires the attacker to decode
the entire ciphertext for each trial decryption.
> Another argument against w-pcbc is what if there is a burst error
> (say in a MPEG stream) do I want to lose the entire contents?
Naturally an all-or-nothing transform produces an output that is
vulnerable to errors. David Scott argues that reliable transmission
should be considered independent of encryption, and I agree with him.
However, I consider compression and all-or-nothing transforms as
independent preprocessing steps from encryption. It is simpler and
cleaner to enhance resistance to brute force search by just increasing
the keyspace.
Rather than incorporating compression, an AONT, and an encryption
algorithm to form a super-cipher as David Scott has done, I prefer to
consider these as separate modules, each chosen with different
criteria that depend on the overall application. For example, in a
particular application one might choose a compression algorithm that
is adapted to a particular data set, choose to use an AONT because the
application is vulnerable to related-message attacks, select an
encryption algorithm based on speed and security, and then use a
error-correction method that can handle the expected error-rates of
the transmission channel.
-Richard
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 09:48:49 +0200
Tom St Denis schrieb:
>
> (this is addressed towards Dave Scott, but feel free to comment),
>
> The point of a cipher is to hide the contents of a message M with an
> encryption method E, and the key K. The goal is without knowledge of K,
> nothing of M can be derived from E_K(M) .
>
> Now tell me where 'magical' compression methods come in. Either you know the
> key, and get the message, or you don't know the key and you only get random
> crap. I agree that compression helps remove redundancies, but it doesn't
> hinder brute-force or any other attack outisde of just trying to decompress
> what you guessed M could be.
Compression reduces the amount of plaintext/ciphertext. That's a good
idear to
prevent other attacks.
Like whithening it is a cheap method to add some strength: Compression
is
already a good idear to reduce network traffic or disc space.
> ...
> So can you clear up how either 'magical compression' or 'w-pcbc' actually
> protect M from the attacker?
I agree that w-pcbc isn't worth the effort.
It slows down brute-force-attacks but bits are cheap so why not use a
cipher
with a little bit larger keys to get the same result without having to
use
multiple encryption.
On the other hand we don't know in what way other attacks are affected:
Maybe w-pcbc with only one key openes a backdoor ...
> Another argument against w-pcbc is what if there is a burst error (say in a
> MPEG stream) do I want to lose the entire contents? (this plus it's slower,
> no more secure and awkwards should strongly suggest not to use it).
You can't use w-pcbc in a data stream or you would have to get the whole
data
before beginning to decrypt. Nobody would want to do this with a MPEG
stream.
> So tell me where you gain info from a CBC stream without knowledge of M or K?
What if I know M or parts of M or the structure of M?
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ralf Stephan)
Subject: Re: Schneier/Publsied Algorithms
Date: Sun, 5 Sep 1999 09:40:01 +0200
Eric Lee Green:
>On the other hand, public key encryption (like in the "microsoft thing")
>is a fairly new field (and there has been an insinuation that actually
>it's an older field, that the NSA had it for years before Shapir et. al.
>let the genie out of the bottle),
We know that at least the Brits had it years before.
>But then again, for my particular application I don't care much if the
>NSA can crack it, as long as random criminals can't crack it.
This only applies if you're living in the U.S.
And even then I'm wondering what happened to the spirit
of the founding fathers...
What hypocrisy --- spasmodically holding to your rifles
and, at the same time, delivering yourself on a golden plate!
I'll never understand that,
ralf
--
http://www.in-berlin.de/User/rws/
"_NSAKEY signifies that it satisfies security standards." (Microsoft)
------------------------------
From: [EMAIL PROTECTED] (Serge Paccalin)
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Sun, 5 Sep 1999 11:21:32 +0200
Reply-To: [EMAIL PROTECTED]
On/le Sat, 4 Sep 1999 23:22:04 -0500,
Rick Braddam <[EMAIL PROTECTED]> wrote/a �crit...
> Doesn't anyone else think it strange that _Key cannot
> be replaced without disabling CAPI but _NSAKey can?
No, because it's not CAPI that is disabled, but all modules signed
with _KEY. And currently, all of them are, because it's Microsoft's
key, while _NSAKEY is just dormant, for now...
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San Antonio
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI
Date: Sun, 05 Sep 1999 08:35:55 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 03 Sep 1999 23:00:43 GMT, Chris Adams <[EMAIL PROTECTED]> wrote:
>I still think the people who suggest it's to allow the NSA to use their
>own private CSPs but it wouldn't surprise me to learn the answer was
>less innocent.
If I were the NSA that key wouldn't be mine. There could be a second key,
but I'd overwrite it with mine.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Pincodes
Date: Sun, 05 Sep 1999 10:32:23 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Walter
Hofmann wrote:
> Even better: Don't store the PIN anywhere, not even encrypted. Make
> the PIN a function of the card data:
>
> PIN = Crypt(Key, Hash(Account-No, Expiry-Date, ...)) (mod 10**n)
>
> This would also prevent the user from changing the expiry date on
> the magnetic stripe.
>
It would also prevent the user from changing their PIN and would
require that a new PIN be issued whenever a new card was issued.
Many banks do actually do something like what you propose to compute an
initial PIN for a card (excluding the expiry date) and store an offset
value in their databases when a user changes a PIN. PVVs (PIN
Verification Values) that are stored on-card are computed from the
actual current PIN (and card/account number, so a PVV can't be copied
from one card to another) as they are intended for use when the central
database in not accessible.
Nowadays any two banks friendly enough to share each other's PIN
Verification keys are probably friendly enough to maintain a full time
data connection between their computer centres so PVVs on cards are
becoming rarer.
Cheers,
Dnaiel.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Graphical Passwords
Date: Sun, 05 Sep 1999 12:28:40 +0200
AlainNYC wrote:
>
> we are a group of researchers from Bell Labs, AT&T Labs and
> NYU. We implemented "graphical passwords" for the PalmPilot.
> That is, you can simply draw a little figure as your password
> rather than trying to remember some funky textual password.
> his password is then use to encrypt data in the memopad
> application.
I haven't yet tried out your system but perhaps I am allowed to ask
a few questions nonetheless:
1. How do you eliminate the risk of someone observing the user do
the drawing?
2. What is the error rate of the system?
3. Quite a time ago someone wrote that he found an IBM patent that
is general enough to cover a password system that is based on
user selection from among a number of human faces presented.
Your system is quite different from that. But it might be
nevertheless advisable to do a check with that patent for
possible legal conflicts.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 11:50:01 GMT
In article <o1oA3.21146$[EMAIL PROTECTED]>,
"Richard Parker" <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > So can you clear up how either 'magical compression' or 'w-pcbc'
> > actually protect M from the attacker?
>
> It is not uncommon to perform compression on a message before
> encryption. I believe that the goal of David Scott's modifications to
> Huffman compression is to produce an algorithm for which any input
> sequence is not only an acceptable input for decompression, but also
> the same sequence that would be output by compressing the
> decompression. This property presumably increases the work factor of
> a brute force ciphertext-only attack because the attacker can't
> validate a trial decryption by simply testing to see if the trial
> decryption is a valid input sequence for the decompression algorithm.
The thing is you can still brute force his method. I can try a key, then
decompress and test for ASCII.... not that hard. My point is that his
compression SHOULD NOT be a factor in considering the security of the system,
only as a bandwidth optimization.
> David Scott is using "w-pcbc" as an all-or-nothing transform (AONT).
> It is my understanding that his primary motive for incorporating an
> AONT into his cipher is also as a method of increasing the work factor
> of a brute force attack, since an AONT requires the attacker to decode
> the entire ciphertext for each trial decryption.
But his w-pcbc is so inefficient it's hardly worth considering. Yeah I can
slow down brute force by using 8191 rounds of blowfish, but I could also just
plug in 256 bit keys......His method is also very bad for many applications.
What if for example you are encrypting a build, or a mail archive, or
something big, say 1GB, do you want to encode 25GB worth of data with his
method, or 1GB worth of data with any other serious method?
> > Another argument against w-pcbc is what if there is a burst error
> > (say in a MPEG stream) do I want to lose the entire contents?
>
> Naturally an all-or-nothing transform produces an output that is
> vulnerable to errors. David Scott argues that reliable transmission
> should be considered independent of encryption, and I agree with him.
To some extent you are right. Integrity however is provided thru MACs and
Signatures, not PPP CRCs ....
> However, I consider compression and all-or-nothing transforms as
> independent preprocessing steps from encryption. It is simpler and
> cleaner to enhance resistance to brute force search by just increasing
> the keyspace.
YES YES YES, I agree with this :)
> Rather than incorporating compression, an AONT, and an encryption
> algorithm to form a super-cipher as David Scott has done, I prefer to
> consider these as separate modules, each chosen with different
> criteria that depend on the overall application. For example, in a
> particular application one might choose a compression algorithm that
> is adapted to a particular data set, choose to use an AONT because the
> application is vulnerable to related-message attacks, select an
> encryption algorithm based on speed and security, and then use a
> error-correction method that can handle the expected error-rates of
> the transmission channel.
I don't think his ideas are bad, I just don't think they merit serious
consideration. Like my toy cipher xxtea is probably weak, I could bump it to
128 rounds and make it 'secure', but is that worth it?
Basically I think his ideas lack focus on the big picture. Encryption =
randomize data, compression = make it smaller. I would rather have the
encryption strong, and the compression tight, then the opposite...
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: arguement against randomness
Date: Sun, 05 Sep 1999 11:52:11 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Isn't one of the laws of thermaldynamics stating the spontaneuous
> > creation of energy is impossible (or something to that effect)?
> > Also wouldn't something truly random fall into this category?
> > If I am dead wrong, please let me know.
>
> You're close to dead wrong. Even if thermodynamic entropy were
> the same as informational entropy (which it is *not*), all that
> one could conclude is that one would have to expend some energy
> in order to increase the amount of *order*. (Disorder tends to
> increase on its own.)
>
I should take some physic classes before I open my flap right?
I am just thinking that something truly random must be created spontaneously,
otherwise it's not truly random.... :(
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 11:40:50 GMT
In article <7qstef$[EMAIL PROTECTED]>,
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> In article <7qsl65$5fs$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> >In article <7qrflp$446$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Cary O'Brien) wrote:
> >> I (like probably 10% of the readers) need to encrypt a data stream with a
> >> stream cypher. I want to use des in cfb mode (specifically des_cfb64_encrypt
> >> from libdes). The system will use shared secrets for keys. The problem
> >> is that the packet structure of the underlying data stream would be know
> >> to an attacker (ok, ok, it is ppp). I'm worried that this will provide
> >> the attacker with a known-cleartext attack. Not good.
> >>
> >> I propose to insert 4 bytes of "random" data to the beginning of the
> >> cleartext data stream on the encryption side, and drop the first 4 bytes
> >> on the decryption side.
> >>
> >> 1) Is this worth the effort?
> >> 2) Am I being otherwise stupid?
> >>
> >> Thanks,
> >
> >Here's a question.... why are you using des? Is this to be compatible with
> >another app? In this case your question is moot.
> >
> >Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or just
> >make up some Algorithm M clone). RC4 is about 20 times faster, more compact
> >and easier to get RIGHT. It's also not yet vulnerable to any known attack.
> >
> Actually, it is. If the attacker knows the plaintext of a message, he can
> modify the ciphertext so that, when the receiver decrypts that modified
> ciphertext, he gets a message of the attacker's choosing (of the same
> length as the original message). In other words, the attacker can change:
>
> "Pay to Alice: $1064.76"
>
> to
>
> "Pay to Mallet: $999999"
>
> CFB is slightly stronger, in that if the attacker attempts to modify a
> block, the next block will decrypt to garbage.
This will work only if you are not smart enough to sign the message.
If you RC4 encrypt a hash there is no way to guess what the hash could have
been unless you recovered the entire message.
In that case why not use CBC or something?
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: point of a cipher
Date: Sun, 05 Sep 1999 11:43:55 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > The point of a cipher is to hide the contents of a message M with an
> > encryption method E, and the key K. The goal is without knowledge
> > of K, nothing of M can be derived from E_K(M).
>
> First of all, that is an overly restrictive view.
> More accurate would be the goal of requiring an eavesdropper
> to perform more work than is economically feasible in order
> to have a significant chance of recovering the plaintext.
You are right, but realistically I am right. If I give you a packet dump of
say CBC Blowfish (and a 160-bit key) you will probably never read the message
without guessing the key first.
> As I've advised before, one should develop some practical experience
> in cryptanalysis before trying to discuss its feasibility in any
> particular case. In fact, I've cracked messages in some systems
> without ever recovering the key. Precompression *does* hinder
> cryptanalysis, because it obscures underlying statistical properties
> of the source language that could otherwise be exploited. I don't
> know why you even mention exhaustive keyspace search ("brute-force
> attack"), because no competent cryptosystem designer is going to
> choose a key so small as to make that attack feasible.
The thing is if you can guess the input plaintext you can always compress
that and compare against the ciphertext... a bit more complex but not
impossible.
I think compression should only be considered as a means for making the
message smaller, not more secure. As if you would encrypt a message to get
higher bit rates.... :)
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sun, 05 Sep 1999 12:18:22 +0100
From: [EMAIL PROTECTED]
Subject: Re: arguement against randomness
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
with regards to randomness, this kind of falls into the realms of philosophy.
<br>Is anything truly random but really varying degrees of predictability.
<p>sha99y</html>
------------------------------
From: [EMAIL PROTECTED] (Ralf Stephan)
Subject: Re: Schneier/Publsied Algorithms
Date: Sun, 5 Sep 1999 14:45:01 +0200
>We know that at least the Brits had it years before.
http://www.research.att.com/~smb/nsam-160/
(Prehistory of Public Key Cryptography)
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: RE: point of a cipher
Date: Sun, 5 Sep 1999 08:58:28 -0400
>===== Original Message From Tom St Denis <[EMAIL PROTECTED]> =====
>
>The point of a cipher is to hide the contents of a message M with an
>encryption method E, and the key K. The goal is without knowledge of K,
>nothing of M can be derived from E_K(M) .
Given both M and E_K(M) you shouldn't be able to find K.
============================================================
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com and http://MailAndNews.co.uk
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
============================================================
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DES cfb stream cypher and "whitening" or initialization
Date: Sun, 05 Sep 1999 14:04:23 GMT
In article <7qstef$[EMAIL PROTECTED]>, Scott Fluhrer
<[EMAIL PROTECTED]> wrote:
>In article <7qsl65$5fs$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>>In article <7qrflp$446$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Cary O'Brien) wrote:
>>> I (like probably 10% of the readers) need to encrypt a data stream with a
>>> stream cypher. I want to use des in cfb mode (specifically
> des_cfb64_encrypt
>>> from libdes). The system will use shared secrets for keys. The problem
>>> is that the packet structure of the underlying data stream would be know
>>> to an attacker (ok, ok, it is ppp). I'm worried that this will provide
>>> the attacker with a known-cleartext attack. Not good.
>>>
>>> I propose to insert 4 bytes of "random" data to the beginning of the
>>> cleartext data stream on the encryption side, and drop the first 4 bytes
>>> on the decryption side.
>>>
>>> 1) Is this worth the effort?
>>> 2) Am I being otherwise stupid?
>>>
>>> Thanks,
>>
>>Here's a question.... why are you using des? Is this to be compatible with
>>another app? In this case your question is moot.
>>
>>Otherwise... DROP DES. Use RC4 if you need a good stream cipher (or just
>>make up some Algorithm M clone). RC4 is about 20 times faster, more compact
>>and easier to get RIGHT. It's also not yet vulnerable to any known attack.
>>
>Actually, it is. If the attacker knows the plaintext of a message, he can
>modify the ciphertext so that, when the receiver decrypts that modified
>ciphertext, he gets a message of the attacker's choosing (of the same
>length as the original message). In other words, the attacker can change:
>
> "Pay to Alice: $1064.76"
>
>to
>
> "Pay to Mallet: $999999"
>
>CFB is slightly stronger, in that if the attacker attempts to modify a
>block, the next block will decrypt to garbage.
>
What you said is ture sort of. Well at least for CFB but with the
wonderful error recovery feature of the NSA approved 3- letter chaining
the next block after the garbage block will be OK. And who knows what
the average user will do with a message that looks almost correct he
may not even notice.
You could use if you have the time and don't want error recovery use
RC4-257 or RC4-17 You use the current "plain text character" in a secondary
RC4 to generate a 8 bit caharacater that either directly pick the next
main RC4 fuction that is used or divide by 16 and use remander to pick
1 of 16 RC4. This gets rid of error recovery that helps the NSA break the
code and the problem metioned in single RC4 where a message can
be modifed by the technique above. The nice thing about this approach
is it takes only about twice the speed of RC4 but greatly increase its
security.
Example use tommys method and use padding in front of file
to encrypt old way each character
Cn = RC4(K,Pn)
modifed way if using RC4-17
T = RC4( K16,Pn-1); p-1 is an IV character know to both parites
K = S[ T % 16]; a 16 entry look up table that returns a pointer to the next
RC4 funtion to be used
Cn=RC4( *K,Pn) I wrote it as *K for reasons of pointer to show that the key
used is really just the key from the 0 to 15 choices.
This is actaully a hair slower that 2 times RC4 but it gains you a lot in
securtiy.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Description of SQ
Date: Sun, 05 Sep 1999 14:09:31 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Kostadin Bajalcaliev wrote:
>> ... Shannon theories are just theories nothing else, ...
>
>That shows a profound misunderstanding of the usage of the word
>"theory" in such contexts. Information theory, probability theory,
>group theory, etc. are organized bodies of knowledge, not "just
>theories" in the sense of "falsifiable hypotheses".
Here is a comparsion that might make both of you happy in your
own minds being the diplmat that I am. Theory is like what the
word means to YOU when one talks about the "THEORY OF
EVOULTION". There that example was meant to clarify.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
