Cryptography-Digest Digest #283, Volume #10 Tue, 21 Sep 99 01:13:03 EDT
Contents:
Re: Yarrow: a problem -- am I imagining it? (Scott Nelson)
Re: Yarrow: a problem -- am I imagining it? (David Wagner)
Re: some information theory (Tim Tyler)
EAR Relaxed? Really? (Greg)
Re: Schrodinger's Cat and *really* good compression ("rosi")
Another bug RE: CryptAPI (Greg)
Re: Yarrow: a problem -- am I imagining it? (Eric Lee Green)
Re: Yarrow: a problem -- am I imagining it? ("Richard Parker")
Re: Second "_NSAKey" (Peter Pearson)
Re: some information theory (SCOTT19U.ZIP_GUY)
Re: XTEA (Tom St Denis)
Re: Sources of randomness ("John E. Kuslich")
Re: some information theory (Anti-Spam)
Re: Second "_NSAKey" (Greg)
Re: Yarrow: a problem -- am I imagining it? (David Wagner)
Re: Second "_NSAKey" (Greg)
Re: Second "_NSAKey" (Greg)
Re: Second "_NSAKey" (Greg)
Re: frequency of prime numbers? (Donald Welsh)
Re: Second "_NSAKey" (Greg)
Re: Second "_NSAKey" (Greg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Yarrow: a problem -- am I imagining it?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 21 Sep 1999 00:16:31 GMT
On Mon, 20 Sep 1999 17:30:55 -0400, Paul Koning <[EMAIL PROTECTED]>
wrote:
>Mark Wooding wrote:
>>
>> Yarrow seems to be a rather clever design. But there's something that's
>> been nagging me about it for a while.
>>
>> The actual output bits are generated by a block cipher in counter mode.
>> A property of counter mode is that you don't get a repeat in the output
>> until you've been through every possible counter value. Thus, for any
>> two adjacent output blocks $O_i$ and $O_{i + 1}$,
>>
>> P(O_i = O_{i + 1}) = 0
>>
>> i.e., they'll always be different. This isn't what I'd expect from a
>> random source. In fact, if the cipher block size is N bits, I'd expect
>>
>> P(O_i = O_{i + 1}) = 2^{-N}
>
>I remember getting into a long debate with someone about a year
>ago on this very topic. It wasn't very conclusive. What I got out
>of it is:
>
>1. Yes, that's true.
That's only true without reseeding.
With reseeding there is a chance that consecutive outputs will
be the same, though it's still less than 2^{-N}
>2. So what?
>
>In other words, yes, you can use this property to distinguish a PRNG
>from an RNG. That doesn't mean it is a weakness. Nothing I heard
>back then convinced me that there is any problem here. It's merely
>an interesting amusing property.
>
Not much off a weakness for crypto. In fact, not much of a
weakness at all, but at least in theory someone could use
Yarrow to produce over a billion 64 bit data points without
reseeding and get whonky results. I'd bet pretty heavily
against this ever occurring in practice.
It does make me wonder though, why Yarrow didn't use
SHA1(160bit counter + 160 bit key) as the final output.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Yarrow: a problem -- am I imagining it?
Date: 20 Sep 1999 16:20:52 -0700
Counter mode -- like OFB, CBC, and CFB mode -- has security problems
after about 2^32 outputs (and not before), due to the non-random number
of repeats. This is a well-known consequence of the birthday paradox.
In practice, most well-designed cryptosystems change the key long before
the birthday limit. So no, this should not be a problem in real life.
Note that this is an artifact of a 64-bit block length, and is the reason
that the AES will have a 128-bit block length.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: some information theory
Reply-To: [EMAIL PROTECTED]
Date: Mon, 20 Sep 1999 15:20:59 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:>Anti-Spam <[EMAIL PROTECTED]> wrote:
:>: Random data is generally not compressable. OK. BUT, the converse is not
:>: a true statement - "compressed data should look random." ( If A implies
:>: B, then NOT B implies NOT A.)
:>
:>I wondered if anyone would debate the syllogism's logic when I posted ;-)
: Hay I don't know how to pronounce "syllogism" but i did fault you
: logic if you weren't to lazy to read it.
AFAICS, the validity of the statement does not depend only on the logic.
I wrote: "One definition of what constitutes "randomness" mentions that
random data is generally incompressible. Conversely, incompressible data
should look random - if there's any order in it it will be fodder for a
better algorithm that identifies that order and squeezes it out."
To me, this reads more like a flat statement than a logical argument.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Randomoneum.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: EAR Relaxed? Really?
Date: Tue, 21 Sep 1999 01:43:55 GMT
So what if the Clinton Administration says that they will allow
128 bit encryption to be exported? It still requires government
licensing- that is, NSA must review the software. Now think about
that for a minute. What market exists today anywhere in the world
for use of 128 bit compromised (by definition of NSA examination)
encryption software?
Until the day comes that anyone can post the source code to the
web of their strong encryption without prior restraint, there will
always exist the compromising factor in any product. And they
know this. They want that compromising factor. They know that
if this factor is removed from the equation, America will lead
the world into native (call it TCP/SIP) encryption at the lowest
levels where every web server is naturally secure, every e-mail
is naturally kept confidential, and project Echelon shuts down.
The EAR does not exist to keep strong encryption out of the hands
of criminals and terrorists, but out of the common and standard
use of Americans. Our leaders are too smart not to recognize this
and we must come to grips with their intentions.
By definition, any 128 bit browser you use, or server it ties to,
must be considered compromised because the US government is
involved.
Did you ever ask yourself, "well if we cannot export it, why not
set up a small shop overseas to import from?" It is such a simple
solution to the EAR, why hasn't anyone, including MS, gone that
route and formed a standard for all America to use? It is because
the US government does not want them too and they know the
rabid dog lies quiet when not provoked.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 20 Sep 1999 21:20:50 -0400
Douglas A. Gwyn wrote in message <[EMAIL PROTECTED]>...
>[EMAIL PROTECTED] wrote:
>> And here we come to Schrodinger's cat. One of the interpretations of
>> quantum mechanics held that a superposed quantum state did not resolve
>> itself into one state until it was exposed to the gaze of a *human
>> observer*.
>
>The point of Schr�dinger's cat is that it points up the logical
>problem with that interpretation (which seems to have fooled
>Roger Penrose too) -- why can't the cat play the role of observer?
^^^^^^^^^
I don't really know anything about the subject. But this to me sounds
beautiful, very beautiful.
>A self-consistent quantum theory of measurement has to be apply to
>the measuring device as well as to the object being measured.
>There *is* at least one such theory in general use today.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Another bug RE: CryptAPI
Date: Tue, 21 Sep 1999 01:28:56 GMT
The NSA key overshadows this by a wide distance, but in case
anyone is interested, I was looking for a way to develop
strong encryption and making it into a crypto provider DLL.
When I saw the gun registration forms- uh, I mean the crypto
provider SDK forms- I immediately knew I had to figure a way
around the Microsoft signature requirement. Anyone who wants
to do this should use the NSA key approach- substitute your own
key in place and then load your CPDLL. My approach is far more
complicated and unnecessary.
Anyway, what I did was figured that applications like bounds checker
and the api spy that MS documents in their MSDN sample and white
papers was an approach I would try. What I found was that on
NT I could inject my crypto DLL into the address space of, say,
MS Outlook Express. When it called the cryptAPI to encrypt or
decrypt, I would catch it and redirect it to my DLL instead. And
this worked. But then I realized that any virus can do the same
and take a copy of the plain text that is on its way to be
encrypted and broadcast it over the internet. So I completely
abandoned my approach to ever develop encryption in a DLL. For
more information, see www.ciphermax.com and go to the technology
page.
Again, the NSA key is a far more important find. It totally
destroys any integrity MS has had- period. Kudos to those
who made the discovery. Bugs are questionable. The NSA key
is absolute and total conspiracy on the part of Microsoft to
perpetrate fraud against its customers.
Everything you need to know how to do this is totally documented
by Microsoft. I will not supply any source code to anyone because
I am not in the business of helping manufacture viruses.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Yarrow: a problem -- am I imagining it?
Date: Mon, 20 Sep 1999 18:36:00 -0700
Scott Nelson wrote:
> It does make me wonder though, why Yarrow didn't use
> SHA1(160bit counter + 160 bit key) as the final output.
Yes, that is an interesting question, considering that SHA1 on the
output would give some measure of resistance against backtracking
attacks (assuming that some additional entropy was fed into it
occasionally to throw things off). On the other hand, it doesn't do much
about the other possible attacks, so I guess the decision was made that
that it would slow things down too much (3DES and SHA1 are not either
known for speed).
I made a different choice for Ocotillo (http://www.estinc.com/~eric ),
but I'm paranoid.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
There Is No Conspiracy
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Yarrow: a problem -- am I imagining it?
Date: Tue, 21 Sep 1999 02:07:12 GMT
Eric Lee Green <[EMAIL PROTECTED]> wrote:
> I made a different choice for Ocotillo (http://www.estinc.com/~eric ),
> but I'm paranoid.
Eric,
I have a question regarding the design of Ocotillo. After gathering
entropy to key the block cipher during initialization, Ocotillo uses
any additional entropy that accumulates to perturb the counter used as
the input to the block cipher. Why does Octillo use this accumulated
entropy to perturb the counter used as input to the cipher as opposed
to using the entropy to rekey the cipher?
-Richard
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Tue, 14 Sep 1999 09:23:47 -0700
Clifford Heath wrote:
> Does anyone want to explain how this purported "back door" operates,
> even if the NSA does hold the matching private key (MS claim they
> don't)?
Simple: the FBI breaks into your house and replaces your
Microsoft CSP with a look-alike NSA-signed CSP whose
random-number generator has been damaged in such a way that
it produces only a few billion different values. Thereafter,
if they want to intercept your communications or decrypt a
file seized from your computer with a proper search warrant,
they need only pursue a small keysearch attack.
As has been noted before, the US Department of Justice is
actively pressing congress to expand its authority to break
into your home to sabotage your computer's security software:
http://www.washingtonpost.com/wp-srv/business/daily/aug99/encryption20.htm
This NSAKEY development fits astonishingly well.
- Peter
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: some information theory
Date: Tue, 21 Sep 1999 05:21:01 GMT
In article <[EMAIL PROTECTED]>, Anti-Spam
<[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>>
>**** WHOLE LOTTA STUFF WE FAST FORWARD OVER *****
>
>> : A deterministic bit stream "combined" with another deterministic bit
>> : stream in a reversable (one-to-one and onto) process, no matter how
>> : complex or convoluted, produces another deterministic bit stream
>> : whose substrings will evidence some correlations.
>>
>> To put it another way, in order to produce the appearance of randomness
>> in the resulting compressed file, the compression program that needs to be
>> applied to an unboundedly large source data itself needs to become
>> unboundedly large. Optimally compressing large files which are not
>> themselves random becomes more and more "tricky" the larger the file.
>>
>> In general I'm talking about compressing files, rather than compressing
>> streams.
>>
>> When compressing files you have all the data available at once.
>
>
>The statement on resulting bit-stream pseudo-randomness still stands as
>true for the use of a binary file. If the algorithm used to compress
>the original file into a "compressed and *random* " output file relies
>only and totally on any or all possible substring (bit patterns) in the
>original uncompressed file, in any combination, accessed in any order
>(front of file, back of file, middles of file, round and round file..)
>no matter how complex, involuted and twisted, AND this operation must
>reverse the process on the compressed output to reproduce the original
>input, the result will be a new file of bits whose substrings will
>evidence some correlations and thus fail some or all tests for
>statistically valid random bit patterns.
>
>Random bits exhibit no correlation or dependence on any bits that appear
>before them or that follow them in the file. Unless randomness is
>injected into the process of compression from some true random exernal
>source, the resulting file's bits are pseudo-random.
Actually it is very hard to define what a random file is. Once you have
any file and start talking about it. It is not random but you could make
up some defination that if it passes some certain tests. You could call
it random. But if you keep making up more tests there are really no random
files. But if you take what you call a random file by your tests. And if you
run my decompression method. You will get a nonrandom file by some
of your tests. You may have to run it more than once if you cooked the
example by compressing a random file to get another random file. But
the expanded file will most likely not pass all your random tests.
Do something your mind my think is fair using quatum measurements.
Take many long runs. Most but not all will pass your test for randomness.
The fact is a random file really refers to how the file was generated but
it can still fail your tests for randomness. And just becuase it fails does
not mean it was not generated in a random way. But take one that
passes all your tests. Decompress it. It will more than likely fail
your test for randomness even though the compressed specially
generated file passes. I know this is hard for you to grasp but
think about it.
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: XTEA
Date: Tue, 21 Sep 1999 03:33:50 GMT
In article <01bf035b$575b6d20$0164640a@server>,
"Gary Partis" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is there such a concept as 'weak keys' in XTEA?
>
None in the DES weak sense but there MIGHT be detectable class keys. I would
guess relating to the upper bits of the keys.
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: Tue, 14 Sep 1999 11:01:26 -0700
If you have ever tried to design an electronic circuit that produces a
"random" stream, you will appreciate the difficulty of removing any
periodic (correlated) data.
The problem is pathologically difficult when strict randomness testing is
applied to the output stream. Power supply ripple, power line correlated
variations in the stream output, any tendency toward oscillation or under
damped response built into the electronic circuits will be obvious when
the output stream is tested. Circuit ground quality, parasitic loads or
feedback, common impedance loops all will influence the quality of the
output stream. These problems are exacerbated by the fact that most
sources of random signals are available only at millivolt levels and need
to be significantly amplified and processed before they are useable in
digital circuits. Unwanted signal pickup is a significant problem, even
when the circuits are shielded. Of course, if there is a bad guy in the
vicinity who wants to adversely affect the quality of your random source
there may also be microwave radiation having a periodic aspect which
could ruin the output stream statistics. (remember the US Embassy
microwave radiation in Russia?? )
Perhaps in the process of building a circuit that would use a periodic
signal as an input to produce a "random" output, one would learn enough
tricks to be able to properly design a good random source that would
reject periodic inputs like the plague .
JK
Mok-Kong Shen wrote:
> If I don't err, obtaining random bits from physical sources is
> commonly done where the phenomena involved are known to be fairly
> random, in particular without any apparent periodicity.
>
> Question: How about utilizing sources in the opposite direction,
> i.e. obtaining random bits from apparently periodic phenomena?
> Since perfectly periodic events are rare in real life and one has
> mostly at best only 'almost periodicity', I think one can somehow
> filter out the periodic wave form to obtain the noise that is
> superposed on it. How technically/economically feasible/difficult
> is such filtering work? Just for illustration of the idea, I suppose
> one could obtain random bits from a recording of one's pulses or
> other autonomous recurring biological signals.
>
> A related question (posted also in another thread): What is the order
> of magnitudes of the demand of random bits per unit of time for
> generating session keys in some typical environments?
>
> Thanks in advance.
>
> M. K. Shen
> -------------------------
> http://home.t-online.de/home/mok-kong.shen
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Mon, 20 Sep 1999 19:54:51 -0700
Tim Tyler wrote:
>
**** WHOLE LOTTA STUFF WE FAST FORWARD OVER *****
> : A deterministic bit stream "combined" with another deterministic bit
> : stream in a reversable (one-to-one and onto) process, no matter how
> : complex or convoluted, produces another deterministic bit stream
> : whose substrings will evidence some correlations.
>
> To put it another way, in order to produce the appearance of randomness
> in the resulting compressed file, the compression program that needs to be
> applied to an unboundedly large source data itself needs to become
> unboundedly large. Optimally compressing large files which are not
> themselves random becomes more and more "tricky" the larger the file.
>
> In general I'm talking about compressing files, rather than compressing
> streams.
>
> When compressing files you have all the data available at once.
The statement on resulting bit-stream pseudo-randomness still stands as
true for the use of a binary file. If the algorithm used to compress
the original file into a "compressed and *random* " output file relies
only and totally on any or all possible substring (bit patterns) in the
original uncompressed file, in any combination, accessed in any order
(front of file, back of file, middles of file, round and round file..)
no matter how complex, involuted and twisted, AND this operation must
reverse the process on the compressed output to reproduce the original
input, the result will be a new file of bits whose substrings will
evidence some correlations and thus fail some or all tests for
statistically valid random bit patterns.
Random bits exhibit no correlation or dependence on any bits that appear
before them or that follow them in the file. Unless randomness is
injected into the process of compression from some true random exernal
source, the resulting file's bits are pseudo-random.
[EMAIL PROTECTED]
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:33:35 GMT
> Oh, neat.
>
> That suggests it's trivial to defeat the purpose of those keys
> (prevent the use of crypto modules not signed by MS, i.e., subjected
> to export blessing via MS proxy). Anyone could create a crypto module
> anywhere, and sign it wit his own key, and supply that key along
> with the module.
>
> Is that right?
In the case of the NSA key, YES!!!! Now why do you think NSA
wanted it that way?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Yarrow: a problem -- am I imagining it?
Date: 20 Sep 1999 20:39:08 -0700
In article <[EMAIL PROTECTED]>,
Scott Nelson <[EMAIL PROTECTED]> wrote:
> It does make me wonder though, why Yarrow didn't use
> SHA1(160bit counter + 160 bit key) as the final output.
This is a bad idea.
It requires very strong assumptions about SHA1 if the resulting
construction is to be secure, and I don't think those particular
assumptions have received much scrutiny.
Triple-DES is far better.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:50:39 GMT
> Occam's razor indicates that we need not invoke any dark
> agencies in order to explain the facts available.
Uh Hmmmm.. I would disagree here. The NSA is the MOST viable
suspect to consider since it must sign off on any export license.
This would be far too convenient NOT to ask for a key of their own.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:53:49 GMT
> To the contrary, Microsoft *has* explained the purpose, and it
> was quite plausible
No it isn't...
>...and Microsoft didn't want to
> be forced to hand over their private key to NSA,
> so they anticipated this by providing for a second,
> NSA-private, key that could not be used to
> authenticate Microsoft modules but
> could be used by NSA to verify how the framework operated,
> using NSA's own (test) modules.
Why on earth would MS care if NSA kept their key? Is it such
strong crypto in and of itself that they felt it was too valuable
to allow the licensing agency to have? I don't think so.
This is a far fetched scenario in and of itself.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:45:51 GMT
> (Simple technique: NOP out the call that initializes the RNG in the
> application of interest. No "_NSAKEY" needed. Ian Goldberg and I
> implemented this for Netscape several years ago, and it was a trivial
> 4-byte patch to the binary.)
>
> Personally, I don't find your scenario a terribly plausible
> explanation for the existence of the "_NSAKEY".
Nor does yours make any sense. Both of these approaches would
leave the cipher text unreadable at the other end. The CPDLL
would have to function normally, but the plain text is syphoned
off and sent to a covert site. This is the WHY you are looking for.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Donald Welsh)
Subject: Re: frequency of prime numbers?
Date: Tue, 21 Sep 1999 04:32:53 GMT
On Fri, 06 Aug 1999 17:27:45 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
>No. What Goedel showed was that any sufficiently rich axiomatic
>system is incomplete in the sense that there are true statements
>which can not be proved. [as well as other stuff I won't discuss].
>Peano arithmetic is "sufficiently rich", BTW.
I'd like to correct this misconception, if I may. Godel's theorem
does not say that "there are true statements that cannot be proved".
It says that there are unprovable statements. These statements are
neither true nor false.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:59:36 GMT
Look! It is really simple. Take a look at everyone's arguments.
Then consider every possible scenario. Then you will find that
the only scenario that EFFORTLESSLY fits the evidence and facts
is the one that says the NSA wanted to get into your CPDLL and
replace it with their own that can send plain text to their
covert site.
It is so easy to understand. It is the only scenario that
EASILY fits everything we know to date. Surely if this was
not correct, MS or the feds could easily show why, and they
have not. Isn't that telling?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Second "_NSAKey"
Date: Tue, 21 Sep 1999 04:56:47 GMT
Seriously, do either of you believe anything MS says on this
subject after they got caught in a fraud against the American
people?
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
