Cryptography-Digest Digest #14, Volume #13 Fri, 27 Oct 00 09:13:00 EDT
Contents:
Re: Symmetric cipher (Runu Knips)
Re: BEST BIJECTIVE RIJNDAEL YET? (John Savard)
Re: Is OPT the only encryption system that can be proved secure? (John Savard)
Questions about DES (Steven Wu)
Re: CHAP security hole question (Vernon Schryver)
Re: Q: Computations in a Galois Field (Volker Hetzer)
Re: Is OPT the only encryption system that can be proved secure?
([EMAIL PROTECTED])
Re: Image on glasses of the cover guy in Secrets & Lies (Daniel James)
Re: Questions about DES (Tom St Denis)
Re: Q: Computations in a Galois Field (Tom St Denis)
Re: Questions about DES (Simon Johnson)
Re: Rijndael and PGP (Tom St Denis)
ciphertext smaller than blocksize (Marc)
Perfect Compression Possible? (Simon Johnson)
Re: Algebra texts (Basic skills and equipment...) ([EMAIL PROTECTED])
Re: hardware vs. software vs. crypto accelerators (Paul Rubin)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
Date: Fri, 27 Oct 2000 10:17:04 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Symmetric cipher
"William A. McKee" wrote:
> Excuse my ignorance but what exactly is a "symmetric" cipher?
A classic cipher. Just what you think a cipher is: a key
and two algorithms, one for encryption, the other for
decryption.
The concept of interest is the asymmetric cipher, where you
have different keys for encryption and decryption. You
encrypt with the 'public' key, and decrypt with the 'private'
key.
The trick is that you can't compute the private key from the
public key - so you can publish the public key (as the name
says) and everyone can send you messages which only you
yourself are able to read.
>From a purely mathematical standpoint, there is no such
thing like an asymmetric ciphers, because finally it is
always possible to compute the private key from the public
key. The only question is how hard it is to do so.
The really good asymmetric cipher has still to be found,
most algorithms, such as RSA, are horribly slow.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Fri, 27 Oct 2000 08:08:04 GMT
On Fri, 27 Oct 2000 09:15:38 +0200, Runu Knips
<[EMAIL PROTECTED]> wrote, in part:
>Well okay, except that you can't prove automatically
>that you have the wrong key, like with non-bijective
>compressors, but that is only of interest for brute
>force attacks.
Actually, unless known plaintext is available, if there isn't some
property of the plaintext susceptible to automatic detection, the
cryptanalyst doesn't have redundancy to exploit.
Now, if a random file decompresses to random data, there probably _is_
a way to still do a brute-force attack, since even a bijective
compressor is not a _perfect_ compressor.
A nearly perfect compressor would be one that, when given a random
input, would produce, say, a file that looked so much like a text file
that only a human being could tell the difference with probability p,
a file that looked so much like an image file that only a human being
could tell it was just snow with probability q, a file that looked so
much like an executable...
and so the compressor would have detailed descriptions built in of all
the popular image file and word processor file formats, so that from
its own ultra-compressed rich text format, it could build a valid word
processor file using only a minimum number of bits to specify which
word processor (hence the need for frequent updates!)...
this being on top of containing dictionaries for 100 or so popular
languages...and presumably some kind of external choice of a
probability profile file, so that the fact that you or I might
consistently avoid sending text in Big5 or Basque could not be
exploited.
The level of compression really required to make brute-force searching
even moderately more difficult is daunting to even think about. No
wonder the conventional wisdom says to just use a bigger key.
That's why my viewpoint is - to take the middle road. To take
advantage of easy opportunities to improve compression, but to avoid
placing undue emphasis on this point, and to avoid making unwarranted
claims.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Fri, 27 Oct 2000 08:13:39 GMT
On Fri, 27 Oct 2000 04:50:05 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>That's my claim. It's also almost indisputable that this is one of
>the most confusing issues to anyone who is not a crypto expert.
>Claiming that we "have" something which is perfect, but which is not
>possible to realize in a guaranteed perfect way, is just stupid: In
>practice, we don't really "have" it at all. Too bad that bothers you.
Well, I've probed this in further detail. We may not "have" anything
perfect, but since the path towards making anything a science includes
engaging in _reductionism_ from time to time, it is indeed meaningful
to talk about the security of an encryption algorithm as distinct from
the security of its actual implementation.
Otherwise, we would be overwhelmed by trying to consider everything at
once, and we would be unable to design better algorithms.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Steven Wu <[EMAIL PROTECTED]>
Subject: Questions about DES
Date: Fri, 27 Oct 2000 08:42:06 GMT
Hi,
I have some questions about DES:
1) Why DES do 16 iterations, no 15 or 17 ?
2) Why people say, the choice of the primitive functions KS, S1,...S8
and P is critical to the strength of an encipherment resulting from the
algorithm?
3) Today, what are effective ways to attack DES ?
Thanks in advance.
-A Student
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 26 Oct 2000 23:28:39 -0600
In article <[EMAIL PROTECTED]>,
David P Jablon <[EMAIL PROTECTED]> wrote:
>Sure some flavors of CHAP are better than others ...
>just like RC4-40 is better than ROT13.
>
>The real story is that all purely hash-based or symmetric-encryption-
>based password authentication protocols have been obsolete for years.
>
>To resist offline brute-force attacks on network messages,
>regardless of the size of the password, look at the protocols in
>the class of EKE, SPEKE, SRP, SNAPI and AMP. These are documented
>in a number of papers linked at <www.IntegritySciences.com/links.html>.
As far as I can tell, the claims at http://www.IntegritySciences.com/ are
over the top. Maybe I'm wrong, but, for example, it strikes me as
impossible make small secrets unguessable. Small secrets by definition
need a small number of guesses to discover. It also seems to me that
http://www.IntegritySciences.com/password.html gets the notion of
challenge/response protocols such as CHAP wrong; the authenticatee in a
CHAP exchange does not learn the secret if it was not already known.
It's not that there are no problems with CHAP, what with the need for both
parties (instead of only one as in PAP) to keep a private cleartext copy
of the secret. (For years Microsoft falsely claimed that MS-CHAP does
not involve cleartext copies of a password.) There are also some
man-in-the-middle attacks, and other serious attacks involving the
common practice of using the same secret for both peers.
In other words, beware of technical information from sales people.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 27 Oct 2000 11:27:30 +0200
Terry Ritter wrote:
> http://www.io.com/~ritter/GLOSSARY.HTM#GaloisField
> http://www.io.com/~ritter/GLOSSARY.HTM#FiniteField
> http://www.io.com/~ritter/GLOSSARY.HTM#Field
> http://www.io.com/~ritter/GLOSSARY.HTM#Ring
> http://www.io.com/~ritter/GLOSSARY.HTM#Polynomial
> http://www.io.com/~ritter/GLOSSARY.HTM#Irreducible
> http://www.io.com/~ritter/GLOSSARY.HTM#PrimitivePolynomial
> http://www.io.com/~ritter/GLOSSARY.HTM#Mod2Polynomial
Great!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Fri, 27 Oct 2000 09:24:19 GMT
Tim
Thanks for your esoteric reply, but I dont think that Scott had this in
mind when he referd to PK and PGP.
Perhaps he will answer directly...I also have been meaning to ask him
about his cipher, whether its a conventional product/feistel network
cipher .....
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>
> :> Actaully the only reason a OTP used in the correct way is secure
> :> is becuase if one has cipher text there can be more than one
possible
> :> solution. Most real world ciphers are not secure in this sense
take
> :> PGP for example. It is not secure at all in this sense becasue of
the
> :> public key.
>
> : Sorry....what are you talking about?
>
> : Are you claiming that Public Key crypto is insecure?.
> : If so, please explain why.
>
> God (i.e. an entity with no work factor constraints) can look at some
data
> encrypted with a public key cryptosystem and extract the message
(assuming
> he has the public key).
>
> He can't do this to a message encrypted with an ideal OTP (assuming he
> doesn't have the OTP itself).
>
> With public key systems, the information required to break the message
is
> publicly available - it just takes a lot of work to recover the
message.
>
> With an ideal OTP, no volume of work on the cyphertext will help
recover
> the message.
>
> Security in an ideal OTP rests on information theoretic
considersations.
>
> Security in public key systems rests on unproven ideas about certain
> mathematical operations being hard to perform quickly.
>
> : WHat is scott19u? [...]
>
> http://members.nbci.com/ecil/lnink1.htm
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Image on glasses of the cover guy in Secrets & Lies
Date: Fri, 27 Oct 2000 11:49:18 +0100
Reply-To: [EMAIL PROTECTED]
In article <8ta9p9$s1c$[EMAIL PROTECTED]>, Jeff Moser wrote:
> I know it probably isn't worth too much to know, but what is the contents of
> the screen that the guy is looking at on the cover of Secrets and Lies by
> Schneier? It appears to be a Mac dialog with the options "OK", "CANCEL",
> and another.. the first word of the dialog is "You".. but I cannot
> distinguish much more.
Looking at it in a mirror, and employing a little thought and guesswork it
looks like:
You have requested an insecure
document?. The document and any
information you send? back could be
observed? by a third? party while in
transit.
For more information on security
choose page? prfs? through? the view menu.
('?' indicates a particularly fuzzy word)
Commonsense tells me that the first "document" should be something like
"connection", but it looks much more like "document" to me.
Shame, I was hoping it would be Bruce's password, or maybe his private key...
<smile>
Cheers,
Daniel
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Questions about DES
Date: Fri, 27 Oct 2000 11:27:03 GMT
In article <8tbf4u$5lk$[EMAIL PROTECTED]>,
Steven Wu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have some questions about DES:
>
> 1) Why DES do 16 iterations, no 15 or 17 ?
Read about the differential and linear cryptanaylsis of DES.
> 2) Why people say, the choice of the primitive functions KS, S1,...S8
> and P is critical to the strength of an encipherment resulting from
the
> algorithm?
Um because if you choose poor constructions biases could be found and
exploited.
> 3) Today, what are effective ways to attack DES ?
Yea, brute force the keyspace.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Fri, 27 Oct 2000 11:25:26 GMT
In article <8tb8u9$is$[EMAIL PROTECTED]>,
"kihdip" <[EMAIL PROTECTED]> wrote:
> > If anybody has problems with or suggestions for any of these or any
> > other topics, please let me know.
>
> I looked into your glossary and just wondered about one thing:
>
> Field:
> In abstract algebra, a commutative ring in which all non-zero
elements have
> a multiplicative inverse. (This means we can divide.)
> - If the order of a ring is a prime, would it always be a field ??
If every element of a ring is a unit then i believe it's also a field.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Questions about DES
Date: Fri, 27 Oct 2000 11:31:10 GMT
In article <8tbf4u$5lk$[EMAIL PROTECTED]>,
Steven Wu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have some questions about DES:
>
> 1) Why DES do 16 iterations, no 15 or 17 ?
This is a good question. Basically, DES is Feistel network type
construction. The reason it has an even number of rounds is to give the
Feistel network it 'natural' completeness. 15 rounds is significantly
less secure than 16, and 17 isn't much more secure than 16. The
ultimate choice of 16 rounds offers the best security to speed ratio
for this algorithm.
> 2) Why people say, the choice of the primitive functions KS, S1,...S8
> and P is critical to the strength of an encipherment resulting from >
> the algorithm?
S1-S8 are critical to the security of the algorithm. Basically, these
mappings give DES a large fraction of its resistance to differential
and linear cryptanalysis. Selecting substitutions randomly would result
in massive loss of security. I havn't seen much on the P-box, but
looking at it i would conclude its major function is to provide a
diffusive element to the cipher and speed up the avalanche effect.
> 3) Today, what are effective ways to attack DES ?
'The fasted attack at the time of writing requires 2^43 plain-texts and
over 50 days using 12 HP9000/735 workstations' - Applied Cryptography.
> Thanks in advance.
>
> -A Student
> [EMAIL PROTECTED]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Don't implement DES, since it aint the 'Data Encryption Standard'
anymore. It has been replaced by Rijndael, which is faster and more
secure.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
Date: Fri, 27 Oct 2000 11:30:33 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I disagree strongly. THere is no proof that Twofish is any stronger
> than Rijndael. And since it is the winner and carries the AES blessing
> we may see stinky two fish dead and buried. Since it will no longer
> have that fresh smell in the public eye. I aslo don't think security
> is a big concern for PGP convenince and speed to the user is its main
> virture. IF they wanted security better ciphers and better compression
> methods would have been in place long ago.
The funny thing is that PGP outperforms your ideas in compression and
encryption. It uses deflate which is a much better codec then "huffman
coding" and it uses well trusted symmetric ciphers (and not some random
awfully inefficient design).
How about giving your rants a rest?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: ciphertext smaller than blocksize
Date: 27 Oct 2000 11:58:38 GMT
>Do look up "ciphertext stealing". It's even in the section
>"Terminating Block Cipher Use" on my page
Ciphertext stealing is a nice method for keeping the ciphertext
size identical to plaintext size, when the plaintext is larger
or equal to the blocksize of the algorithm.
Does anyone know a similarily clever method for handling plaintexts
*smaller* than the blocksize? The only that comes to my mind is
to pad the plaintext with zeros, encrypt it, and crop it to the
plaintext size. Then the ciphertext can be built by XOR with
the plaintext.
This method will make the ciphertext unreadable, but not near as
secure as the real thing. The attacker can flip bits at will.
Are there any other ideas?
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Perfect Compression Possible?
Date: Fri, 27 Oct 2000 11:47:08 GMT
I was wondering if it was possible to generate a perfect compression
algorithm using the Berlekamp-Massey algorithm. If you took an normal
piece of plain-text, and let the algorithm chew away for a long while
eventually it would produce an LFSR that would exactly reproduce the
plain-text right?
Is there something preventing this, or am i correct in my observation?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Algebra texts (Basic skills and equipment...)
Date: Fri, 27 Oct 2000 13:09:19 +0100
Bob Silverman wrote:
>
> Cerainly not Hungerford or Lang. I think well of Birkhoff/MacLane.
> VanDerWaerden is a good book if you can find a translation.
>
> A good book from a comp. sci. perspective is "Modern Applied Algebra"
> by Birkhoff & Bartee.
I'm interested in refreshing and enhancing my understanding of algebra.
I did an undergrad degree in math & c.s. so I have a strong math
background but I'd like to improve my algebra, in particular looking to
understand modern cryptography as an end goal.
So I am looking for either a more complete undergrad level text (more
than just proving Galois Theory as the goal of the text), or an
introductory level graduate text.
The biggest issue for me is that I need it to be as self-contained as
possible since I do not have professors handy to ask questions to, or
ready access to other texts.
Thanks
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: hardware vs. software vs. crypto accelerators
Date: 27 Oct 2000 05:24:41 -0700
"Simon" <[EMAIL PROTECTED]> writes:
> I need to define an architecture that lists what crypto services are
> required, and how they should be delivered. The requirements range from
> simple secure email, ssl, right through to application specific encryption,
> and as the company are looking to deliver financial products, there is a
> requirement for payments to be macced, and protected in transit.
>
> So essentially there is a wide range of services required, and I want to put
> forward a paper that compares software toolkits against on host accelerators
> against network crypto appliances.
You still don't say what kinds of comparisons you want to make.
In my experience, using software toolkits takes a great deal of care
and discipline to keep the keys secret. Even the Los Alamos nuclear
bomb lab, which I'd hope would be one of the most secure facilities
in the world, seems to have trouble doing this (see the reports of
hard drives left behind xerox machines and so forth). Hardware
accelerators are not really cost effective on a pure performance
basis, but they let you sleep a lot easier about possible key leakage.
I've been using NCipher accelerators (www.ncipher.com) and have
been happy with them. They're made over there in the UK so you might
give them a call.
You could also look at the FIPS 140-1 hardware module test criteria
(follow links from csrc.nist.gov) to see what kinds of things hardware
modules do for you.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 27 Oct 2000 12:25:03 GMT
[EMAIL PROTECTED] (Runu Knips) wrote in
<[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> It can treat any file as a compressed encypted file.
>> So you can give the government any key since any key
>> will decrypt any file and when renecrypted you get same
>> file back.
>
>I don't understand the advantage.
>
>The government would like to get a key which leads to a
>reasonable result, doesn't it ? You can't tell them
>you've encrypted random data. And if you decrypt the
>file with the wrong key and pipe it through a bijective
>compressor, the result is again random.
The point is they can't prove you encrypted tect.
You may not have. It might be a data file for a card
game where the data could be used for dealing cards.
One could easily write many programs that use random
looking data for various purposes.
But if you used another compression encryption
program. You can't trick them with a wrong key since
it will not decrypt correctly
>
>So what ?
>
>Gained nothing.
>
>Well okay, except that you can't prove automatically
>that you have the wrong key, like with non-bijective
>compressors, but that is only of interest for brute
>force attacks.
That is where your wrong. The brute force argument is
to only show about the information added. It does not
mean that brute force is the only way to attack a poor
program.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 27 Oct 2000 12:43:31 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Fri, 27 Oct 2000 09:15:38 +0200, Runu Knips
><[EMAIL PROTECTED]> wrote, in part:
>
>>Well okay, except that you can't prove automatically
>>that you have the wrong key, like with non-bijective
>>compressors, but that is only of interest for brute
>>force attacks.
>
>Actually, unless known plaintext is available, if there isn't some
>property of the plaintext susceptible to automatic detection, the
>cryptanalyst doesn't have redundancy to exploit.
Your on the correct track so far.
>
>Now, if a random file decompresses to random data, there probably _is_
>a way to still do a brute-force attack, since even a bijective
>compressor is not a _perfect_ compressor.
It depends on what your defination "of perfect is". A huffman
compressor can be perfect based on certain conditons of the input.
Since this is a bejective transform it is pertfect for some
set of conditions. Something few other compressor implementations
can honestly state. However since it is a general compressor and
not targeted directly to only english text. It is not perfect for
that specific application.
>
>A nearly perfect compressor would be one that, when given a random
>input, would produce, say, a file that looked so much like a text file
>that only a human being could tell the difference with probability p,
>a file that looked so much like an image file that only a human being
>could tell it was just snow with probability q, a file that looked so
>much like an executable...
>
covered above.
>and so the compressor would have detailed descriptions built in of all
>the popular image file and word processor file formats, so that from
>its own ultra-compressed rich text format, it could build a valid word
>processor file using only a minimum number of bits to specify which
>word processor (hence the need for frequent updates!)...
What you fail to see is that if one did make a "perfect compreesor"
for a class of wordprocessors and languages. It would not be perofect
for a man who only writes in one language and in one style say with
edit on a DOS machine. If you ever get the chance to study higher
mathematics you learn that as you expand your list of requirements
for any perfect process. The less perfect it is for someone not
interested in haveing the full range of capabilites.
>
>this being on top of containing dictionaries for 100 or so popular
>languages...and presumably some kind of external choice of a
>probability profile file, so that the fact that you or I might
>consistently avoid sending text in Big5 or Basque could not be
>exploited.
>
>The level of compression really required to make brute-force searching
>even moderately more difficult is daunting to even think about. No
>wonder the conventional wisdom says to just use a bigger key.
Gee I thought conventional wisdom was to dazzle people how big
a key of a few hundred bits is. By giving them some bullshit about
how long a brute force seach would take. While ignoreing the fact
most people have forgotten about the information side of problem.
You just them that the math is too hard for anyone and consider
all other aspects as not important.
>
>That's why my viewpoint is - to take the middle road. To take
>advantage of easy opportunities to improve compression, but to avoid
>placing undue emphasis on this point, and to avoid making unwarranted
>claims.
>
I have never seen you take the middle road.
Matts code does both for those that think Rijndael is secure.
He has it. For those that want no added crap add to file so an
attacker can take advantage of it his has that. It has great
compression. It is a great tool of one wants to add others
things after it. It is like having your cake and eating it too.
I suggest you try it. I am sure your socalled middle of
the road approach is to badmouth it with out looking since I
suspect your quadrathing does not yet exist as working code
that is bijective.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
