Cryptography-Digest Digest #411, Volume #14 Tue, 22 May 01 19:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Help with a message ("Amethyste")
Unix file encryptor ("Arik Shelter")
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: ECB plus padding instead of CBC? (SCOTT19U.ZIP_GUY)
Re: CIA Kryptos last 97 characters (Gary Warzin)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: ECB plus padding instead of CBC? ("Tom St Denis")
Re: ECB plus padding instead of CBC? (SCOTT19U.ZIP_GUY)
Re: "computationally impossible" and cryptographic hashs ("Douglas A. Gwyn")
Re: survey ("Douglas A. Gwyn")
Re: ECB plus padding instead of CBC? (SCOTT19U.ZIP_GUY)
Re: survey ("Tom St Denis")
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: ECB plus padding instead of CBC? ("Tom St Denis")
Re: survey (Mok-Kong Shen)
Re: ECB plus padding instead of CBC? ("Julian Morrison")
Re: survey ("Tom St Denis")
Re: survey ("Joseph Ashwood")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 22 May 2001 22:08:11 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 22 May 2001 15:54:03 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote, in part:
>
>> Yes Joe and the other phony crypto gods refuse to openly state
>>that full RIJNDAEL can be used in a full block mode that is not
>>a weakened 3 letter chaining mode. Where the result can still be
>>bijective to byte files on input and output. They seem to wrongly
>>think only something weak like a counter mode can do this.
>
>Ah. Then you don't claim that you can, with Rijndael, using your
>preferred "full block mode", encipher a one byte compressed input to a
>one byte output?
>
Actaully I never specifed the input file size. Only looking
at output that could be one byte long. Don't forget that
BICOM has a bijective PPM compressor woring on the input file.
Also I MADE A MISTAKE. since full RIJNDEAL uses only
128 bits per block. All of the files that when encrypted
that map to one byte. Would have used only one 128 bit block.
It would be trivial to change BICOM so that at least 2 128 bit
blocks are used. Matt if your reading this you might do that or
leave to the users who have your source code if they wish to
use a two block min. Anyway that would put the current limit for
a one byte output file in the 2**128 range. So that is less
than the 2**256 I first stated. Hell I am human and make mistakes
I am getting like John I am starting to BS without writting code
to test. But 2**128 is still a hell of a lot larger than 2**8
which is what one would get in basic CTR mode.
Know since I admited to being human and not god. I since I
didn't write BICOM. Maybe Matt could say for a single output
file of one byte. How many possible input files could one select
from as a possible input. I was basing it on the key of 2**256
choices but if a single block is used there are only 2**128 possible
values.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Amethyste" <[EMAIL PROTECTED]>
Subject: Re: Help with a message
Date: Tue, 22 May 2001 22:14:04 GMT
"gp" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> Most of these occurances are multiples of 3.
For key length = 3 I found :
IC1 = 0.069
IC2 = 0.054
IC3 = 0.064
It is probably a Vigenere with 3 alphabets.
------------------------------
From: "Arik Shelter" <[EMAIL PROTECTED]>
Subject: Unix file encryptor
Date: Tue, 22 May 2001 18:05:13 -0400
I am looking for a command-line Unix file encryptor that uses 128 bit (or
higher) encryption. Does anyone know of anything out there besides PGP (too
much $$$) or GnuPG (not recommended for production environments) ?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 22 May 2001 22:16:04 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (John Savard) wrote in
><[EMAIL PROTECTED]>:
>
>>
>>>At one point you specifically stated that BICOM could
>>>output a single byte output that was Rijndael encrypted, that always
>>>has been, and always will be the problem.
>>
>>But that _is_ possible. Just use counter mode, for example. I agree
>>you can't use ECB mode, or CBC mode, to produce a one-byte
>>Rijndael-encrypted output. But other modes allow one to encipher
>>messages in fractions of a block, although they may require an IV the
>>size of a block in addition.
>>
>
> Mr J. You seem to be big on theroy but I never see code at your
>site. BICOM does use RIJNDAEL in full block mode. Obviously its
>not your NSA approved variation of CBC but its a carefully mated
>bijective compression encryption combination. I suppose you
>think it doesn't work. Sorry but the weak CTR mode does not give
>full bijectiveity like BICOM. If you use straight weak CTR mode
>and tried to make it bijective which it really is not you have two
>major problems that the big boys don't address.
>
>1) Your encryptying consecutive values for the input block namely
>ctr then ctr+1 ... Which requires a unque starting value for each
>message or the one time pad probken occurs. And the very fact of
>using consecutive values is giving a big plus to the NSA boys in
>breaking this weak chaining mode.
>
>2) Its not bijective anyway. Proof take the stupid method as proposed.
>Suppose you have a one byte output file. What could the input have
>been? The anwser is only one of 256 values. Not to good. Who cares
>what the real key was you only have 2**8 possibliites.
>Compare this to a real bijective encryption BICOM which actaully
>uses a modifed impedanced mathc CBC mode. For a one byte output
>file. Any key could have been used. Meaning that there are 2**256
>possible messages that could have been the original files. So for
>this simple example CTR suck big time since I think you can even
>see that 2**256 is a little more secure than 2**8. Or at least I
>hope you can see that.
As mentioned on other thread I caught it not someone else
but as BICOM is currently implimeneted a one byte output file
I think would have only use one full block of RIJNDEAL so that
puts it at 2**128 still a far cry greater than 2**8
>
> The big boys will deny problem one exists. Yet that there is
>a simple realationship between blocks is undeniable.
>THe second is a problem they we say exists in only small files.
>Meaing they don't really want to look at the problem and want
>you to use weak chaining.
>
>
>David A. Scott
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ECB plus padding instead of CBC?
Date: 22 May 2001 22:12:52 GMT
[EMAIL PROTECTED] (Julian Morrison) wrote in
<[EMAIL PROTECTED]>:
>Will this work? I have a block cypher, say Rijndael, which has an input of
>16 bytes. I use the first 12 of those bytes for data and fill the last
>four from /dev/urandom.
>
>The intent is to avoid CBC, so that any 16 byte data chunk can be
>separately decoded despite missing data chunks.
>
>Is this a good approach? What security do I lose from this (if any)?
>
Well one for one thing you haven't covered all your options.
You say use 12 bytes for the data and 4 bytes filled with random.
What if file is 11 bytes long. So no its not a good idea. Its
a start of an idea but your not done enough to use it as a general
file encryption sort of thing.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
Subject: Re: CIA Kryptos last 97 characters
From: [EMAIL PROTECTED] (Gary Warzin)
Date: Tue, 22 May 2001 22:22:00 GMT
Thanks to input from Douglas Gwyn and Ferdinando Stehle I have been able to
revise and simplify my notes on the last 97 characters of Kryptos. The new
version is now available at www.iquest.net/~gwarzin. Looking forward to any
comments or alternate approaches.
(In all fairness to both Douglas and Ferdinando, I should point out that, for
the most part, they disagree with my hypothesis.)
===========================================
Gary Warzin [EMAIL PROTECTED]
Audiophile Systems, Ltd. www.aslgroup.com
Phone: 317-849-7103 Fax: 317-841-4107
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 23:33:10 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote:
> Um, read up. CTR doesn't use chaining.
>
> The idea works like this.
>
> 1. Start a binary counter at 0, call it I 2. For each new block
> increment I and encrypt it with the key. Call the ciphertext of the
> counter C1.
> 3. Take the message block and xor it against C1. 4. Go backto #2 as
> needed.
>
> The nice thing is that you can seek with this method since you use the
> block cipher regardless of the message being encoded. So you simply use
> a 128-bit counter for all your UDP packets (or blocks within them) and
> as long as you don't reuse counter values the method is secure (asuming
> all else is ok like random keys, etc...)
Right. Although I'd have to do a bignum bit increment for every send, and
I couldn't wrap-around the counter, so I'd have to renegotiate the key at
that point.
Is the predictability of this count a drawback? (ie: do I have to hide the
count of each block from snoopers?)
By comparison, how bad exactly is partial-block-plus-padding-ECB? Since it
seems it would be several orders of magitude cheaper to do, it may be
"secure enough".
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 22:36:56 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote:
>
> > Um, read up. CTR doesn't use chaining.
> >
> > The idea works like this.
> >
> > 1. Start a binary counter at 0, call it I 2. For each new block
> > increment I and encrypt it with the key. Call the ciphertext of the
> > counter C1.
> > 3. Take the message block and xor it against C1. 4. Go backto #2 as
> > needed.
> >
> > The nice thing is that you can seek with this method since you use the
> > block cipher regardless of the message being encoded. So you simply use
> > a 128-bit counter for all your UDP packets (or blocks within them) and
> > as long as you don't reuse counter values the method is secure (asuming
> > all else is ok like random keys, etc...)
>
> Right. Although I'd have to do a bignum bit increment for every send, and
> I couldn't wrap-around the counter, so I'd have to renegotiate the key at
> that point.
>
> Is the predictability of this count a drawback? (ie: do I have to hide the
> count of each block from snoopers?)
Nope, the count values can be public knowledge. Just not their encrypted
values.
Not only that but increments with 128-bit numbers takes no time... (i.e four
adds...)
> By comparison, how bad exactly is partial-block-plus-padding-ECB? Since it
> seems it would be several orders of magitude cheaper to do, it may be
> "secure enough".
Your method is less efficient and less analyzed...
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ECB plus padding instead of CBC?
Date: 22 May 2001 22:36:59 GMT
[EMAIL PROTECTED] (Julian Morrison) wrote in
<[EMAIL PROTECTED]>:
>
>The intended use in secure and small-as-possible UDP-alike datagrams,
>where no amount of dropped messages will stop decryption of those
>successfully recieved, immediately they arrive. In this circumstance it
>would be quite possible to recieve a data chunk and neither the one
>preceding nor the one following, or entirely out of sequence, so no simple
>XOR chaining will work.
>
I am not sure what your driving at. Don't you care about the
block order. IF you send 1 2 3 4 5 6 packets are you happy
with 1 2 4 3 6 packets getting through. Do you need to know
which packet is which. Do you only have packets that are 12 bytes
of data independent of the other packets 12 bytes of data.
If that the case then you approach is ok.
If not state what you need more clearly
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "computationally impossible" and cryptographic hashs
Date: Tue, 22 May 2001 21:50:03 GMT
David Wagner wrote:
> Douglas A. Gwyn wrote:
> >Not in general; a "randomly chosen" function (according to some
> >distribution over the space of all functions) will a posteriori
> >not act pseudo-randomly.
> Meanwhile, I could voice the same complaint about your terminology
> usage. Strictly speaking, a pseudorandom function need not have
> (an approximation to) the uniform distribution. Pseudorandomness
> refers to "computationally indistinguishable from random", and
> just as a random function might be randomly distributed according
> to some arbitrary distribution D, so too a pseudorandom function
> might be distributed according to a distribution D' that is
> computationally indistinguishable from D.
? I didn't mention uniform distribution, and once a function is
selected it has a trivial distribution. Note what I said the
relevant sample space was.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 21:51:15 GMT
Tom St Denis wrote:
> Well my design is simple and faster than most other known block ciphers.
> Does that count?
No.
void encrypt(const char *key, char *data) { } // very fast and simple
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ECB plus padding instead of CBC?
Date: 22 May 2001 22:45:07 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<cSBO6.8064$[EMAIL PROTECTED]>:
>
>> By comparison, how bad exactly is partial-block-plus-padding-ECB?
>> Since it seems it would be several orders of magitude cheaper to do,
>> it may be "secure enough".
>
>Your method is less efficient and less analyzed...
Actually your method is more in line with what RIJNDAEL is designed
for. If you have independent input blocks encrypted with the method
then it safer that using somthing predictable. Tom coments about the
counter valuses to be encrypted being open knowledge definitely weakens
the system. By how much is anybodys guess.
However your method will take more bandwidth if thats a problem.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 22:58:56 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Well my design is simple and faster than most other known block ciphers.
> > Does that count?
>
> No.
>
> void encrypt(const char *key, char *data) { } // very fast and simple
And you call me immature? Wow, you guys have high standards... double
standards but high none the less.
Tom
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 23:59:39 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
> I am not sure what your driving at. Don't you care about the
> block order. IF you send 1 2 3 4 5 6 packets are you happy with 1 2 4 3
> 6 packets getting through.
My approach in this case would be in "unreliable stream" mode to deliver 1
2 4 6 (ie: the outdated 3 is dropped, as would 5 be if it then arrived),
or just all of them as and when they arrive, in "unreliable datagram"
mode.
> Do you need to know which packet is which.
Yes for "unreliable stream" mode.
> Do you only have packets that
> are 12 bytes of data independent of the other packets 12 bytes of data.
In either of the two modes described above, that's the app's problem, not
the protocol's.
> If that the case then you approach is ok. If not state what you need
> more clearly
Ok, see above.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Tue, 22 May 2001 23:00:25 GMT
"Julian Morrison" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
>
> > I am not sure what your driving at. Don't you care about the
> > block order. IF you send 1 2 3 4 5 6 packets are you happy with 1 2 4 3
> > 6 packets getting through.
>
> My approach in this case would be in "unreliable stream" mode to deliver 1
> 2 4 6 (ie: the outdated 3 is dropped, as would 5 be if it then arrived),
> or just all of them as and when they arrive, in "unreliable datagram"
> mode.
>
> > Do you need to know which packet is which.
>
> Yes for "unreliable stream" mode.
With a CTR mode of operation you could throw away blocks and decode them in
reverse order for all it matters.
CTR doesn't care about order or consistency.
Look at http://www.cs.berkeley.edu/~daw/papers/ for some papers on CTR.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Wed, 23 May 2001 01:00:09 +0200
Tom St Denis wrote:
>
> "Pascal Junod" <[EMAIL PROTECTED]> wrote:
> > g) Most of us are quite busy and don't have enough time to read carefully
> > what you write.
>
> Which is ironic because I know with 90% certainity that you have downloaded
> all my papers including MDFC, NA and TC15 ...
>
> Do you just download them and not read them?
Are your stuffs stored at your internet provider? I am
interested to know how did you manage to get a record of
those who have accessed/downloaded these. Thanks.
M. K. Shen
------------------------------
From: "Julian Morrison" <[EMAIL PROTECTED]>
Subject: Re: ECB plus padding instead of CBC?
Date: Wed, 23 May 2001 00:02:56 +0100
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
> Well one for one thing you haven't covered all your options.
> You say use 12 bytes for the data and 4 bytes filled with random. What
> if file is 11 bytes long. So no its not a good idea. Its a start of an
> idea but your not done enough to use it as a general file encryption
> sort of thing.
This isn't file encryption, this is network protocol encryption. The
length will probably be in the data chunk as the first byte, or some
equivalent mechanism. That's protocol level stuff though, not relevant to
the encryption. And it would have to be done anyway with any sort of block
cypher.
--
I like e-gold. Digital currency based 100% in real physical gold.
This link ( http://www.e-gold.com/e-gold.asp?cid=281798 ) takes you to
their site and shows me as the introducer if you open an account.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 23:02:28 GMT
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Tom St Denis wrote:
> >
> > "Pascal Junod" <[EMAIL PROTECTED]> wrote:
>
> > > g) Most of us are quite busy and don't have enough time to read
carefully
> > > what you write.
> >
> > Which is ironic because I know with 90% certainity that you have
downloaded
> > all my papers including MDFC, NA and TC15 ...
> >
> > Do you just download them and not read them?
>
> Are your stuffs stored at your internet provider? I am
> interested to know how did you manage to get a record of
> those who have accessed/downloaded these. Thanks.
I run the httpd off my computer. I have a log (well when it logs
properly... stupid windows) of all accesses to my site, including their IP,
time, date and what they fetched...
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Tue, 22 May 2001 15:43:35 -0700
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:a4BO6.7983$[EMAIL PROTECTED]...
> Comments don't always have to be "here is a detailed
> dissertation of your paper" Just "neat keep it up" or "I don't like it"
or
> "thank god for recycling" would be nice. Just short comments if possible.
I have read much of what you have written, along with the writings of dozens
of other people, at a rate of 700+ pages a week. What I have found is that
your writings tend towards a brute-forcish style of establishing security.
Instead of trying to find S-boxes that can be expressed extremely easily,
you pound your way through the entire space finding a set that will work for
what you want. Instead of giving a proof against differential cryptanalysis
that can be applied to a broad range of possible ciphers you find a way to
establish that your ciphers are probably immune. Continue similarly. Also
while your designs are fundamentally solid they tend to lack an explorative
nature. You need to change your target a bit. Instead of just trying to make
a secure cipher, try to make one that has something interesting about it,
create a new type of primitive structure (e.g. Wide Trail), or a particular
method of applying it (example RC6 is a feistel but expresses it
differently). Explore the boundaries, we know that the middle of the sandbox
offers some good secure areas, but it's crowded, find something that can
distinguish your designs from the designs of others. Perhaps you should look
into a design that requires a large number of very fast rounds to be secure,
or look into a different method of constructing S-boxes, a different
combinor for feistel structures. Something distinctive, something that isn't
just another cipher, experiment, don't just reiterate.
Think about it, who in cryptography has made a name for themselves by just
doing what everyone else has already done. We have names like Feistel, who
basically developed a new structure for symmetric ciphers, Rivest who
continually experiments with new and different ideas, Daemen who also
created a new structure, Schneier who experimented with key-based s-boxes,
etc. But no one will even given your work a second glance unless you find
something new and interesting for people to experiment with. This is true of
all fields, in physics we remember Einstein, Newton, etc for their enormous
donations. In art we remember Da Vinci, Dali, etc. Everywhere (unless you
look at Bill Gates) you will see that the only people that get any attention
are innovators.
Joe
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
