Cryptography-Digest Digest #863, Volume #9 Sat, 10 Jul 99 19:13:03 EDT
Contents:
Re: How strong would this algorithm be ? ("Daniel Urquhart")
Re: How strong would this algorithm be ? ([EMAIL PROTECTED])
Re: The Iraqi Block Cipher ([EMAIL PROTECTED])
Can Anyone Crack The Zip Password In (The BusMan)
Short Key and Short Data -- XOR ??? (Randy Given)
Re: How strong would this algorithm be ? ([EMAIL PROTECTED])
New encryption methods ("User")
Re: The Iraqi Block Cipher
Re: Shamir�s no-key protocol
Re: The Iraqi Block Cipher
Re: Properties of Chain Addition?
How Big is a Byte? (was: New Encryption Product!)
Re: Is it possible to combine brute-force and ciphertext-only in an
Re: Stream Cipher != PRNG
Re: How strong would this algorithm be ? ("Daniel Urquhart")
Re: New encryption methods (NFN NMI L.)
----------------------------------------------------------------------------
From: "Daniel Urquhart" <[EMAIL PROTECTED]>
Subject: Re: How strong would this algorithm be ?
Date: Sat, 10 Jul 1999 10:34:10 -0700
> In particular, when a few dozen times 256*lcm(KeyLen,256) bytes of
ciphertext
> are accumulated, KeyLen can be deduced by the Kasiski test, then the
stream
> divided up into a large number of parallel streams, each of which is a
simple
> substitution solvable by frequency analysis. Note that this is a
ciphertext
> only attack, and once the necessary volume of material has been
accumulated
> the computing power to process it is not very great. Typically somewhere
> around 10 MB of ciphertext would be required, but powers-of-two keylengths
are
> weaker than composite even keylengths, which are weaker than odd
keylengths. A
> power-of-two keylength reduces the ciphertext requirement to about 1 MB.
Thus by allowing very long keys (as much as you have memory for) a
reasonable ammount of security may be obtained ?
> Unlike simply xoring with a CSPRNG (eg RC4), it is possible to reuse keys
with
> this cipher; however doing so reduces the amount of material required to
carry
> out the ciphertext-only attack to a few thousand messages, regardless of
> message length.
So randomy generating a # wich is stored, unencrypted in the file, and XOR
it with the key before encryption would improve this alorithm for the
encryption of multiple smaler files ?
> >Would this essentially have to be cracked using brute-force, or does this
> >have some inherent flaw.
>
> No, it is considerably weaker than bruteforce.
Thanks for the info !!!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How strong would this algorithm be ?
Date: Sat, 10 Jul 1999 17:50:59 GMT
In article <avKh3.26$[EMAIL PROTECTED]>,
"Daniel Urquhart" <[EMAIL PROTECTED]> wrote:
> allocate table [keylen-2][256]
are we talking about bytes or what? Is keylen fixed? Is there a
minimum, is there a max. Maybe the table should be fixed in size.
> for i = 0 to keylen-2 /* Non inclusive */
>
> /* This is actually a seperate function*/
> t1 = key[i]
> t2 = key[i+1]
> t3 = key[i+2]
>
> for j = 0 to 256
>
> table[i][j] = ( t1 + t2 ) XOR t3
> t1 = t2;
> t2 = table[i][j];
> /* Add 2 previous numbers then XOR to get next */
>
> next j
> next i
Is this suppose to be a RNG? You should examine the period. Basically
you are doing this
a <- (t1 + t2) ^ t3
t1 <- t2
t2 <- a
but why doesn't t3 change? This is a 2 element lagged fibonacci
generator with a period of (3)(2^(w-1)) w = word size in bits. For 8
bits you can make (3)(128) or 384 elements before repeating. This
seems to be quite short. If your table is larger then this it will
fall to a divide and conquer type attack. If t3 changed (i.e time
based) you could make the period better. What I suggest is to find
some other intractable key schedule. You should use fixed size tables
but their is no rule.
Also with the lsb of a there is a linear equation (t1 ^ t2 ^ t3) which
will hold with prob of 1 for all elements of the table. Since t3 is
fixed for all elements you can perform
a ^ a' = (t1 + t2) ^ (t1' + t2')
And if you get some of the values you can guess at the generator. I
don't know if the attack will be usefull but it is an attack. It would
work with a chosen plaintext attack (which this cipher seems to be
vulnerable to since the ciphertext is used as a feedback...)
> /* now encode the data, decryption is nearly identical*/
> out[0] = in[0] XORtable[0][0]
> for i = 0 to datalen
> /* I can't seem to get fmod to work, and I just finished G10 math
(I'm in
> highschool) so lets say that
> rem(X,Y) gives the remainder of X/Y (i use a more confusing method,
though
> it works */
>
> out[i] = table[ rem(i,keylen-2) ][ out[i-1] ]
>
> next i
You use the previous ciphetext as a parameter right? This will be
vunlernable to a chosen plaintext attack then. Where does the new
plaintext plug in though? Is it just
for i = 0 to size
out[i] = in[i] xor table[?][?]
next i
What is 'rem(i,keylen-2)'?
> my program then writes over the existing file.
> Well that should cover it.
That's of little concern.
Hmm well I mangaged to analyze some of it. Could you explain the
encrypt/decrypt process better?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Iraqi Block Cipher
Date: Sat, 10 Jul 1999 17:56:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Quite possible, then Western compilers will produce incorrect
> executables, attempts to break the cipher will be proclaimed
> not worth effort and the cipher itself "not serious".
>
> Any knowledge about the compilers with 16-bit "char" type?
Well unicode in WATCOM and MSVC is supported. I believe C-86 supported
it as well (in some form).
Although this is OT, I think char should always be 8-bits since it will
allow the programmer to optimize the code (i.e pentiums handle byte
arithmetic fine, but 16-bit bad!)... Of course ANSI dudes will always
argue this (somehow having fixed size types is bad?) so let's not argue
this...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: The BusMan <[EMAIL PROTECTED]>
Subject: Can Anyone Crack The Zip Password In
Date: Mon, 05 Jul 1999 07:30:08 GMT
The file EntryPro.Zip? "EntryPro 2.06" Look I won't bullshit
you I'm very new to this! I've been tyring to break this thing
for 41 days, with some luck, I found out that if I put "%l%"
for a password it will start to decommpress but mid way I
get an "BAD CRC" error, and it either unloads 1/4 the file
size or "0" the file size. This is as far as I can go with
what little Skills I have... Please If there is someone out
there who can help me solve this... You will have FRIEND for
LIFE!!! Thank-You for hearing me out!
The BusMan
05July1999
12:25 a.m.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Randy Given)
Subject: Short Key and Short Data -- XOR ???
Date: 10 Jul 1999 19:23:55 GMT
I have a short set of data (4 to 6 bytes) that I need
to encrypt symmetrically using a short key (2 to 8 bytes).
Is there anything better than XOR for this small of a
data set?
Randy Given
[EMAIL PROTECTED]
http://members.aol.com/GivenRandy
public key at http://members.aol.com/GivenRandy/pgpkey.asc
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How strong would this algorithm be ?
Date: Sat, 10 Jul 1999 19:46:09 GMT
> Thus by allowing very long keys (as much as you have memory for) a
> reasonable ammount of security may be obtained ?
You are talking about a OTP which you did not invent.
Try to design algorithms with keys that are in the 128 <> 1024 bit
range. In stream ciphers (like yours) normally this is called the
state or starting time (the key). The key would be the starting state
of a PRNG or similer. In RC4 though their is a key schedule so the key
is not used literally as the PRNG state. In SEAL they use some tables
which use internal time-, key- dependant registers.
Also define reasonable. Is that brute force? Is that less then brute
force but at N known plaintexts? Is that ... Normally there is a
medium. For example all AES ciphers can be broken with 2^128 chosen
plaintext regardless of the key size, however this is considered
acceptable (it should be) for it's use.
> So randomy generating a # wich is stored, unencrypted in the file,
and XOR
> it with the key before encryption would improve this alorithm for the
> encryption of multiple smaler files ?
What? If you have
out[i] = in[i] xor key[i] xor state[i][out[i-1]]
which I think you are taling about. This is linear and can be solved.
It would prove as somewhat difficult to start but with chosen/known
plaintext it probably could be mounted with less then 2^20 depending on
the state size.
Don't forget that a divide and conquer attack could probably take over
this quite easily...
> > >Would this essentially have to be cracked using brute-force, or
does this
> > >have some inherent flaw.
> >
> > No, it is considerably weaker than bruteforce.
>
> Thanks for the info !!!
Did you get my other post? I noted the key schedule and some other
facts...
I think you should re-think what you are trying todo. Try looking at
other stream ciphers like RC4 and SEAL to see how they work. SEAL
might be along your lines of though. What they did is made a PRF which
can 'stretch' a value into an arbitrary length PRN output. RC4 is more
like a pseudo-OTP using a PRNG and xoring it directly with the
plaintext...
I also have some examples in my C++ code. Notably DDARNG. I dunno if
it's 'secure' but it's an interesting idea. I would also research
Algorithm M which is somewhat related to your idea.
Just try looking around. I wouldn't make claims unless you have
reasons. And remember that no cipher is immune to attack just
intractable (to some degree). So don't make claims like 'it's
unbreakable' because you will be wrong.
Happy coding and good luck !
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "User" <[EMAIL PROTECTED]>
Subject: New encryption methods
Date: Sat, 10 Jul 1999 14:24:18 -0700
Base 1000000000: 1 has 1 digit
Base 64: XCIE0 has 5 digits
Base 40: 9up000 has 6 digits
Base 30: 1b4h13a has 7 digits
Base 25: 42a0000 has 7 digits
Base 20: fca0000 has 7 digits
Base 19: 124g6g1i has 7 digits
Base 18: 1b73hdda has 8 digits
Base 17: 27750aa7 has 8 digits
Base 16: 3b9aca00 has 8 digits
Base 15: 5cbd146a has 8 digits
Base 14: 96b4b6b6 has 8 digits
Base 13: 12c23a19c has 9 digits
Base 12: 23aa93854 has 9 digits
Base 11: 47352388a has 9 digits
Base 10: 1000000000 has 10 digits
Base 9: 2520607101 has 10 digits
Base 8: 7346545000 has 10 digits
Base 7: 33531600616 has 11 digits
Base 6: 243121245344 has 12 digits
Base 5: 4022000000000 has 13 digits
Base 4: 323212230220000 has 15 digits
Base 3: 2120200200021010001 has 19 digits
Base 2: 111011100110101100101000000000 has 30 digits
Base 1: INFINITE digits!!! (haha)
Note that for this example, its a tradeoff between base (number of symbols
per digit) and length (number of digits).
To represent 1000000000 in base 1000000000 requires only 1 digit
To represent 1000000000 in base 10 requires 10 digits
To represent 1000000000 in base 2 requires 30 digits
Somewhere inbetween those values is a good match for compressing
numbers, letters, or anything (even 256 bit/color pixels)
Since most encryption schemes nowadays are limited by the byte
(represents 0-256), would it be possible to create a new encryption
standard based on a different "base"?
And does making the "base" of the encrypted text unknown
to the cracker make it more secure?
The person trying to crack it now also have to take into consideration
what base it is in (which can be anything!!!)
For those interested in how I calculated those numbers...
Virtual Calc 99 (free download!)
The only calculator in the world that supports unconstrained bases
and calculates to infinite precision!
http://www.edepot.com/phl.html
Runs on Windows 95/98/NT
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: The Iraqi Block Cipher
Date: 10 Jul 99 21:33:03 GMT
Boris Kazak ([EMAIL PROTECTED]) wrote:
: .......... it really does not seem to be serious. Will anybody
: care to explain what sense does it make to apply %256 to
: "unsigned char"?
Maybe the Iraqis use Unicode. However, I think we can take it as pretty
obvious that this is an anonymous effort from some U.S. hacker.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Shamir�s no-key protocol
Date: 10 Jul 99 21:29:45 GMT
Georg Zetzsche ([EMAIL PROTECTED]) wrote:
: Can ynobody tell me how you get the number a�(the key that is used
: to decrypt the second message)
: from a (the secret key from the first message) in shamir�s no-key protocol ?
The Shamir three-pass protocol goes like this:
Two parties agree on a prime, M.
The secret message, x, is encrypted by the first party by raising it to
the power a.
x^a is sent to the second party.
The second party then encrypts it by raising it to the power b.
x^(a+b) is sent to the first party.
The first party takes the a-th root by raising it to the power that does
that - so, the answer to your question is that the same method is used to
find that number as is used to find d from e knowing the factorization of
the modulus in RSA, except here it's simpler, since the modulus is only a
single prime. M-1 is the Euler totient function...
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: The Iraqi Block Cipher
Date: 10 Jul 99 21:35:22 GMT
Boris Kazak ([EMAIL PROTECTED]) wrote:
: Any knowledge about the compilers with 16-bit "char" type?
Although there are C compilers with 16-bit characters, they use a special
long character type, not char. However, Java uses 16-bit characters as its
only character type. (And 9-bit bytes...)
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: sci.math
Subject: Re: Properties of Chain Addition?
Date: 10 Jul 99 22:00:32 GMT
[EMAIL PROTECTED] wrote:
: Thanks for the link. BTW what do you think I meant by 'Additive
: Generator' ? It's well described in AC, which is where I learnt about
: them.
: I have a few Additive Generators in my C++ code. If you want to peak.
Well, I remember you mentioned that you had C code for such generators,
but I wasn't looking for that; I was looking for math references that
would tell me stuff about the period and so on.
The requirement, no doubt, is simply that the feedback arrangement be a
primitive polynomial mod n, but I was hoping that the polynomial x^n+x+1
might be a special case that is particularly likely to be primitive.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: alt.folklore.computers
Subject: How Big is a Byte? (was: New Encryption Product!)
Date: 10 Jul 99 21:46:05 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: It would have been funnier if it were right. A byte need not have
: exactly 8 bits, although that is such a common misconception that
: it is used in labeling disk drives, etc. That's why in technical
: work, such as Internet packet specifications, we prefer the term
: "octet" when we mean precisely 8 bits.
That reminds me of a letter to Byte magazine, wherein a reader protested
that the use of the term "byte" to describe a storage unit containing 8
bits was _incorrect_, because the "official" definition of a byte was
something that could take between 64 and 100 values.
Of course, that fellow had been reading the definition of "byte" found in
Donald E. Knuth's description of the MIX computer, not realizing that it
was not intended as a general definition of the term.
However, AFAIK, that is the *only* place the term byte has ever been used
to describe anything other than an (ahem) octet, and it is arguably
incorrect (the proper term would be "character", which indeed could be 6
bits, 8 bits, 16 bits, two digits, or whatever on different computers) as
the term byte was coined and defined, with a definition that made no
provision for the term referring to any other quantity of storage...
in "System/360 Principles of Operation".
However, I have heard that the term "byte" may have been used earlier than
this - again to designate 8 bits of storage - in the manuals for the
STRETCH computer.
Thus, I'm not sure that the common definition of a byte, as 8 bits the way
a foot is 12 inches, is necessarily wrong. But I do have to admit that
some authorities could argue it the other way: since "byte" belonged to a
family of terms including "halfword" and "word", and since not all
computers have a word length of 32 bits, by implication a byte is also a
flexible unit.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: 10 Jul 99 22:04:24 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: John Savard wrote:
: > If one's plaintext were so well compressed as to be indistinguishable
: > from random data, it would not be possible to be confident of any
: > decipherment.
: That would require that *any* random ciphertext decode to meaningful
: plaintext, with relative likelihoods identical to one's a priori
: estimates of message probabilities. No compression scheme in common
: use comes anywhere close to that.
: If the attacker knows (or can guess) the decompression algorithm,
: then that can be used in a brute-force attack (it just adds one
: more step in the test for plaintext).
Yes, I'm well aware this is only a theoretical limitation. One could be
sending data that actually *is* random, but then, it would be for some
sort of future use (i.e. as an additive key) which would allow brute-force
attacks involving two intercepted ciphertexts.
But in theory - and the fellow did claim the data was random - this, like
the one-time-pad, is a fundamental information-theoretic limitation of
cryptanalysis. No redundancy, no unique solution.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Stream Cipher != PRNG
Date: 10 Jul 99 21:55:32 GMT
[EMAIL PROTECTED] wrote:
: All of these are time dependant permutations. They are based on the
: time stepping of a PRNG. You have not proved or provided hints towards
: stream cipher != PRNG.
Yes, I have. You haven't been paying attention.
If the stream cipher involves a complicated rule for producing a
permutation from PRNG output, then the PRNG alone is not the stream
cipher. The rule for producing the permutation, called the "combiner", is
also part of the stream cipher - and in this case, it is NOT just an XOR
of the PRNG output any more!
If you don't know that the rule is S3( PRNG[8..15] xor S2( PRNG[0..7] +
S3( plain ) ) ), and all you have is the PRNG, you can't do the stream
cipher.
I don't know how to make it any clearer than this. Yes, stream ciphers
generally *are* built with PRNGs. Now, there IS a completely different
kind, the self-synchronizing stream cipher (to encipher character n,
encrypt the eight preceding ciphertext characters with DES, and use the
64-bit output to encrypt that character) which could be viewed as a block
cipher mode, and doesn't even use a counter - there's only a block cipher
and no PRNG at all.
Basically: Stream cipher =(usually) PRNG + combiner != just the PRNG.
Where the combiner is just an XOR, the stream cipher and the PRNG are
close enough to being the same that they can be confused. Where the
combiner has some complexity of its own, the two are not the same. And
stream ciphers can be of the autokey type, such as the self-synchronizing
stream cipher, and in that case the PRNG isn't even present.
John Savard
------------------------------
From: "Daniel Urquhart" <[EMAIL PROTECTED]>
Subject: Re: How strong would this algorithm be ?
Date: Sat, 10 Jul 1999 16:02:43 -0700
> > allocate table [keylen-2][256]
>
> are we talking about bytes or what? Is keylen fixed? Is there a
> minimum, is there a max. Maybe the table should be fixed in size.
>
we are talking about bytes. keylen is NOT fixed, and limited only memory
(the computers and yours)
> > for i = 0 to keylen-2 /* Non inclusive */
> >
> > /* This is actually a seperate function*/
> > t1 = key[i]
> > t2 = key[i+1]
> > t3 = key[i+2]
> >
> > for j = 0 to 256
> >
> > table[i][j] = ( t1 + t2 ) XOR t3
> > t1 = t2;
> > t2 = table[i][j];
> > /* Add 2 previous numbers then XOR to get next */
> >
> > next j
> > next i
>
> Is this suppose to be a RNG? You should examine the period. Basically
> you are doing this
>
> a <- (t1 + t2) ^ t3
> t1 <- t2
> t2 <- a
>
> but why doesn't t3 change? This is a 2 element lagged fibonacci
> generator with a period of (3)(2^(w-1)) w = word size in bits. For 8
> bits you can make (3)(128) or 384 elements before repeating. This
> seems to be quite short. If your table is larger then this it will
> fall to a divide and conquer type attack. If t3 changed (i.e time
> based) you could make the period better. What I suggest is to find
> some other intractable key schedule. You should use fixed size tables
> but their is no rule.
This is seeded with bytes but the variables (t1,t2) are DWords. Also, this
is called once for every set of 3 consecutive bytes in the key (keylen -2)
and only has to generate 256 random values each time.
> Also with the lsb of a there is a linear equation (t1 ^ t2 ^ t3) which
> will hold with prob of 1 for all elements of the table. Since t3 is
> fixed for all elements you can perform
>
> a ^ a' = (t1 + t2) ^ (t1' + t2')
>
> And if you get some of the values you can guess at the generator. I
> don't know if the attack will be usefull but it is an attack. It would
> work with a chosen plaintext attack (which this cipher seems to be
> vulnerable to since the ciphertext is used as a feedback...)
Even though I have allmost no experiance I did guess that this may be the
case. The biggest whole, as I see it is that if one has the cipher text &
plaintext, one immeadeately knows what the first 'random' number as, this
would make if very easy to find a set of canates for the first 3 bytes of
the key.
> > /* now encode the data, decryption is nearly identical*/
> > out[0] = in[0] XORtable[0][0]
> > for i = 0 to datalen
> > /* I can't seem to get fmod to work, and I just finished G10 math
> (I'm in
> > highschool) so lets say that
> > rem(X,Y) gives the remainder of X/Y (i use a more confusing method,
> though
> > it works */
> >
> > out[i] = table[ rem(i,keylen-2) ][ out[i-1] ]
I meant: out[i] = table[ rem(i,keylen-2) ][ out[i-1] ] XOR in[i]
> > next i
>
> You use the previous ciphetext as a parameter right? This will be
> vunlernable to a chosen plaintext attack then. Where does the new
> plaintext plug in though? Is it just
>
> for i = 0 to size
> out[i] = in[i] xor table[?][?]
> next i
>
> What is 'rem(i,keylen-2)'?
I explaned this in the comments rem(x,y) gives the remainder of X/Y. I know
that this is not standard notaion, but I just finished grade 10. . .
> Hmm well I mangaged to analyze some of it. Could you explain the
> encrypt/decrypt process better?
Once again, thanks for the help.
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: New encryption methods
Date: 10 Jul 1999 22:44:01 GMT
So you are trying to represent 1,000,000,000 (one billion) in different bases?
<<Base 1000000000: 1 has 1 digit>>
Sorry. 1 means 1. 10 would be a billion in base-billion. Bzzzt!
<<Base 1: INFINITE digits!!! (haha)>>
Sorry! Base-1 is the tally system. 137 is 137 digits in base-1. Beware kookery.
Moo-Cow-ID: 7 Moo-Cow-Message: The
-*---*-------
S.T.L. (NFN NMI L. also) -===> [EMAIL PROTECTED] <===- 2^6972593 - 1 IS PRIME!
Quotations: http://quote.cjb.net Main site: http://137.tsx.org F00FC7C8 MOO!
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!" e^(i*Pi)+1=0 Mail block
is gone, but will return if I'm bombed again. It was an easy fix. Address is
correct as-is. Giving the correct address is COURTEOUS; junk gets in anyway.
Join the Great Internet Mersenne Prime Search at http://entropia.com/ips/ My
.sig is even shorter, and contains 3046 bits of entropy including next line:
-*---*-------
Card-holding member of the Dark Legion of Cantorians, People for the Ethical
Treatment of Digital Tierran Organisms, the Holy Order of the Catenary, the
Great SRian Conspiracy, the Triple-Sigma Club, the Polycarbonate Syndicate,
the Union of Quantum Mechanics, the Roll-Your-Own Crypto Alliance, and the
Organization for the Advocation of Two-Letter Acronyms (OATLA)
Avid watcher of "World's Most Terrifying Causality Violations", "When Kaons
Decay: World's Most Amazing CP Symmetry Breaking Caught On [Magnetic] Tape",
"World's Scariest Warp Accidents", "When Renormalization Fails", "World's
Most Energetic Cosmic Rays", and "When Tidal Forces Attack: Caught on Tape"
Patiently awaiting the launch of Gravity Probe B and the discovery of M39
Physics Commandment #16: Eight Types Of Gluons Exist.
------------------------------
** 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
******************************
