Cryptography-Digest Digest #222, Volume #9 Thu, 11 Mar 99 08:13:03 EST
Contents:
Conference IMACS-IEEE CSCC'99 ("William F. Gilreath")
Re: Finite Field with Hard Division? (Peter L. Montgomery)
Re: Where have I seen this? ("almis")
Re: RC4 (Michael Sierchio)
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
SCOTT19U GLOAT CONTEST ([EMAIL PROTECTED])
Re: Cyclotomic Number Generators ("Douglas A. Gwyn")
Re: Musings on the PKZip stream-cipher (Sundial Services)
Re: Are there free RSA Software lib's ? (Rosenegger Josef)
Re: Key Schedule Error Corrected in Quadibloc III
Re: RC4 in PGP ([EMAIL PROTECTED])
Re: Where have I seen this? ("Trevor Jackson, III")
updated rc4/5/6 code, birthday attack ([EMAIL PROTECTED])
Re: Variable Cipher ("Trevor Jackson, III")
Re: Testing Algorithms [moving off-topic] ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: "William F. Gilreath" <[EMAIL PROTECTED]>
Subject: Conference IMACS-IEEE CSCC'99
Date: Tue, 9 Mar 1999 22:31:26 -0600
Dear Colleague,
The Organizing Committee of CSCC'99 has the great honor to announce that
the Conference IMACS-IEEE CSCC'99 is dedicated to the Founder of the Fuzzy
Logic, Professor Lotfi Zadeh.
Professor L.Zadeh will be with us in Athens (Greece) in July for CSCC'99
presenting a Plenary Lecture titled:
"From Computing with Numbers to Computing with Words - From Manipulation
of Measurements to Manipulation of Perceptions."
CSCC'99 is The 3rd IMACS|IEEE International Multiconference on CIRCUITS,
SYSTEMS, COMMUNICATIONS AND COMPUTERS.
(Co-sponsored by WSES, Greece Section of IEEE, MIUE, HNA)
The detailed information about the conference can be found at:
http://www.softlab.ntua.gr/~mastor/CSCC99.htm
Do not hesitate to contact us if you need some help or additional
information. Looking forward to seeing you in Athens, in Summer 1999.
Best Regards
Nikos E. Mastorakis
Marcin Paprzycki
Conference Chairs
------------------------------
Crossposted-To: sci.math
From: [EMAIL PROTECTED] (Peter L. Montgomery)
Subject: Re: Finite Field with Hard Division?
Date: Thu, 11 Mar 1999 04:31:02 GMT
In article <[EMAIL PROTECTED]>
Anonymous <[EMAIL PROTECTED]> writes:
>Is there a finite field where addition and multiplication
>are easy, but there is no known algorithm for finding
>multiplicative inverses in polynomial time?
>Is there a trapdoor form of this, where division is hard
>if you don't know the secret (e.g. the factors of some
>large composite), but easy if you do know the secret?
If the field has q elements, then x^q = x for all x in the field.
The inverse of any nonzero x is x^(q-2). You can get this with
O(log(q)) multiplications, regardless of the method used to
encode field elements.
Can q be unknown? If the characteristic p is known,
and q = p^k for some unknown k, we can compute x^p, x^(p^2),
x^(p^3), ..., until we get x again. When we find j with
x^(p^j) = x, we backtrack and find x^(p^j - 2).
I'm unsure how to proceed if our modulus is a
large but unknown odd prime, and the field representation
is non-linear. This might apply if a black box
could be given the DES encryptions of two field elements,
and would return the DES encryptions of their sum and product.
--
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
From: "almis" <[EMAIL PROTECTED]>
Subject: Re: Where have I seen this?
Date: Wed, 10 Mar 1999 22:15:47 -0600
Dan S. Camper wrote in message ...
|All:
|
|Recently I've read -- somewhere -- about a scheme that supposedly allows
|you to "reuse" a chunk of random numbers. The algorithm, if I remember
|correctly, went something like this:
|
|1) Generate a bunch of random numbers (a pad).
|2) Generate random offsets into the pad.
|3) When you need a random byte, extract the bytes from
| the pad at the offsets and XOR them together to get
| a single output byte.
|4) Increment all the offsets, wrapping them to zero
| in case of overflow.
|5) The total key, in this case, becomes the pad and
| the original list of offsets. I believe that the
| original discussions indicated that the pad could
| be reused for many messages and/or users, in which
| case only the offsets need to be transmitted as keys.
|
|I spent quite a while crawling through Deja News and a couple of other
|archives trying to find discussions about this, with no luck. Does anyone
|have any further information about it or can direct me to another source?
|
|Thanks for your time!
|
|DSC
|
|____________________________________________________________________
|Dan S. Camper [EMAIL PROTECTED]
|Borrowed Time, Inc.
This, Dan, is a rotor machine.
Efficiency requires that the rotors be 'parallel' stepped. and the most
efficent form
is when the length of the rotors are relativley prime.
Randomly selecting starting points for each rotor (pad) has the disadvantage
of possibly using the same section of several pads for long messages. Making
the pads sucesptable to analysis.
I have a paper on this subject. If interested let me know.
...al
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RC4
Date: Wed, 10 Mar 1999 19:36:27 -0800
Reply-To: [EMAIL PROTECTED]
Jim Gillogly wrote:
>
> Michael Sierchio wrote [regarding RC4 and ESP]:
> > Using SKIP on a 100-BASE-T net, I get about 80% of unencrypted throughput
> > using RC4-128, and about 70% using DES-CBC, IDEA, SAFER-128-SK, etc.
> > The difference is greater on big, fat streams, like video or audio.
>
> Very nice! Using beefy hardware for the encryption? Hand-bummed ASM?
On one side, a Sparc, but the other SKIP filter is running FreeBSD 2.2.8
and has a 200 MHz Pentium "Genuine Intel" :-b Which is lagging pretty
far behind the head of the pack.
RC4 works well in this application -- running a profiler reveals that
out of sequence packets are by no means rare but are also not a
burden. Precomputing both the DH shared key, which changes hourly, and
the symmetric keys is a timesaver. I don't hash output from the process
table to get random numbers (the reference implementation does), I use
/dev/random.*
There are many aspects of SKIP that are IMHO superior to ISAKMP/Oakley.
Sun didn't present the case very well in the IETF, and also never
implemented the protocol (algorithm discovery, etc.), and didn't
understand the need for a PKI to support trusted, signed certs
with DH public values. SSL3 is neatly
designed, and in the case in which the "client" is required to
present a cert to complete session negotiation, represents a
technique that protocol designers should learn from.
Managing keys when deploying SKIP is a pain, esp. with a large
number of mobile users.
* The ref code does this to gather "entropy" every so many seconds and
runs the output through SHA:
"/usr/sbin/pstat -f 2>&1",
"/usr/bin/netstat -n 2>&1",
"/usr/bin/vmstat -s 2>&1",
"/usr/bin/netstat -in 2>&1",
"/usr/sbin/pstat -st 2>&1",
"/usr/bin/netstat -sn 2>&1",
"/usr/sbin/iostat 2>&1",
"/usr/bin/netstat -rn 2>&1"
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 10 Mar 1999 07:32:58 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>Because you can shut down the TRNG anytime you want, and perform
>extensive tests on its subsystems to make sure it is performing as
>specitfied, you are not introducing any predictibility into the
>keystream that an attacker would not otherwise assume. But it is so
>miniscule to be of no significance.
>
>On the other hand, if you systematically remove certain sequences
>because you are prejudiced against regularity, and the attacker
>discovers that, then you have given him a information to help him
>attack the ciphers.
>
>>Bear in mind that I am talking about real time testing, (which obviously has
>>limits). A value of all zero's may be legitimate, but is of no use (and may
>>be dangerous) for most crypto applications.
>
>Most of us seem to be in agreement that the null string and its
>complement are so pathological as to warrant special treatment.
>
>>Even if we used this RNG to feed an
>>OTP which is encrypting plain english language text, a long run of 0's may
>>reveal a secret.
>
>How? If the attacker has no reason to believe that a long run of 0s is
>any more probable than a sequence of high algorithmic complexity, how
>can he bet the ranch on that interpretation?
>
I think we may be on different tracks here. A RNG which is used in real time
operation, dishing out key material must be checked continuously. If you rely
only on periodic off-line testing you may potentially have dished out Megs
worth of useless material which will have already been put to use. Unless you
know exactly how all the information is being used, you must assume that you
could be compromising the security of the applications. I thought that this was
all fairly obvious. I understand where you are comming from, that is also very
obvious information, but I don't think that you are getting what I am trying to
say.
This thread is getting boring now.
Mark Currie
------------------------------
From: [EMAIL PROTECTED]
Subject: SCOTT19U GLOAT CONTEST
Date: Thu, 11 Mar 1999 06:53:18 GMT
Well folks I am a little behind in putting up the first part
of solution. But Joe Peschel's site had the clue up quicker. I have
not been writting much as I have been working on the Adaptive
Huffman compression programs that will make suitable compression
methods for those that wish to compress text in a way that does
not leak information that helps an attacker break your messages
if one is stuck using methods poorer than all or nothing
encryption methods of scott19u.zip
I will most likely only work on compression in this country since
it lacks the freedoms that our forefathers had planned for all
americans. I hope to set up shop in Mexico in a short time and
since they seem to allow people there to write encryption
programs with out the fear of jail. The country has won my
respect. I hope to be lucky enough to marry a fine mexican woman
but I hope some day that US citizens can once again be free.
But I suspect that those freedoms are lost forever. Just as
the one time belief that the president was not above the law.
It would be to much to expect that we could someday be free again.
One question though. After the Clinton thing I wonder if any
of our young will ever bother to tell the truth in court again.
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cyclotomic Number Generators
Date: Thu, 11 Mar 1999 09:03:46 GMT
"R. Knauer" wrote:
> The conclusion I reached after having waded thru that book was that
> cyclotomic number generation was an important issue in stream ciphers,
Assuming this is related to cyclotomic fields or cyclotomic integers,
it might have some relevance to elliptic curve cryptography, but not
to stream ciphers in general.
> The cyclotomic generator is supposedly the most secure
> keystream generator known.
One wonders what a proof of that would look like
(assuming that the important missing details are filled in);
it's hard to imagine.
One reason to think that it's wrong is that it's a deterministic
mathematical algorithm, and the objects involved have a lot of
structure (which usually means there are ways to exploit the
structure). Surely, a keystream generated from a thermal or
radioactive source is "more secure" in any meaningful sense.
------------------------------
Date: Tue, 02 Mar 1999 14:02:40 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Musings on the PKZip stream-cipher
Anthony Naggs wrote:
> The mask byte in turn is trivially determined from a plaintext/
> ciphertext byte pair.
But there appear to be two not-quite-trivial obstacles in the way.
First of all, the data -is- compressed and if you do not know what the
compressed data is EXACTLY, you may not know at all what even one
plaintext-byte might be. (If you do know, there are many published
known-plaintext attacks and programs to work them.)
Second, the compressed stream includes twelve random bytes in front of
the compressed data. Terry has alluded to the notion that you can start
anywhere in the cipher with only twelve bytes ...
... but you know, twelve known bytes is effectively a "96-bit key"
because you have to know 96 consecutive bytes correctly to strip off the
decipherment.
Essentially, what made me abandon my consideration of this cipher (and
this is hardly a military purpose so PKZip might have been "okay") was
the concern that someone could, by comparing (e.g.) the headers of
multiple archive-members (all known to be enciphered using the same key)
deduce enough twelve-bytes or enough commonality to deduce the key value
-- not by examination of one member but by examining several.
Anyhow... very enlightening info from you both. Thank you all.
------------------------------
From: Rosenegger Josef <[EMAIL PROTECTED]>
Subject: Re: Are there free RSA Software lib's ?
Date: 11 Mar 1999 09:32:56 GMT
Now I red a few notes concerning the RSA patents.
My conclusion: 1.) I'm allowed to implement the RSA algorithms
exported from the US, in our products, also for commercial use, but
2.) Our partners in the US arn't
allowed to import this new products without licence from RSA Data Security
Inc.
Is this right?
regards
Josef
Rich Wales wrote:
> Bill Stewart wrote:
>
> In the US and Canada, any use of RSA is subject to
> RSA's patent.
>
> Do you have a reference for the above claim, as regards Canada?
>
> My understanding has been that the RSA algorithm is patented only in the
> US, not Canada -- and that, as a result, residents of Canada are free to
> use either RSAREF (which US law allows to be exported to Canada) or a
> third-party implementation such as Phil Zimmermann's MPILIB.
>
> Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
======================================
SZ Testsysteme AG
Josef Rosenegger, Software Development
mailto:[EMAIL PROTECTED]
http://www.sz-testsysteme.de
Phone: +49 8075 17-239
Fax: +49 8075 1588
======================================
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Key Schedule Error Corrected in Quadibloc III
Date: 11 Mar 99 05:13:22 GMT
John Savard ([EMAIL PROTECTED]) wrote:
: My description of the key schedule for Quadibloc III completely omitted any
: mention of how the key-dependent S-box S8, used in Quadibloc III as well as
: in Quadibloc II, is generated.
There was another mistake: the middle GoodStuff rounds were given an
arrangement that did not at all correspond to the original design goals:
the second round stood in the (second) best relationship to the first, but
the third was not appropriate at all: it has now been changed, so that it
has the (third) best relationship.
John Savard
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 in PGP
Date: Thu, 11 Mar 1999 11:49:31 GMT
> > BTW, what are the actual restrictions on RC4/5/6? RSA didn't reply! So is
> > the patent only valid in the states?
>
> Give 'em time! Have you ever known an attorney to give you an
> answer in less than a few days?
>
I would figure this is a question they get asked alot.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Thu, 11 Mar 1999 07:25:21 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Where have I seen this?
almis wrote:
> Dan S. Camper wrote in message ...
> |All:
> |
> |Recently I've read -- somewhere -- about a scheme that supposedly allows
> |you to "reuse" a chunk of random numbers. The algorithm, if I remember
> |correctly, went something like this:
> |
> |1) Generate a bunch of random numbers (a pad).
> |2) Generate random offsets into the pad.
> |3) When you need a random byte, extract the bytes from
> | the pad at the offsets and XOR them together to get
> | a single output byte.
> |4) Increment all the offsets, wrapping them to zero
> | in case of overflow.
> |5) The total key, in this case, becomes the pad and
> | the original list of offsets. I believe that the
> | original discussions indicated that the pad could
> | be reused for many messages and/or users, in which
> | case only the offsets need to be transmitted as keys.
> |
> |I spent quite a while crawling through Deja News and a couple of other
> |archives trying to find discussions about this, with no luck. Does anyone
> |have any further information about it or can direct me to another source?
> |
> |Thanks for your time!
> |
> |DSC
> |
> |____________________________________________________________________
> |Dan S. Camper [EMAIL PROTECTED]
> |Borrowed Time, Inc.
>
> This, Dan, is a rotor machine.
> Efficiency requires that the rotors be 'parallel' stepped. and the most
> efficent form
> is when the length of the rotors are relativley prime.
> Randomly selecting starting points for each rotor (pad) has the disadvantage
> of possibly using the same section of several pads for long messages. Making
> the pads sucesptable to analysis.
> I have a paper on this subject. If interested let me know.
>
> ...al
I'm interested in this concept, so I'd like to read your paper.
------------------------------
From: [EMAIL PROTECTED]
Subject: updated rc4/5/6 code, birthday attack
Date: Thu, 11 Mar 1999 12:15:31 GMT
I updated the RC4/5/6 code, there were only typo things. They are at:
http://members.tripod.com/~tomstdenis/rc4.c
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
Also what is the birthday attack?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Thu, 11 Mar 1999 07:31:22 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Variable Cipher
<HTML>
D wrote:
<BLOCKQUOTE TYPE=CITE> I have posted my cipher idea (you
remember, the one with multiple
<BR>operations) in source and exe format here
<BR> I have not written a description (i do plan to),
but it is fairly
<BR>simple, yet deceptively complex
<BR> I really think that this cipher has potential and
I would like lots of
<BR>feedback.
<BR> Here is an overview.
<P>Key: It has 8 numbers that have a length in
multiples of 32 bits,
<BR> each number can be 32-320
bits, but all 8 of them must have the
<BR> same length
<BR>
Also, there are a variable number of files with instructions in
<BR> them. Each file constitutes
one round. Each instruction names a
<BR>range of plaintext bits, and a range of keybits or CFB bits.
<BR> Each instruction can be:
add, substitute, xor, multiply,
<BR> bakwordize, or intersperse
(like abcdef -> adbecf).</BLOCKQUOTE>
This means you really have two fundamental operations: substitute and transpose
(intersperse). All of the other operations you listed: add, xor,
multiply, and reverse (bakwordize) are trivial forms of a more general
substitution.
<BLOCKQUOTE TYPE=CITE>
<P>Operation: One instruction is picked from each file according
to the
<BR>key and/or CFB, and is used to encrypt the curent block, which is
<BR>also variable. After each block, the key is incremented according
<BR>to a sort of quadratic fractal scheme: ax^2+bx+c
<BR>
X is composed of the last 5 numbers of the key, and a, b, and c
<BR> are the first 3 numbers
of the key and remain constant, they are
<BR>not used in the operations.</BLOCKQUOTE>
</HTML>
------------------------------
Date: Thu, 11 Mar 1999 07:47:18 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms [moving off-topic]
<HTML>
Doggmatic wrote:
<BLOCKQUOTE TYPE=CITE>In article <7c3f59$4f7$[EMAIL PROTECTED]>,
<BR> [EMAIL PROTECTED] (Patrick Juola) wrote:
<BR>> In article <7bpipm$drj$[EMAIL PROTECTED]>,
<BR>> Doggmatic <[EMAIL PROTECTED]> wrote:
<BR>> >In article <7bonge$81b$[EMAIL PROTECTED]>,
<BR>> > [EMAIL PROTECTED] (Patrick Juola) wrote:
<BR>> >> In article <7bn566$b44$[EMAIL PROTECTED]>,
<BR>> >> Doggmatic <[EMAIL PROTECTED]> wrote:
<BR>> >> >In article <7b70cj$1li$[EMAIL PROTECTED]>,
<BR>> >> > [EMAIL PROTECTED] (Patrick Juola) wrote:
<BR>> >> >> In article <7b6tmq$ojt$[EMAIL PROTECTED]>,
<BR>> >> >> Doggmatic <[EMAIL PROTECTED]> wrote:
<BR>> >> >>
<BR>> >> >> >But I will look up this "reversible computing." For such a
<BR>> >> >> >great idea researched 30 years ago, you think I'd have my
Free-Energy
<BR>> >> >> >computer by now.
<BR>> >> >>
<BR>> >> >> I'll build one for you. Just buy me a frictionless surface.
<BR>> >> >[snip]
<BR>> >[snip my previous condescension]
<BR>> >> >accepted that there is no such thing as a "frictionless surface"
in this
<BR>> >> >universe. Here is where you can correct me if I'm wrong.
I know that
<BR>> >> >theoretically you can have smoother and smoother surfaces, but
I thought
<BR>that
<BR>> >> >a frictionless surface is a physical impossiblilty, which is
why I've also
<BR>> >> >wondered about why "parasitic losses" were mention as if they
are
<BR>> >> >inconsequential.
<BR>> >>
<BR>> >> Because "parasitic losses" are the sort of things that engineers
are
<BR>> >> really good at reducing as technology improves. Look at
the amount
<BR>> >> of waste heat and waste power that a vacuum tube uses when compared
<BR>> >> with an identically functioning IC transistor.
<BR>> >>
<BR>> >> > If the ideal cannot be reached, which is my current
belief,
<BR>> >> >then why even mention it, since this thread was originally about
tractable
<BR>> >> >solutions and not impossible ideal solutions.
<BR>> >>
<BR>> >> Because what is tractable in fifty years will be a hell of a lot
closer
<BR>> >> to the ideal than what's tractable today. And you don't
have any idea
<BR>> >> how much closer.
<BR>> >>
<BR>> >> -kitten
<BR>> >
<BR>> > Okay .. we'll play your game. Sample program:
<BR>> >
<BR>> > Time equals 0; <--- some arbitrary number
Friction of surface equals 10;
<BR>> ><-- some random number beginning
of a loop { time advances by 50
<BR>years;
<BR>> >engineers reduce friction of surface by a factor of ten so
new Friction of
<BR>> >surface now equals old Friction of surface divided by 10;
Tell me what the
<BR>> >new Friction of surface is; } end of loop...repeat loop only
until Friction
<BR>> >of surface equals 0 then stop;
Tell me how many years have passed;
<BR>>
<BR>> Wrong stopping condition. Tell me; when friction is small enough
that
<BR>> per-bit losses are less than 1/2^256 of an erg. At that point,
you'll
<BR>> be able to count to 2^256 at a total cost of less than an erg of
energy.
<BR>[snip approx answer]
<BR>>
<BR>> -kitten
<P>I almost concur, except that the limit of one erg is unnecessary.
So long as
<BR>you can, at least, count up to 2^256 with some x number of available
ergs of
<BR>energy, which is likely greater than just one erg. So let's assume
we've got
<BR>a whole bunch'a ergs to use. What sounds good to you? We'll
go with 10^60
<BR>ergs just sitting in our energy bank; is that enough? I know
... I know ..
<BR>you're thinking, "Hey, that's more energy than the Sun will release
before it
<BR>goes nova [not counting the supernova itself]." .. or maybe "Wait!
There
<BR>aren't even 10^60 atoms in this solar system - maybe we shouldn't have
10^60
<BR>ergs?" But, don't worry about those piddly little details, just
humor me.
<BR>We know that the energy of a state change is greater than or equal
to
<BR>1.38e(-16) * TempOfUniv.</BLOCKQUOTE>
How did you derive this? In particular, what definition of "state
change" are you using?
<BLOCKQUOTE TYPE=CITE>We've got 10^60 ergs to spare and we want to run
<BR>something through 10^77 (2^256) state changes. So, we're looking
for an
<BR>energy-per-state-change of (10^60 / 10^77) = 10^(-17). Let's
plug that into
<BR>our equation. 10^(-17) >= 1.38e(-16) * TempOfUniv. So,
TempOfUniv <=
<BR>10^(-17) / 1.38*10^(-16). T comes out to ... hmmm, let's see
... less than
<BR>or equal to ~10^(-1) K. The average temparature of the universe
during our
<BR>computer's counting has to be at most 0.1 Kelvin. Oh darn, the
temperature
<BR>of the universe exceeds that by an appreciable amount right now.
Guess we'll
<BR>have to wait and see if this universe is open (i.e. no Big Crunch)
and then
<BR>maybe in a gazillion years or so, we'll be able to make those 2^256
state
<BR>changes. We'll find out, at the longest, whether this universe
is open or
<BR>closed in 10 billion years, but making 2^256 state changes now would
cost
<BR>~10^61 ergs, which exceeds our original (very generous) allotment.
<P> ___/Mike ...two legs good, four legs bad? ... Why
conform?
<BR>__/. | For my next trick,
WATCH as this humble mouse breaks
<BR>\-__ \___ Windows at the mere press of a button.
<BR> \
Hey! Where are we going, and why am I in this handbasket?
<P>-----------== Posted via Deja News, The Discussion Network ==----------
<BR><A
HREF="http://www.dejanews.com/">http://www.dejanews.com/</A>
Search, Read, Discuss, or Start Your Own</BLOCKQUOTE>
</HTML>
------------------------------
** 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
******************************
