Cryptography-Digest Digest #9, Volume #13 Thu, 26 Oct 00 19:13:00 EDT
Contents:
Re: Hardware RNGs (Bryan Olson)
Re: Q: Computations in a Galois Field ("Brian Gladman")
frequency analysis ("binary digit")
Re: On block encryption processing with intermediate permutations (James Felling)
Image on glasses of the cover guy in Secrets & Lies ("Jeff Moser")
Re: Is OPT the only encryption system that can be proved secure? (Terry Ritter)
Re: Q: Computations in a Galois Field (Terry Ritter)
Re: Collision domain in crypt()? ([EMAIL PROTECTED])
Re: Visual Basic ("Vic Drastik")
Re: Collision domain in crypt()? ([EMAIL PROTECTED])
Re: My comments on AES (Terry Ritter)
Re: My comments on AES (Terry Ritter)
Re: My comments on AES (John Myre)
Re: Rijndael and PGP (SCOTT19U.ZIP_GUY)
Re: How do I detect invalid passwords? (Tom St Denis)
Re: My comments on AES (SCOTT19U.ZIP_GUY)
IRC crypto (Modemac)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Thu, 26 Oct 2000 21:24:31 GMT
Tom St Denis wrote:
> The problem is that virtually of the lsb's on my comp are zeroes, with
> a few ones... In fact last time I counted the ratio was about 7 to 1.
> This means you need to gather about 100,000 bits before you can safely
> have about 160 bits (using SHA-1).
The raw sound data definitely needs to be condensed down.
> However, the problem gets
> worse...you must sample very slowly, otherwise the samples are
> correlated... Thus sample at about 8khz. At 8khz it will take 12.5
> seconds to gather enough inputs....
There's no reason to reduce the sampling rate. The
sub-sampled stream cannot contain more entropy than the
full stream. The correlation is no problem for SHA-1.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Thu, 26 Oct 2000 22:43:54 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8t9t5f$tf2$[EMAIL PROTECTED]...
> In article <8t9dui$pmb$[EMAIL PROTECTED]>,
> "kihdip" <[EMAIL PROTECTED]> wrote:
> > Twofish and Rijndael (among others) use computations in a Galois
> Field.
> >
> > Can any of you explain to me why the Galois Field is usefull.
> (Advantages)
> > Is it because of the modulus, so you'll never get more than 8 bits ??
> > Or because it eases decryptation ??
>
> Well for starters all galois field operations in GF(2)^n involve single
> bits (thus shifting/xors/ands, etc...) which makes them efficient on a
> a plethora of platforms.
>
> Second a multiply of two n-bit elements only needs an n-bit temporary
> variable whereas in GF(p) you need a log2(p^2) bit temp variable.
>
> Third inversion (and cubing) are highly usefull operations in GF(2)^n
> fields since they have low xor/linear biases.
>
> > Rijndael uses 11B and Twofish uses 169 - how do one choose the
> irreductable
> > polynomia ?? Are some better than others ??
>
> No polynomial is "better" then another. There are about 25 polynomials
> of nine bits (8-bit fields).
This depends on what you mean by 'better'.
Although there is a mathematical equivalence between different
representations of the same finite field, the efficiency achieved in an
implementation can be very dependent on which field elements are chosen and
the way they are represented. Both Rijndael and Twofish use field elements
and representations designed to make their field arithmetic efficient.
The forward transformation in Rijndael is very fast because, of the four
field element multipliers, two are unity, one has a single bit set and the
other has just two bits set - (0x02, 0x03, 0x01, 0x01) - only just over 1
bit per multiplier on average. The inverse transformation is much slower -
(0x0e, 0x0b, 0x0d, 0x09) - but still averages less than three bits set per
multiplier.
Brian Gladman
------------------------------
From: "binary digit" <[EMAIL PROTECTED]>
Subject: frequency analysis
Date: Thu, 26 Oct 2000 21:46:59 GMT
Anyone know of any programs out there that will try to do a frequency
analysis on a peice of enciphered text and it will output occording to the
amount of times a letter appears which letter is which?
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Thu, 26 Oct 2000 17:06:54 -0500
Mok-Kong Shen wrote:
> James Felling wrote:
> >
> > Bryan Olson wrote:
> >
> > > <snip an excellent attack vs. Mok's scheme>
> >
> > Mok:
> >
> > Now the only way I can see of this scheme working in an even remotely
> > plausible way is by seperating the mixing from the feistel. This is
> > only accomplishable if the feistel is unballanced, or in the case of a
> > balanced feistel, if the block is divided into an odd number of pieces
> > by the permuataion. Otherwise this attack applies, as one can always
> > find a set of properly formed blocks to peel off a 2 round pair.
> > Unfortunately most cyphers use block sizes that are power of two bits in
> > size. This will limit the aplicability of this method. In addition
> > such splitting will likely result in a substantial slowdown of the
> > cypher. OTOH, in these cases, this attack fails, and I have trouble
> > seeing an alternate line of attack. Brian?
>
> I have made some thoughts on the line which you wrote above
> but I am not sure/conclusive about my own answers since I
> am only starting to comprehend the nature of the ingenious
> attack devised by Bryan Olson and certainly yet lack deep
> understanding of it at the current moment. Supposing one
> has a 128 bit block DES-like cipher, my question is:
>
> Would the situation be different or at least essentially
> better in the following cases:
>
> (1) the permutation unit is in word size (32 bits).
Nope.
Assume an input of the form (a,b,c,d)
do a 1 block message and gather the 4^N possible 1 block messages
then do a 2 block message of the form (a,b,c,d,a,b,c,d) you will always have
the potential of the next to last round's out put being of the form
(m,n,o,p,m,n,o,p) which will lead you into a similar situation to the previous
case, as you then have a way of identifying "special pairs" -- sure this is
substantially more effort than the previous attack, but it is still probably
better than attacking it the cypher directly.
>
>
> (2) the permutation unit is in block size (128 bits).
Unless this permutation is somehow offset within the blocks this is no
different than directly permuting the output of the raw cypher( as every block
will have moved through as if it were independently encrypted. -- the input
into the 2 round feistel block will be the same as if it were just sitting
there, the only difference being that it is going to output at a different
location.
The best way to view it is that all the 2-round feistel sees is its input( the
block being processed, and its round keys) and it generates as output a block.
This means a block B may start as the first block, and get moved about the
message eventually arriving at its final position. This is (in theory) more
secure than the original, but if you can break the original code, the
transpostion step will also fall fairly easily- the problems are completely
orthogonal.
>
>
> (3) the permutation unit is in double block size (526 bits).
(I think you mean 256 bits) -- same as the above case. ( except you are doing
a 2 block permutation).
>
>
> I like to take this opportunity to thank you for a previous
> post that has helped me to understand certain points of
> Bryan Olson's attack.
>
Actually upon careful examination and an Ahh! moment any blocksize less than
the round size that divides blocks evenly will fall to this attack, as in all
cases you will have the potential for a "special form" input to the last round
leading to a recognisable pair. If the block is sliced fine enough you will
reach a point where this attack is effectively more work than it is worth( as
the time in selecting an apropriate block pair is sulficiently long that a
direct attack versus the system is actually time comprable to the special pair
selection process.) The other downside to this is that while searching for
special pairs is time consuming, it parallellizes very well.
M. K. Shen
> ----------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Image on glasses of the cover guy in Secrets & Lies
Date: Thu, 26 Oct 2000 17:04:25 -0500
I know it probably isn't worth too much to know, but what is the contents of
the screen that the guy is looking at on the cover of Secrets and Lies by
Schneier? It appears to be a Mac dialog with the options "OK", "CANCEL",
and another.. the first word of the dialog is "You".. but I cannot
distinguish much more.
Bruce, if you are reading this, do you know?
Just curious,
Jeff
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Thu, 26 Oct 2000 22:22:44 GMT
On Thu, 26 Oct 2000 12:18:07 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Wed, 25 Oct 2000 23:27:56 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>The mathematically-proven OTP depends upon various assumptions which
>>cannot be provably achieved in practice. And proof based on
>>unprovable assumptions is ultimately no proof at all.
>
>Although it is important to note that the OTP is subject to the
>bit-flipping attack, beyond this, I've tended to find this statement
>about the OTP as unhelpful, perhaps even annoying.
>
>But now I've finally figured out _why_ it bothers me.
>
>If we say that the OTP isn't "really" proven secure, because you can't
>prove that an eavesdropper hasn't somehow gotten hold of your key...
>
>then we _must_ say the same about all other cryptosystems.
What is *really* annoying here is how you misstate the argument: The
issue is *not* about "getting hold of a key." The issue is that the
OTP proof has implicit assumptions which easily can be overlooked.
And even if we don't miss the assumptions, we may be unable to achieve
them in practice. One such assumption is that the keying sequence is
unpredictably random. Unfortunately, even though theoretical
randomness is required, in practice, there is no way to prove that we
have it.
This is not about stealing the key; this is about using unexpected
characteristics of the generator to predict (some part of) the keying
sequence. That would be a successful attack, an OTP break. Some
would take such a break to mean that we did not have a "real" OTP in
the first place. Unfortunately, a "fake" OTP can look remarkably like
a "real" one according to all the tests we can perform.
This is also a lesson about hidden assumptions and mathematical
"proof" in cryptography: I'm not sure there even exists a good
technique for accumulating a comprehensive list of the hidden
assumptions upon which a "proof" depends. For example: Where in the
OTP proof do we find an explicit requirement for randomness, to say
nothing of a description of the difficulties one might have in
achieving that in practice? Without a comprehensive list of
assumptions, there seems little hope that we could *guarantee* that
*every* requirement is satisfied in practice, so that we could use the
results of a "proof."
Mathematical proofs concern models which may not, and probably do not,
exist in practice. It is important to keep the distinction in mind.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Q: Computations in a Galois Field
Date: Thu, 26 Oct 2000 22:20:34 GMT
On Thu, 26 Oct 2000 16:17:48 +0200, in
<8t9dui$pmb$[EMAIL PROTECTED]>, in sci.crypt "kihdip"
<[EMAIL PROTECTED]> wrote:
>Twofish and Rijndael (among others) use computations in a Galois Field.
>
>Can any of you explain to me why the Galois Field is usefull. (Advantages)
>Is it because of the modulus, so you'll never get more than 8 bits ??
Mainly.
>Or because it eases decryptation ??
>
>Rijndael uses 11B and Twofish uses 169 - how do one choose the irreductable
>polynomia ?? Are some better than others ??
That depends upon use. An irreducible in polynomials is similar to a
prime in integers. But some irreducibles are also primitive, which
may or may not be an advantage in actual use.
There are some related topics in my Glossary:
http://www.io.com/~ritter/GLOSSARY.HTM#GaloisField
http://www.io.com/~ritter/GLOSSARY.HTM#FiniteField
http://www.io.com/~ritter/GLOSSARY.HTM#Field
http://www.io.com/~ritter/GLOSSARY.HTM#Ring
http://www.io.com/~ritter/GLOSSARY.HTM#Polynomial
http://www.io.com/~ritter/GLOSSARY.HTM#Irreducible
http://www.io.com/~ritter/GLOSSARY.HTM#PrimitivePolynomial
http://www.io.com/~ritter/GLOSSARY.HTM#Mod2Polynomial
If anybody has problems with or suggestions for any of these or any
other topics, please let me know.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 22:23:39 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> MD5 produces a 128-bit output, using the birthday attack, you could
> expect to find a two documents that hash to the same value after trying
> 18,446,744,073,709,551,616 pairs.
> Defining wether its overkill depends on what u need you're hash to do.
> If you simply want to uniquly identify a record then its overkill. You
> would only need around 24-bits to represent all 4 million with a low
> chance of collision. To avoid birthday attack, you need about 6
> characters.
> A CRC is probably you're best bet, though it isn't designed for this
> task, because its realitivly simple to implement.
Thanks, I'll check CPAN for a CRC implementation.
------------------------------
From: "Vic Drastik" <[EMAIL PROTECTED]>
Subject: Re: Visual Basic
Date: Fri, 27 Oct 2000 09:27:58 +1000
> >VB is compiled too; however VB as a language is indeed unsuitable
> >for bit-twiddling.
>
> PowerBASIC, on the other had, is ideal for bit-twiddling.
> [ http://www.powerbasic.com ]. On the same subject, everyone
> who twiddles bits should know about [ http://www.basicx.com ].
You mean http://www.xbasic.org
BasicX is a microcontroller , XBasic is a compiled PC language (Linux and
Windows) with all the bit-twiddling primitives you may need , like >> , >>>
, << , <<< , & , | , ^ , ~ , RotateL , RotateR , mask and bitfield
selection using braces {}.
Vic
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Collision domain in crypt()?
Date: Thu, 26 Oct 2000 22:26:33 GMT
[EMAIL PROTECTED] wrote:
> Just take MD5 and chop off what you don't need, it'll actually be
> faster than crypt().
> BTW, I noted the e-mail address. I'm still gonna let you slide with
> decent security.
Actually, I tried hashing and taking the first 16 chars and had several
collisions, hence the request. :-/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 22:26:36 GMT
On Thu, 26 Oct 2000 17:57:40 GMT, in <8t9rag$rvb$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>My understanding of an "attack" is defined as anything that forces
>cracking runtime to be:
>
>(keyspace-x) even if x=1.
>
>No?
Some people would say than an *attempt* at a break was just an
"attack," and that only *success* in the attempt produces a "break."
A cipher which has a "break" obviously is "broken" in one sense, but
may still be usable and thus *not* "broken" in another, although that
is a different issue.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 22:27:08 GMT
On Thu, 26 Oct 2000 18:10:28 GMT, in <8t9s2f$sib$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>[...]
>I see your point, but my assertion was made within the context of
>NIST's selection process. The word "proven" in English is often used
>not in the sense of mathematical proof but rather in the sense of "have
>been shown in praxis". I remember some time back I criticized a post of
>Bruce Schneier where he stated something like "DES has proven to be
>secure", and now it is I who falls in the same linguistic trap.
My problem with that statement is not the obvious falsehood that "DES
has been mathematically proven secure," but instead the idea that
people *could* know if their use of DES was insecure. Simply
thinking: "everything seems to be OK, so it must really be OK" is in
no sense "proof" -- not even in base common usage.
The problem is that users *CANNOT* know if the cipher is secure, and
so *THERE* *CANNOT* *BE* a collective "proof" in practice: Suppose
DES is broken every day; just because we don't *know* that such is
happening and continue to use the cipher does not mean the cipher has
been "proven" strong in any sense at all.
Cipher strength *CANNOT* be shown "in praxis." No interpretation of
"proof" can make the statement correct.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Date: Thu, 26 Oct 2000 16:30:07 -0600
[EMAIL PROTECTED] wrote:
>
> My understanding of an "attack" is defined as anything that forces
> cracking runtime to be:
>
> (keyspace-x) even if x=1.
<snip>
One problem with a definition like that is that even the
worst possible attack (randomly guessing keys until you
get the right one) has an expected (average) cost of
keyspace/2. In fact, if you know everything except the
key, the absolute worst you can do is already keyspace-1;
you don't have to test the last one because it has to
be right.
Another problem is that the cost of checking one key is
rather fuzzy. You might be able to go faster by using
a clever way of going to the "next key" (reducing the
cost of key setup or decryption); conversely, it may
take several decryptions to check one key because of the
nature of the available data.
I doubt the term is defined that exactly; standard
usage seems to be "anything that is significantly
faster than brute force", where of course significance,
like beauty, is in the eye of the beholder.
JM
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Rijndael and PGP
Date: 26 Oct 2000 22:31:49 GMT
[EMAIL PROTECTED] (Simon Johnson) wrote in
<8t9qio$rbc$[EMAIL PROTECTED]>:
>In article <8t4jjk$hq9$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>> In article <bsgJ5.161$[EMAIL PROTECTED]>,
>> "George Gordon" <[EMAIL PROTECTED]> wrote:
>> > Rijndael and PGP. What's the word on this?
>> >
>>
>> You have succesfully named two buzzwords. Your homework is to study
>> why your question is stupid.
>>
>> Honest, the ciphers in PGP (IDEA, CAST, 3DES) are secure enough,
>adding
>> Rijndael will ****NOT**** make PGP any better or usefull then it
>> already is.
>>
>> Tom
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
>>
>Indeed, Rijndeal is faster than Twofish but not as secure. It appears
>than Zimmerman likes his ultra-secure ciphers (hence IDEA, CAST and 3-
>DES). So i would agree with Tom's reasoning, and say its unlikely that
>Rijndeal will be included in PGP.
I disagree strongly. THere is no proof that Twofish is any stronger
than Rijndael. And since it is the winner and carries the AES blessing
we may see stinky two fish dead and buried. Since it will no longer
have that fresh smell in the public eye. I aslo don't think security
is a big concern for PGP convenince and speed to the user is its main
virture. IF they wanted security better ciphers and better compression
methods would have been in place long ago.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: How do I detect invalid passwords?
Date: Thu, 26 Oct 2000 22:43:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] wrote in <8t88h7$j7v$[EMAIL PROTECTED]>:
>
> >I am trying to write an application that does something like this:
> >
> >1. Asks the user for a password.
> >2. Using the password, I get an MD5 hash.
> >3. I use the hash to encrypt the user's information (i.e. a data
file)
> >using a symmetric cipher such as BlowFish or triple-DES.
> >
> >Now when the user wants to retrieve the information I do something
like
> >this:
> >
> >4. Ask the user for the password (same one as in step #1 above). 5.
Get
> >the MD5 hash using the password in step 4.
> >6. Decrypt the data using the hash.
> >
> >I have two questions:
> >
> >A. Is there a better (i.e. safer) way to do this?
>
> Yes if password is shorter than the key
> why bother to hash it at all. I assume you
> are saving neither the hash or the password.
> Also why use something fishy like blowfish
> use the approved AES cipher would impress
> your boss and customers more.
While I agree Rijndael is possibly not the "most secure" of the AES
finalist I think dismissing their work on a whim to be very improper
thing todo.
Also in some algorithms such as RC4 using ASCII keys (no matter how
random they are) is not a good idea. I could use a 15 ASCII char
password (if it's random) that you will not guess easily but will be
ill-suited to plug directly into RC4.
Similarly for all other algorithms. Consider a DH exchange where we
have a 1024-bit secret, why would I just feed the lower n-bits of the
DH secret value? I would rather hash the entire value so statistical
attacks cannot predict certain parts of the words...
> >B. How do I detect an incorrect password? I don't want to decrypt the
>
> If you really want to do this I would encrypt the password
> the user entered the first time. When the user enters a password
> to get his data decypt the file that has his encrypted password
> if they match then his in. But I would make this a very slow
> operation if he guesses wrong so that he can't sit there and guess
> quickly. That is if you do it at all I think not doing anything
> and giving him garbage may be best.
Or you could be *smart* and make the number of possible keys large
enough. Let's not forget that every bit of entropy you add *doubles*
the work factor. I.e using an 80-bit key instead of a 64-bit key is
65536 times harder to guess (assuming all is random).
Why make your algorithm 65536 times slower? That makes no senses.
Another way to look at it... I don't care if you can try trillions of
keys a second.... if I can plomp in a 256-bit key it won't matter
either way.
See there is a difference between "nonsense crypto" and "real crypto".
You must tell the difference between the two to be a succesfull
cryptographer (a spell checker wouldn't hurt either, my spelling is
bad, sorry guys!).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: My comments on AES
Date: 26 Oct 2000 22:41:57 GMT
[EMAIL PROTECTED] wrote in <8t9qjm$rd1$[EMAIL PROTECTED]>:
>
>
>> It is not inconceivable that all possible ciphers have some kind of
>> academic break. I'd be intensely interested in a proof (or even a
>sketch
>> of a proof) that it is even possible for a non-OTP cipher to be
>certified
>> against such breaks.
>
>While I can offer no absolute proof, you can take the following as an
>indicator that it may be true.
>
>Take a function ct=f(key, pt) that meets our requirements for
>cryptography.
>If there exists a (pt,ct) pair where there exists more than one value
>of key to create it then an academic attack is immediately presented
>once the pair has been found, because there is a detectable bias in the
>system
Could you expand on this some more. Since I know for scott19u and
small files there are several keys that can map plainfile to cipherfile.
But it the same time there are many possible plainfiles that could map
to the same cipherfile. So where is the break. Even if two small files
are encrypted with the same key and an attacker finds a key then that
maps planefileone to cipherfileone. It is highly unlikely that
it will work for the second set of files. It is very possible that
every entry in the S table is wrong. So how do you assume there is
a break. Just curious since most messages encrypted with scott19u
will be much smaller than the key.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Modemac <[EMAIL PROTECTED]>
Crossposted-To: alt.slack
Subject: IRC crypto
Date: 26 Oct 2000 22:57:16 GMT
[ This is a repost of the following article: ]
[ From: lcs Mixmaster Remailer <[EMAIL PROTECTED]> ]
[ Subject: Mirc crypto ]
[ Newsgroups: alt.religion.scientology ]
[ Message-ID: <[EMAIL PROTECTED]> ]
http://noomorph.virtualave.net/mirc_dev/
has some interesting developments of cryptography for mirc.
I am not yet certain whether this can be trusted.
It's very recent and probably has not been stress-tested, but according
to the developer's initial announcement:
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
hello there. i've at last finished development of the first public
beta of mIRC.Crypt, a mirc crypto plugin for secure irc channel
conversations (client to client encryption). it interfaces with
command line pgp for asymetric encryption and signing of session keys
(unique to user/channel combination) and random data. employs ansi
x9.17 key generation and blowfish block cipher (at 256 key bits).
highly configurable and easy to use :) i dont know anywhere i can
send it for distribution (uhm. i guess i should go get some
web-space...) but anyone who is interrested in it - please email
me/reply post and i will email you the zip (approximately 33k). if
anyone wishes to comment on it's potential usefulness i would
appreciate it.
many thanks
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOd3uNGECkjbdfY7gEQIBbwCcD7OlhskmEdUX7dP6EchsJZ/A94cAn0RN
OM2oKB8G1RHsCgQBrKF1Y1cq
=qXmV
=====END PGP SIGNATURE=====
--
First Online Church of "Bob"
http://www.modemac.com/
------------------------------
** 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
******************************
