Cryptography-Digest Digest #782, Volume #10      Wed, 22 Dec 99 12:13:02 EST

Contents:
  Re: MARS (Volker Hetzer)
  Re: Keystrokes monitored/encryption useless (Guy Macon)
  Re: Of one time pads, plaintext attacks, and fantasy (Guy Macon)
  Re: Synchronised random number generation for one-time pads (Guy Macon)
  Re: DES key safety (Markku-Juhani O. Saarinen)
  Re: MARS (Boaz Lopez)
  Re: Good way to one-way encrypt? (Christoffer =?iso-8859-1?Q?Lern=F6?=)
  Re: ElGamal Opinions, Please (lcs Mixmaster Remailer)
  Re: firmware encryption? (Paul Crowley)
  Re: ElGamal Opinions, Please ([EMAIL PROTECTED])
  Re: MARS (Tom St Denis)
  Re: elliptical curve encryption (Tom St Denis)
  Re: MARS (John Savard)
  Re: Of one time pads, plaintext attacks, and fantasy (John Savard)
  NSA and TRUTH (SCOTT19U.ZIP_GUY)
  Re: MARS (Tom St Denis)
  Re: Implementing ElGamal (Doug Stell)
  Re: MARS (John Savard)
  Re: compression & encryption (SCOTT19U.ZIP_GUY)
  Re: MARS (SCOTT19U.ZIP_GUY)

----------------------------------------------------------------------------

From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: MARS
Date: Wed, 22 Dec 1999 09:15:13 +0000

"William W. Joslin" wrote:
> 
> Can anyone tell me more about MARS algorithm...  I know that it is a
> finalist as an AES, but, tell me more about it...
You mean, something ythat isn't covered in the spec?
Well, personally I believe (in my VERY humble opinion) that it's the most
likely winner. Mainly for political reasons. However that is pure
speculation.

Greetings!
Volker
-- 
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

------------------------------

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Keystrokes monitored/encryption useless
Date: 22 Dec 1999 05:05:01 EST

Liyang Hu wrote:

>Frankly, I'm sick of projects involving PIC's, or any other 
>microcontroller for that matter. Every issue of every damn electronics 
>magazine now has at *least* one project involving one of those. I wish for 
>the old days when electronics required years of experience to get to grips 
>with, and when you could see from the circuit diagram how a certain 
>project worked. Now it's all just programming.

I would suggest that you stop reading sci.crypt and find a newsgroup
more to you liking.  While this newsgroup does touch on nonprogrammable
electronics, such discussions are usually limited to talking about
noise sources for creating "random" numbers.  The bulk of the posts
(and the topic of the newsgroup) are about various programmable systems.
These are mostly personal computers, but doing crypto on a microcontroller,
mainframe, steam powerd computer (anti-tempest!), etc. would also be
on topic.

>Anyway, I doubt I'd learn anything new from this.

Your choice.  There is always something to be learned.

>Apart from that, I dont have much spare time now for electronics anyway, 
>especially seeing as I'm not taking Technology for my A-Levels. Although I 
>have to agree with you - it would have been fun, if I had built it :)

Ah.  I see the problem.  You are in the mode where your learning is
constrained to that which gets you grades.  A reasonable position for
one who is in school.   Alas, in too many cases the attitude remains
after graduation, and we see engineers who fail to make the transition
to transistors, ICs, digital logic, Op amps, microcontrollers, hardware
description languages, etc. etc.  More $$$$ for those of us who keep
learning new things all of our lives, I suppose.


------------------------------

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: 22 Dec 1999 05:09:08 EST

In article <83p7al$kut$[EMAIL PROTECTED]>, [EMAIL PROTECTED] ([EMAIL PROTECTED]) 
wrote:
>
>Towards the end of "Cryptonomicon" by Stephenson (interesting
>novel by the way, anybody know of any others that use crypto as a plot
>device??) there's a part in which one of the "heroes" describes
>how he broke a very complex system that was essentially a one-time pad
>(as I understand the term). 


>The system in question was based on generating a pseudo-random sequence
>(using a Riemann-zeta function) and then adding it mod(26) to the
>plaintext.

I see the problem.  You don't understand the term "one-time pad".
If the "random" component is pseudo-random, it isn't a one-time pad.


------------------------------

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 22 Dec 1999 05:19:51 EST

In article <uz47kjDT$GA.286@cpmsnbbsa05>, [EMAIL PROTECTED] (Joseph Ashwood) wrote:
>
>"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>> amadeus wrote:
>>
>> Then there's the issue that a known-plaintext attack reveals the key - and
>> possibly allows inauthentic messages to be passed off as the real one.
>
>That's where I beg to differ, although the security of OTP is generally
>proven using XOR, there is no reason that one could not instead utilize
>[insert your favorite cipher here] instead. In fact using a different cipher
>could very well prove useful for this as it also eliminates an attack on the
>plaintext (the bit-flip attack/problem). I see where this would be more
>useful in the creation of stream ciphers, but it also applies to OTP.

I think that we all agree that OTP plus (some other method) has
different attributes than OTP alone.  This could indeed be useful;
OTP cannot be broken with cryptanalysis, so using another method
that is resistant to plaintext attacks but not to cryptanalysis
then feeding the result to your OTP would seem to be a good idea.

It's important to talk about the weaknesses and strengths of
various encoding methods as they stand without jumping into
quick fixes.  You need a good understanding of the basic scheme
before you can be confident that your proposed fix actually
addresses the weakness.


------------------------------

From: Markku-Juhani O. Saarinen <[EMAIL PROTECTED]>
Subject: Re: DES key safety
Date: 22 Dec 1999 10:59:51 GMT

> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > One question that would be nice to resolve is whether a single
> > 64-bit block of corresponding plain and ciphertext always
> > determines a *unique* 56-bit DES key.  (It's not obvious.)

David Wagner <[EMAIL PROTECTED]> wrote:
> Yes.  Non-obvious indeed.
> However, it would be extremely surprising if the answer is `yes'. 
(..)
> Another interesting feature of this calculation is that it suggests
> we could find a proof that the answer is `no' (as expected) using just
> 2^{72} work or so, if (..)

I hope that I'm understanding this correctly.. but doesn't it suffice just
to find collisions in DES ? 

Fix the plaintext block and take the new key from previous ciphertext
(minus the parity bits). Collision search is O(2^(n/2)) and thus the
overall complexity is around 2^8 * 2^28 = 2^36.

I don't have the paper with me right now but I believe that this was first
done by Jean-Jacques Quisquater and Jean-Paul Delescaille in "How easy is
collision search. New results and applications to DES ," In G. Brassard,
editor, Advances in Cryptology -- CRYPTO '89, volume 435 of Lecture Notes
in Computer Science, pages 408-413, 20-24 August 1989. Springer-Verlag,
1990.

- mj

Markku-Juhani Saarinen <[EMAIL PROTECTED]> University of Jyv�skyl�, Finland

------------------------------

From: Boaz Lopez <[EMAIL PROTECTED]>
Subject: Re: MARS
Date: Wed, 22 Dec 1999 03:33:13 -1000

William W. Joslin wrote:
> 
> Can anyone tell me more about MARS algorithm...  I know that it is a
> finalist as an AES, but, tell me more about it...

It's big, it's bad...
It takes a 128 bit plaintext and multiplies
some parts by other parts. The first round is different from
the middle rounds. The last round is different from the 
middle rounds. That is a good move. It is efficiently crafted.
It does no more rounds than are necessary for pleasant feelings.

------------------------------

From: Christoffer =?iso-8859-1?Q?Lern=F6?= <[EMAIL PROTECTED]>
Subject: Re: Good way to one-way encrypt?
Date: Wed, 22 Dec 1999 14:01:58 +0100

Eric Lee Green wrote:

> Christoffer Lern� wrote:
> > What's the best way of encrypting it?
>
> Probably an off-the-shelf one-way cryptographically-strong hash function such
> as SHA or MD5.

I'm kinda new to crypography in general where can I get a description of these?

> Note that if you're a server expecting to get this hash over a network, you
> first want to transmit a random challenge string, and have the client hash
> that challenge string into the already-hashed value prior to sending it over
> the network. This prevents someone from capturing the already-hashed value and
> replaying that sequence of packets to you later in order to break your
> security.

So you mean the server sends a random string which the client mixes the hash
with?

/Christoffer


------------------------------

Date: 22 Dec 1999 13:20:20 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: ElGamal Opinions, Please

With ElGamal encryption, we have a prime modulus p, and the generator of
some group g.  Let us call q the size of the group generated by g.

Which is better:

A.   q = p-1?
B.   q = (p-1)/2, and q is prime?
C.   q is substantially less than p, perhaps 256 bits, and is prime?

In case (A), g generates the entire group of order p-1.  However the
problem is that this will leak the low order bit of people's private keys
x, by whether y = g^x is a quadratic residue.  Furthermore the product
y^k * M may leak info on whether M is a quadratic residue.

In case (B), g generates the subgroup of all quadratic residues.  It no
longer leaks the low bit of x, however y^k * M will still reveal whether
M is a quadratic residue.

In case (C), g generates a small subgroup, still large enough to thwart
discrete log attacks.  x and k values will be small and so the arithmetic
is somewhat faster.  However M is probably not in the subgroup and,
depending on the factorization of (p-1)/q, this could leak a lot of
information about M.

The leaks about M can be reduced if it is randomized using something like
Optimal Asymmetric Encryption Padding (or plain old PKCS-1).  Normally
OAEP is used for RSA in order to prevent message-guessing attacks and
to make sure that there is wrap-around in the exponentiation, neither
of which is a consideration for ElGamal.  However it may be helpful in
the case of ElGamal in order to prevent information leakage about M.
Knowing that M is a quadratic residue, or knowing even more information
based on using a small subgroup, will not provide information about the
message payload if M is substantially random.

Comments?


------------------------------

From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: firmware encryption?
Date: 22 Dec 1999 08:36:18 -0000

[EMAIL PROTECTED] (Guy Macon) writes:
> A general question to the experts in this newsgroup:
> 
> Would CipherSaber-2 be a good choice for this application?

No.  CipherSaber is based on RC4, which requires a little over 256
bytes of memory to run.  I too would recommend an AES finalist for
this application.

I have other issues with the design of CS-2 which I've discussed
with the author, leading to a proposal for a CS-3 that overcomes
certain shortcomings.  Whether I'll ever find time to do a proper
writeup is another matter, of course...
-- 
  __
\/ o\ [EMAIL PROTECTED]     Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: ElGamal Opinions, Please
Date: Wed, 22 Dec 1999 13:32:55 GMT

In article <83okjf$794$[EMAIL PROTECTED]>,
  Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <TOs74.596$pf1.1005@client>,
>   "David" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am charged with the task of encrypting session key using a public
> key
> > algorithm.
> >
> > We have opted away from RSA, since the still pending patent entails
a
> large
> > cost to use.
>
> Huh?  There seems to be some confusion. The only thing "pending"
> about the RSA patent is its expiration in the fall of 2000. It
> certainly is NOT a "pending patent"

If I remember correctly, how RSA is used will still be patented.
Someone may wish to check me on this.
>
> >  Management here is now leaning towards ElGamal, which seems to
> > be free to use.
> >
> > Can I have your opinions as to the suitability of this idea?
>
> ElGamal with a 1024 bit key certainly possesses adequate security.
> But as to whether it is actually suitable, noone can answer without
> your first answering "suitable for what?".   What application did
> you have in mind?  "encrypting session keys" is just too vague.
> Is speed of encryption/decryption an issue? Is size of certs an issue?
> etc. etc.   You leave too much unsaid to be able to reasonably answer
> your question.

One other thing is that the size of the encrypted file will be twice as
large using El-Gamal than if you were using RSA.  Otherwise, there's
really no reason not to use it unless you need to be complient with
something.

One question: is the encryption being used to facilitate a key exchange?
If so, you may wish to consider using Diffie-Hellman.

csybrandy
>
> --
> 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.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MARS
Date: Wed, 22 Dec 1999 13:58:35 GMT

In article <6yW74.872$[EMAIL PROTECTED]>,
  "William W. Joslin" <[EMAIL PROTECTED]> wrote:
> Can anyone tell me more about MARS algorithm...  I know that it is a
> finalist as an AES, but, tell me more about it...
>

Why not goto the nist website and download the paper?  It can explain
it all for ya.  [I think I have a copy local if you want me to email it]

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: elliptical curve encryption
Date: Wed, 22 Dec 1999 13:57:32 GMT

In article <Pine.SOL.3.96.991222041801.14529A-100000@giaspna>,
  MANIK TANEJA <[EMAIL PROTECTED]> wrote:
> hi all ! can someone provide me with a reference to details,
algorithms,
> implementation issues on ECES. thank you

Get the book 'Implementing Eliptic Curve Cryptography' by Mike Rosing.
Good book.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: MARS
Date: Wed, 22 Dec 1999 13:57:55 GMT

On Tue, 21 Dec 1999 20:22:14 -0600, "William W. Joslin"
<[EMAIL PROTECTED]> wrote:

>Can anyone tell me more about MARS algorithm...  I know that it is a
>finalist as an AES, but, tell me more about it...

IBM has a complete description of the algorithm on the web, and a
pointer to it exists on my web page, which also includes a description
of the algorithm.

First, the block is XORed with key material, for whitening. Then,
there are a few rounds of an unkeyed DES-like scramble. The interior
rounds, called the "cryptographic core", do not diffuse as rapidly as
a more DES-like round might, but they do include multiplication for
nonlinearity; there are also one or more 256 by 32 S-boxes. Then
another unkeyed scramble, and a final XOR.

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Of one time pads, plaintext attacks, and fantasy
Date: Wed, 22 Dec 1999 13:59:38 GMT

On Wed, 22 Dec 1999 00:51:35 GMT, [EMAIL PROTECTED] wrote:

>I know that in general, that was a technique sometimes used during
>wartime to break enemy ciphers. But the more I thought about it, I don't
>see how that would work with a one-time system.

You're right, it couldn't.

>The system in question was based on generating a pseudo-random sequence
>(using a Riemann-zeta function) and then adding it mod(26) to the
>plaintext.

But that isn't a one-time system. So it could work there, because a
cryptanalyst might recognize the mathematical pattern in the _pseudo_
random sequence.

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: NSA and TRUTH
Date: Wed, 22 Dec 1999 16:21:22 GMT



Below is a pointer to something most will enjoy.
It also has a fine quote direct from our PRESIDENT.

http://www.humnet.ucla.edu/people/maschke/the_lying_game.html


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: MARS
Date: Wed, 22 Dec 1999 15:21:42 GMT

In article <[EMAIL PROTECTED]>,
  Volker Hetzer <[EMAIL PROTECTED]> wrote:
> "William W. Joslin" wrote:
> >
> > Can anyone tell me more about MARS algorithm...  I know that it is a
> > finalist as an AES, but, tell me more about it...
> You mean, something ythat isn't covered in the spec?
> Well, personally I believe (in my VERY humble opinion) that it's the
most
> likely winner. Mainly for political reasons. However that is pure
> speculation.
>

Well like it has been said before many many times, I doubt myself there
will be one winner.  RC6 for example is very simple to implement,
compact and fast. Twofish is also very fast and very flexible, Rijndael
is compact as well, etc...

MARS is a good cipher as well [although I don't know it as well].  I
really like there forward/backwards mixing before/after the crypto core.

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Implementing ElGamal
Date: Wed, 22 Dec 1999 15:23:37 GMT

On Wed, 22 Dec 1999 01:33:08 -0500, "Rowland Smith"
<[EMAIL PROTECTED]> wrote:


>   b/a^x mod p as ( b / ( a^x ) ) mod p

This should be read a b*(a^-x) = b*((a^x)^-1) = b*((a^-1)^x) mod p

There is no division in modular arithmatic, as we think of division
from the math taught in high school. There is, however, a notion of
"multiplicative inverse" and it exists in this case. Y is the
multiplicative inverse of X if X*Y = 1 mod p. The texts will tell you
how to calculate the multiplicative inverse using the Extended Euclid
Algorithm.

This is a very common problem, so don't feel bad. 

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: MARS
Date: Wed, 22 Dec 1999 09:06:44 GMT

[EMAIL PROTECTED] (John Savard) wrote, in part:

>IBM has a complete description of the algorithm on the web, and a
>pointer to it exists on my web page, which also includes a description
>of the algorithm.

But I see that my .sig file didn't work...

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compression & encryption
Date: Wed, 22 Dec 1999 17:11:40 GMT

In article <83ofas$omq$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kenneth Almquist) 
wrote:
>>        I don't think that compression is the anwser to every thing.
>> Like I state over and over correct compression just does not add
>> information to a system.  But if done correctly you are correct if
>> an attacker has a an "exact copy" of the plaintext and the encrypted
>> file he can just compress the file and then use it as he would have
>> used the plain text in a a system with out compression and test
>> all the keys.  SO WHAT.
>
>So in most applications an attacker can get sufficient information that
>additional information provided by a compression algorithm will not make
>an appreciable difference.  The solution is to use an encryption algorithm
>which can resist a known plaintext attack.
>                                Kenneth Almquist

   The soultion is to "not use bad compression" even Mr BS the widely
whorshipped crypto god says in his book compression before encryption
is a very good idea. But of course he fails to tell you that bad compression
can leave your encrypted messages subject to a "ciphertext only" type of
attack. One uses compression with the hope of making messages shorter
and it can increase the entropy per bit of the message. One would hope
the closer one gets to perfect compression that every wrong guessed key
leads to a plausible message. This sort of thing makes guessing the
correct password very hard. But real compression falls short of this goal.
In fact most compression schemes fall so far short of this goal that if
you encrypt a message and compress it there may only be one message
that could have been encrypted when all the various kind of keys are tried.
  Sure one should try to use secure methods which resist a known plan text
attack. But there are newer plaintext attacks everyday and many that are
not published in the open literature. How do you protect agaisnt them.
You can't.  My only point is if you use "bad compression" and if the
system is weak to someones plain attack. Then your system could be
weak to a "ciphertext only attack" just becasue bad compression was used.
 Good compression ( mine or Matt's for now) will not add information to
the file so that it would be easyier to attack. The real entropy of the 
message per bit goes up if your using one of our methods. Example
take my conditional 1-1 compression use just the alphabet upper case and space
and 0 to 9 make a condtion file with these symbols. In the condition file
use a big typical message that has all the symbols in use. This will
allow the adpative huffman compressor to be conditioned and preset so
that frequently occur characters have shorter paths in starting tree.
Now compress your mess with my conditional 1-1 adaptive compressor.
You get a binary file out. Encrypt it with any AES DES or FISHY method
of your choice.  You should have a mush smaller file than if you did
not compress at all.  The question is if some trys to decrypt with a random
key what would they get.  While in the system where you conditionally
compressed when the user tries a test key and uncompresses he will
get a meassage only in the character set you used. Every key will generate
a new message. Sure most will be unreadable but they will in the start of
the message have similar character to frequencies of a real message because
ot the condtion file. Know try bad keys to the system with out compressing.
Suppose your a GOD or a good mathematican and you can find the keys
that lead to the chacters you know the user used. The odds are there is only
one such key. Guess what that is the key you used.
Now lets suspose you use bad compression and do the same thing.
May be it compresses to a smaller file than mine. Sounds great so far
know lets see how many keys lead to file with the right characteristics. 
Unfortunately like in the case where no compression used there is most likely 
only one such file.  Worse yet if the message was short to begin with like
only one block in length the method with out compression may be apt
to lead to more possible messages than the one with your compression.
The reason is shorter files when decrypted have a smaller matching problem
so when the message gets longer than the key which should be much longer
than a data block the number of possible candidate soultions gets smaller.
Also again in the short message you can only look at candidates that are
real compressed files.
 I hope this helps you.
 


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: MARS
Date: Wed, 22 Dec 1999 17:44:07 GMT

In article <[EMAIL PROTECTED]>, Volker Hetzer 
<[EMAIL PROTECTED]> wrote:
>"William W. Joslin" wrote:
>> 
>> Can anyone tell me more about MARS algorithm...  I know that it is a
>> finalist as an AES, but, tell me more about it...
>You mean, something ythat isn't covered in the spec?
>Well, personally I believe (in my VERY humble opinion) that it's the most
>likely winner. Mainly for political reasons. However that is pure
>speculation.
>
>Greetings!
>Volker

    Well I suspect TWOFISH will be the winner since the whole
contest is FISHY to begin with and MR BS will be rewared for
his job of skillfully leading the public to belive the contest is for
real.  However I am sure there are other political considerations
and for anything the government does one must alwasy be aware
of the political pressures since in this kind of dog and pony show
they are the reasons that count. PLEASE what are the political
reasons for MARS winning. Did they donate a lot of money to the
DNC or what?
 


David A. Scott
--

SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
                    
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm

Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm

Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm

**NOTE EMAIL address is for SPAMERS***

I leave you with this final thought from President Bill Clinton:

   "The road to tyranny, we must never forget, begins with the destruction of the 
truth." 

------------------------------


** 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
******************************

Reply via email to