Cryptography-Digest Digest #722, Volume #12 Wed, 20 Sep 00 03:13:00 EDT
Contents:
Re: RSA Questions (Bryan Olson)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (John Savard)
Re: Kryptcon ("David Thompson")
Re: Hamming weight (Mack)
Hardware RNGs (Mark Carroll)
Re: Intel's 1.13 MHZ chip ("Douglas A. Gwyn")
Re: Dangers of using same public key for encryption and signatures? (Bryan Olson)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an ("Douglas A.
Gwyn")
Re: CDMA tracking (was Re: GSM tracking) (Mack)
Re: Q: Crypto-PC ("Douglas A. Gwyn")
Re: CDMA tracking (was Re: GSM tracking) (Roger Schlafly)
Re: Hardware RNGs (Paul Rubin)
Re: Algebra, or are all block ciphers in trouble? ("Douglas A. Gwyn")
Re: Hardware RNGs ("Douglas A. Gwyn")
Re: Algebra, or are all block ciphers in trouble? (Mack)
revised code for brute forcing RC4 ([EMAIL PROTECTED])
Re: Figures of Merit for Crypto=Systems (Mack)
Re: Double Encryption Illegal? (Paul Schlyter)
Re: transformation completeness and avalanche effect (Mack)
Re: Intel's 1.13 MHZ chip (Jerry Coffin)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: RSA Questions
Date: Wed, 20 Sep 2000 02:56:01 GMT
Ed Pugh wrote:
> Bryan Olson writes:
> >
> > The modulus must be the product of distinct primes for
> > encryption to be invertible.
> But that is not quite true.
[...]
> Don't forget that, if N
> is not "square free", then the message encrypted with e and N must
> be coprime to N.
That's what makes encryption non-invertible for N
that isn't square free. Well, actually there exist
messages that are not relatively prime to
non-square-free N that will still encrypt and decrypt
correctly. The point is that if N is not square free
the encryption function [0..N-1] -> [0..N-1] has no
inverse.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption
Date: Wed, 20 Sep 2000 02:59:38 GMT
On Tue, 19 Sep 2000 18:16:36 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>On Tue, 19 Sep 2000 14:57:01 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (John Savard) wrote:
>>[...]
>>The specific type of polymorphism in Konstantin Bajalcaliev's designs,
>>though, as you can see from looking at Quadibloc II and the others of
>>my designs which use it, was basically added almost as an
>>afterthought, which is why it is present only in such a rudimentary
>>form.
>I have looked, but end up more confused than when I started: Exactly
>what is it about this "specific type of polymorphism" which
>distinguishes from prior work? What is the process at issue:
>combining, mixing, what? Are we talking streams or blocks or what?
Very specifically, what I did and what Mr. Bajalcaliev anticipated me
in doing, is this:
in a block cipher particularly, but the concept also applies to stream
ciphers,
based on information dependent on the input plaintext or ciphertext
block,
select a different _operation_ (addition, XOR, multiplication) to
perform at some stage in the block cipher.
IDEA used different operations, and so did SAFER, but in a fixed
structure.
Some of your designs go one better: not only do you choose an
operation depending on the key, but you make a _general_ choice, by
choosing between Latin squares, so you have improved on simply
switching between addition and XOR based on the key in that way.
I can't, offhand, think of a specific example of that which predates
Mr. Bajalcaliev, although I agree with your confusion in the sense
that, since it _is_ a simple and obvious principle, it probably was
used by many people long ago.
>>My suspicion is that polymorphism has been around a long time, but
>>mostly in amateur designs.
>Exactly how is a cipher distinguished as being an "amateur design"?
>I claim that any such concept is fundamentally unscientific: A design
>is what it is, and not who did it. It can only matter who did it if
>we have no idea how to evaluate the result. And if we don't, then,
>realistically, those doing it probably don't either.
In this case, I used the phrase 'amateur design' to mean exactly what
it says: a design that was not created in the course of either
employment or academic research. More specifically: I was not saying
that that principle was mostly used in ciphers that were insecure, but
that it was mostly used in ciphers that I was less likely to have
heard of.
Of course, this reminds me, in thinking of the concept of 'amateur' as
being unscientific: in an athletic contest for the championship of a
small town, it is less likely that the deciding margin will be less
than 1/100 of a second.
Despite the fact, therefore, that the athletes are all there
voluntarily, and, indeed, enthusiastically, instead of just worrying
about steroids, perhaps the Olympics should be banned on grounds of
cruelty to humans. :)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Kryptcon
Date: Wed, 20 Sep 2000 04:27:28 GMT
Runu Knips <[EMAIL PROTECTED]> wrote :
...
> Just look at your code. Don't you see those
> masses of errors ? In the key expansion, you
> never test if the string length is less than
> 2 (which would cause an underflow).
Concur, although arguably any user who gives
a 1-character key to an encryption program,
even one this lame, deserves what they get.
> You take
> the string length of your key schedule, but
> there is no guarantee that there is actually
> a zero byte. Too, the length of your key
> schedule is 512, NOT strlen(key).
>
Well, there is guaranteed to be a zero byte,
because he set only elements 0..511 of a
static-duration (zero-initialized) char [513].
But there is quite likely to be a zero byte
*before* the end of the (intended) key schedule.
And in addition to the other comments already made
about pow (for squaring),
> for(1; u <=511; 1) {
is just silly. Use for(; u<=511;) or while(u<=511)
or the more idiomatic while(u<512). Or just do:
for(u=strlen(key); u<512; ++u) key[u] = whatever;
Further, on implementations where plain char is signed,
storing out of range values is not guaranteed to work,
although on mainstream platforms it does.
But even a good implementation of a bad algorithm
is still an implementation of a bad algorithm.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 20 Sep 2000 04:32:48 GMT
Subject: Re: Hamming weight
>
>On 19 Sep 2000 03:38:47 GMT, in
><[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] (Mack) wrote:
>
>>>
>>>On Mon, 18 Sep 2000 14:38:36 +0200, in
>>><8q51uh$kea$[EMAIL PROTECTED]>, in sci.crypt "kihdip"
>>><[EMAIL PROTECTED]> wrote:
>>>
>>>>Does anybody have an exact definition of 'Hamming weight' ??
>>>>(and knowledge of what 'unit' to use - do you say 0,5 ; 50% or something
>>>>else ??)
>>>
>>>See, for example:
>>>
>>> http://www.io.com/~ritter/GLOSSARY.HTM#HammingDistance
>>>
>>
>>A good definition for base two. But Hamming weight is also
>>applicable to other bases. "The Theory of Error-Correcting Codes"
>>by MacWilliams and Sloane defines the Hamming Weight as
>>the number of non-zero entries in the numeric string and
>>the Hamming Distance as the number of places where they
>>differ or alternately the hamming weight of subtracting one string
>>from the other without carry.
>
>I don't have MacWilliams and Sloane, but both Clark and Cain and
>Blahut do say something like "the number of nonzero elements in a
>[code] word." Berlekamp is more precise. However, I'm not sure I
>have ever seen the distinction used in practice.
>
It is used in coding theory. When dealing with other bases, it
is helpful. I didn't run across it until I started researching
MDS codes.
>Upon opening that door, we would also have to address Lee weight.
>
>If you have a list of things you would like to see improved in the
>Glossary, now would be a good time to present it.
>
I will take a look the Glossary is fairly large and I have a project with
a sept. 29th due date.
>---
>Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
>Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mark Carroll)
Subject: Hardware RNGs
Date: 20 Sep 2000 04:56:46 GMT
Can anyone recommend any relatively cheap RNG cards for Intel boxes?
I'd like really good random numbers, so I figured that if they'd
satisfy you guys they'd satisfy anyone. (-: I'm particularly
interested in ones that generate numbers based on some physical
stochastic phenomenon and where I can easily get a driver for Linux
that gives me access to raw data coming from the card, even if it's
meant to be 'preprocessed' for good randomness. So, a card that
insists on doing lots of on-board digital processing itself after the
'random physics' step is of less interest.
An obvious follow-up question regards any tips regarding easy-reading
sources of tests for randomness. I'm happy to do the actual coding
myself, but I would like to be able to try to test the card under
different conditions and satisfy myself with regard to the continuing
quality of its output.
-- Mark
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 20 Sep 2000 01:19:21 -0400
Jerry Coffin wrote:
> Wow! So now all false statements qualify as libel!
That of course is not what I said, if you bother to understand it.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Dangers of using same public key for encryption and signatures?
Date: Wed, 20 Sep 2000 05:07:08 GMT
Mike Rosing wrote:
> Bryan Olson wrote:
>
> > Can't an attacker generate all the plaintext-ciphertext
> > pairs he wants anyway?
>
> Not usually, because the attacker doesn't know the key.
The question is about a public-key system isn't it?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an
Date: Wed, 20 Sep 2000 01:21:19 -0400
Kostadin Bajalcaliev wrote:
> ... I citate [Aristotle] in order to show that there is always
> something behind, a substance of certain form, the smallest particle.
Citing Aristotle does not show any such thing.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: 20 Sep 2000 05:31:42 GMT
>I believe the aluminum briefcase is more than enough for a CDMA cellphone,
>due to the following reasons:
> 1. While off, the cellphone does not transmit -- it only receives. It
>will only transmit when told to do so, which requires the phone to receive
>that message from the network. The briefcase is enough to block phone
>reception from any cellular system.
> 2. Keep in mind that CDMA is based on spread-spectrum. This makes the
>actual power-per-frequency rating much lower than any other cellular system,
>and therefore the briefcase should not have any problem defeating the
>phone's transmission. The signal-to-noise level outside the briefcase would
>be so low that the original signal could never be reconstructed (or sensed,
>for that matter).
> 3. The aluminium briefcase is much bigger than the phone, and is
>therefore a sufficient ground space (compared to the phone's tiny ground
>space).
>
>
>Sagie.
>
I will test this ... since I don't have a small metal briefcase I will use a
small
safe and let you know how it turns out.
Tested with pager and cell phone. Both receive when in an ungrounded
metal safe. The pager recieved beeps. The cell phone maintained signal.
Since I don't have a way of testing the response when it is off I can't
judge that.
For a faraday cage to work properly it should be grounded
in one of the reference frames. ie. with respect to either the phone or the
cell tower but now that I think about it the charging plug would provide
an adequate ground with respect to the phone.
Now to figure out how to do that without shorting the phone out ....
Which one of those connectors is supposed to be ground?
>
>"H. Ellenberger" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Mack wrote:
>>
>> > >If you are concerned about your phone being
>> > >trackable when it is off, why not just put
>> > >it in an aluminum briefcase ?
>>
>> > Not terribly effective at attenuating signals.
>> > It must be properly grounded. The 50 foot of ground
>> > cable limits the effective range of the phone.
>>
>> Completely wrong, no ground cable is required.
>> If the metal briefcase should leak too much rf power,
>> just put it into a small and tight metallic box.
>>
>> HE
>>
>>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Crypto-PC
Date: Wed, 20 Sep 2000 01:33:13 -0400
Runu Knips wrote:
> David Hopwood wrote:
> > Since writing a truly secure operating system is beyond the current state
> > of the art ...
> I might be totally wrong, but AFAIK the most secure OS is OpenBSD ?
That's hilarious.
There have been some extremely secure (in some meaningful sense)
implementations of operating systems, and of course a system in
a vault with a single user and no connection to the outside is
inherently about as secure as they come. I've used such systems.
The biggest single problem with secure OSes is that they have
limited functionality (compared to wide-open ones) and evolve
very much slower than the rest of the world, so they become
obsolete and users turn to something else less secure.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: Tue, 19 Sep 2000 22:45:10 -0700
Jerry Coffin wrote:
> IIRC, it receives, but does not normally transmit.
Suppose I live in Calif, and I drive to Vegas and back with
my CDMA phone in the car. With live batteries but turned off
the entire time.
Is there any electronic evidence that I left Calif? You say
the phone doesn't transmit while off, but conceivably it
could keep a record of where I have been and report it the
next time the phone is turned on or there is a live connection.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: 19 Sep 2000 22:54:57 -0700
[EMAIL PROTECTED] (Mark Carroll) writes:
> Can anyone recommend any relatively cheap RNG cards for Intel boxes?
Isn't the Pentium III supposed to come with an RNG built into the chip set?
Failing that, I believe the Java iButton has an RNG available.
See http://www.ibutton.com/ibuttons/java.html.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Algebra, or are all block ciphers in trouble?
Date: Wed, 20 Sep 2000 01:58:20 -0400
[EMAIL PROTECTED] wrote:
> how to build the simple AND function
> by using only XOR and NOT ?
Oops, that generates a proper subalgebra, not the full Boolean
algebra.
My point was, there are many sets of operators that generate
the full algebra; it doesn't have to involve AND. But now that
we're looking at subalgebras, it should be clear that using a
suboptimal set of operators (e.g. XOR only, or XOR and NOT) one
cannot represent all possible functions. I guess that the
subalgebra spanned by (XOR,NOT) is what was meant by "linear"
in an earlier posting in this thread, but that is contrary to
the normal use of the term. (Or maybe it meant with no terms
higher than first order in the variables, but that wouldn't
represent any cipher worth using.) For GF(2) there are two
binary operators (XOR,AND), which is one of the sets that is
sufficient to represent any Boolean function. Indeed, there
are several "canonical" forms for such functions, explained in
logic-circuit-design textbooks.
The simple fact is that there is no easy way to solve a
general multivariate Boolean system. That's why it was a
valid research topic when I was working on it a couple of
years ago. There are all sorts of approaches one can try,
and I still have hopes that a substantial reduction of
resources (from a simple b.f. search of the full keyspace
using the full system) is possible, but as an unfunded project
it has been relegated to a back burner.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 20 Sep 2000 02:05:50 -0400
Paul Rubin wrote:
> Isn't the Pentium III supposed to come with an RNG built into the
> chip set?
Last I heard, it was in one of the support chips, not the processor.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Algebra, or are all block ciphers in trouble?
Date: 20 Sep 2000 06:03:27 GMT
>> >if you go writing boolean algebraic
>> >equation at BIT level, it can be demonstrated that
>> >ANY invertible f-function may be built-up by a proper
>> >composition of XOR and NOT function...
>Mack wrote:
>> No any invertible LINEAR function can be build using
>> only XOR, the variables and if nessessary the constant 1
>> NONLINEAR invertible functions require the AND operator.
>
Normal boolean algebra uses AND; OR and NOT
>*Any* Boolean pure function can be written in terms of just:
> NAND
>or
> NOR
NAND and NOR are certainly functions usable to generate
all possible functions.
>or
> IMPL and NOT
IMPL(a->b) has truth table
a=0011
b=0101
r=1101
which is ~(a&~b)
this is a simple function of AND
>or
> AND and NOT
since NAND is a function that will generate any boolean function
AND and NOT can also
the same is the case with NOR and OR/NOT
>or
> XOR and NOT
>etc. and the input variables.
But XOR/NOT does not form some functions
while XOR/AND/1 does form the set called ANF
example
the string
a=0011
b=0101
a^b=0110
1^a^b=1001
o=0001
note that if the one is grouped with a then it is
equivalent to NOT a as an input and similarly with
b. If a and b are grouped together then it is equivalent
to NOT (a^b) or complementing the output.
you simply can't produce my function o
no other combinations are possible
QED proof by counter example
>
>An interesting case is when just
> EQV
>is used; one gets a "subalgebra".
EQV = NOT(XOR(a,b))
>
>This was all thoroughly investigated by Polish logicians
>before WWII.
>
without using AND with XOR or XNOR(EQV) your can't
form all possible strings of outputs as the result of inputs.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED]
Subject: revised code for brute forcing RC4
Date: Wed, 20 Sep 2000 05:58:41 GMT
I revised my code for brute-forcing RC4,
http://www.burtleburtle.net/bob/c/brute.c
It doesn't brute-force the 40-bit keyspace, but the internal state of
RC4 itself. It only works on 4-bit RC4 and smaller. It wouldn't finish
in the lifetime of the universe on full scale RC4.
The old code took about 200 seconds (with gcc -O on a 166mhz Pentium) to
break 4-bit RC4. The new code takes about 36 seconds. The old code
would deduce values based on the known results and the
already-chosen values. So does the new code. Improvements:
* Instead of copying the internal state before recursively choosing a
new value, I roll back the previous changes. That brought it down to 90
seconds.
* The internal state is built by handling some contiguous set of
results. The new code can extend that set backwards or forwards.
Forwards was 90 seconds, backwards was about 60.
* The new code can start in the middle of the results and dynamically
grow the set of handled results either way, depending on which requires
the fewest guesses. That brought the time down to 20 to 50 seconds, 36
on average. gcc -O4 brought the 20 second case down to 15.
Could this break 5-bit RC4 in a reasonable amount of time? Dunno.
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Figures of Merit for Crypto=Systems
Date: 20 Sep 2000 06:23:03 GMT
>I wonder if some of the users of this excellent newsgroup could give me
>some help. I would like to have a list of figures of merit (FOM)for
>evaluating cryptosystems, To set the boundries of the problem I only
>want to consider systems useful for "average" PC's (1-200MHZ w/Windows
>95), with the system embodied as an MSDOS executable. I only want to
>consider the properties of the plaintext-cyphertext-plaintext algorithm.
>Other things like public/private keys,authorizations and signatures
>aside. As a base point consider a plaintext of 100 words. Here are some
>FOM's I have come up with:
I assume you mean secret key algorithms since you exclude
everything else.
>1. coding time/100 words
>2. decoding time /100 words
1 and 2 are normally very close to each other.
>3. ratio of cyphertext bytes/plaintext bytes (I have seen 30 bandied
>about)
3 is normally 1 for secret key ciphers
>4. Redundancy. In order to foil frequency analysis the same plaintext
>element (say the letter "e") should never be represented by a given
>cyphertext element more than once in a single message. How many
>representationsare needed? And in successive messages the set of
>cyphertext elements representing a given plaintext element should be
>different. how many sets?
>
Since in modern secret key algorithms the block size is fairly large
the problem of single letter mappings is generally avoided.
This can be a problem for certain formatted messages however
so the solution is usually to employ a chaining mode.
>What FOM's for these are state-of-the-art? What is considered adequete?
>What other FOM's are there?
resistance to differential and linear crytanalysis
resistance to related key attack
resistance to slide attacks
resistance to davies-murphies (sp?) attack.
resistance to impossible differential attack.
resistance to truncated differential attack.
>I am thinking of the simplest type of code, e.g. a list of numbers
>attached to an e-mail. One that an untrained, casual PC user can learn
>in just a few minutes. One suitable for a small business. PGP is too
>hard. I want to remind the experts reading this that their expertise was
>gained after much hard work. Few people are willing to invest such
>effort.
> Thanks for your help-dbf
>
The interface to PGP is less than ideal for a novice. I agree with that.
A simpler version
type mail hit send with automatic key generation on install
would be a good thing to have. Now that RSA patent has expired
most e-mail programs will probably implement a PGP compatible
version. Wait till after New Year's then see if I should take up
fortune telling.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Double Encryption Illegal?
Date: 20 Sep 2000 07:36:51 +0200
In article <[EMAIL PROTECTED]>,
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>
>> In article <[EMAIL PROTECTED]>,
>> wtshaw <[EMAIL PROTECTED]> wrote:
>>
>>> In article <8q1tfb$bj1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
>>> Schlyter) wrote:
>>>
>>>> In article <[EMAIL PROTECTED]>,
>>>> wtshaw <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> When a person uses 3-DES, they are single encrypting with 3-DES.
>>>>
>>>> FYI: 3-DES consists of three rounds of DES, using two or three
>>>> different keys.
>>>
>>> That is the definition of a newer algorithm than just plain DES. It
>>> is not DES.
>>
>> Well, if you consider any combination of crypto algorithm as "one
>> single, newer, algorithm", then there is of course no such thing
>> as "double encryption" or "triple encryption": you've just defined
>> it as non-existent....
>
> The opposing view point would be to consider DES as hexadectuple
> encryption. Or worse.
As you can see, either extremistic view will carry you astray. Quite
often the middle road is best.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: transformation completeness and avalanche effect
Date: 20 Sep 2000 06:29:41 GMT
>"Stanley" <[EMAIL PROTECTED]> writes:
>> Andru,
>>
>> Could you explain why DES encryption = T(p XOR k) and decryption=U(c) XOR
>k?
>
>T(x) = DES_ENCRYPT_WITH_ZERO_KEY(x)
>U(x) = DES_DECRYPT_WITH_ZERO_KEY(x)
>
>I was not proposing an attack on DES, I was using it to achieve
>defusion in a weak algorithm which has avalanch but still stinks.
>
To make it actually have good diffusion of key bits all so you can preprocess
the
key with either U(x) or T(x). (bad pun alert) This doesn't improve the security
one
bit (bad pun alert)
>Andru
>--
>Andru Luvisi, Programmer/Analyst
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Intel's 1.13 MHZ chip
Date: Wed, 20 Sep 2000 00:38:15 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Jerry Coffin wrote:
> > Wow! So now all false statements qualify as libel!
>
> That of course is not what I said, if you bother to understand it.
I notice you carefully did NOT quote what you said, to try to keep us
from noticing that in reality it's _exactly_ what you said.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
** 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
******************************
