Cryptography-Digest Digest #496, Volume #10 Tue, 2 Nov 99 18:13:04 EST
Contents:
Re: Idea for Twofish and MARS ("Niels Ferguson")
IBM 4758 (was: CA software) (Paul Rubin)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (wtshaw)
Re: RC 4: security & law (Bill Unruh)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: What is the deal with passwords? (Tom St Denis)
Re: Doesn't Bruce Schneier practice what he preaches? (Tom St Denis)
Re: announcement: steganography program "steghide" (jerome)
Re: Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: Idea for Twofish and MARS ([EMAIL PROTECTED])
Re: Re: Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: "Niels Ferguson" <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and MARS
Date: 2 Nov 1999 18:30:36 GMT
[EMAIL PROTECTED] wrote in article <7vmu9l$gl$[EMAIL PROTECTED]>...
> One of the main features of DES was that certain bits affected more than
> one s-box selection. After looking at TwoFish and MARS again last
> night, I came up with an idea that could improve them.
>
> Twofish has a G function which consists of two F-functions, and PHT, and
> the addition of two round subkeys. Before the plaintexts are passed
> through the F-functions, one of them is rotated by 8 bits. I was
> thinking that if the inputs to both F-functions were rotated by 4 bits,
> one left and one right for instance, the output of each s-box would be
> affected by two inputs.
The standard terminology that we use is that we call the round function the
F-function, and it consists of two g-functions, a PHT, and the key
addition. Using the standard terminology makes it a bit easier for others
to understand.
The rotation by 8 bits was inserted to ensure that the two `halves' of the
F-function are different. In most implementations it is free from a
performance point of view because accessing the S-boxes is done on a byte
level anyway, and the 8-bit rotation can be implemented by accessing the
input bytes in a different order.
Your suggestion to rotate the inputs by 4 bits would provide some diffusion
between bytes. As you point out, every output byte from an S-box would then
depend on two input bytes.
The diffusion in Twofish is performed by several elements. Within the round
function, the S-boxes provide diffusion within a byte (i.e. between the
bits of a byte). The MDS matrixes and the PHT provide diffusion between the
bytes, and they are very effective at it. Each of the eight output bytes of
the F function depends on each of the eight input bytes. So each input byte
of the F-function in the next round depends on all of the input bytes of
the F-function in the current round (plus one or two bytes from the right
half of course). In short, I do not see that Twofish needs any extra
diffusion between the bytes.
Your rotations might fulfill a similar role to the one-bit rotations that
are in the data-path, in that they break up the byte-aligned structure of
the cipher. On many platforms one-bit rotations are faster then four-bit
rotations. I would therefore not want to swap the one-bit rotations for the
suggested four-bit rotations.
One could argue that the cipher would be `better' with the added rotations.
First of all, it is not clear that the extra rotations improve the
security. You would have to repeat all of our analysis, as well as all the
analysis done by other people. That is well over a man-year of work. The
second observation is that the extra rotations have a cost in performance.
It is not clear that this is the best way to increase the security if you
are willing to decrease the performance. On a Pentium-Pro, adding two 4-bit
rotations to each round would probably cost as much as adding an extra
round at the end. (This is the trade-off we looked at for the one-bit
rotations.) The real question becomes: would you rather have 17 rounds of
Twofish, or 16 rounds of Twofish-with-extra-4-bit-rotations?
[...]
> Anyway, these are just idea I came up with. It just seemed that nobody
> was doing anything like this. The only reason I picked 4 for the
> rotates was that you would have 1/2 of each of two bytes determining the
> output of an 8xN (or in MARS, 9x32) s-box.
It is very easy to make variations on a cipher. One has to be very careful
when doing so; there are many examples in literature of how very minor
changes can have a negative effect on the security. DES is a good example:
almost any small change (such as changing the order of the S-boxes) weakens
it.
> csybrandy.
It is great to see that people are taking an active interest in the AES
process. If you have any comments on any of the finalists, I urge you to
also submit them to NIST as formal comments. (These are due somewhere next
spring.) There is little time for the entire process, and every
contribution can help in selecting the best standard.
Niels
=========================================================
Niels Ferguson, http://niels.ferguson.net/
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: IBM 4758 (was: CA software)
Date: 2 Nov 1999 18:40:39 GMT
Shawn Willden <[EMAIL PROTECTED]> wrote:
>IBM's Trust Authority and Vault Registry products provide this,
>although it could be a little more turnkey. The tamper-resistant
>(actually tamper-reactive) hardware is an IBM 4758 PCI Cryptographic
>Coprocessor. It is FIPS 140-1 certified, currently to level 4, soon
>to level 3. See IBM Cryptography: 4758 PCI Cryptographic Coprocessor
>technical description for details of the 4758. See Security :
>Products for info about more IBM security products.
Thanks. I'm familiar with the 4758 and it is a really cool product.
I'm not using it right now because when I looked at it a year ago, its
software toolkit was really rudimentary so it seemed hard to program,
and I needed to get something running right away, but I've been hoping
to find the time soon to get a 4758 unit and do something with it.
What is this though about it being soon to be certified only to level 3?
Is it losing its level 4 certification for some reason?! Or are they
coming out with an "economy model" that's only at level 3, or relaxing
some of the interlocks or something like that? You've got me wondering
now.
Paul
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Tue, 02 Nov 1999 12:56:06 -0600
In article <7vga5t$i9m$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> It's not just drifts. That is, I would expect those drifts to be like
> brownian random walk. It would probably make a neat exercise for
> a Graduate level statistics course.
>
Given thermal stabilizing circuits, crystal variations are complex events
in which the pattern is largely determined by other components. Having
been associated with people who wore pointed hats and did such things, I
had ample opportunity to see such things not only as used, but as
developed. Of course, I donned a different one for work with the digital
magic I pulled out of thin air in my lab as well.
--
Geo. W. never met a dollar he did not like.
As for people, he likes their dollars.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC 4: security & law
Date: 2 Nov 1999 19:10:36 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED]
([EMAIL PROTECTED]) writes:
]II.
]What about the U.S. Export Regulation. I think it is
]allowed to export cryptogrphic product from U.S. if
]the key isn't longer than 56 Bit. If it is longer, than
]you need permission from an "office/authority".
No. ALL crypto exports require a license. It is just tht for weak enough
crypto you might actually get that license.
]Netscape CC 4.x is able to use 40-bit and 128-bit encryption
]in the SSL(based an RC4). What version CC 4.x uses in other
]states than the U.S.
Countries? They only export the 40 bit version to other countries. Not
that it is hard to convert it
]Where can i find law text about this regulation.
www.access.gpo.gov/bxa/ear
]The algorithm RC-4 is widespread. If i know the algorithm
The algorithm was a trade secret. It is no longer a secret.
Yes, you can use it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Tue, 02 Nov 1999 20:22:10 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
> Oddly, this doesn't sound like anything we have been talking about. I
> have never heard -- and certainly never made -- a suggestion that the
> adversary will choose the cipher.
You certainly have heard such a suggestion. Yes, you
failed to consider the chosen cipher attack, and now
it seems that you confuse failure to recognize the
problem with not having it.
> On the contrary, I have suggested
> that each user be able to create a list of ciphers they will accept,
> and then negotiate agreement -- automatically, in the background, and
> secretly, under the cover of cipher. This would be an ordinary
> handshake selection, not a cryptographic protocol, but nevertheless
> clearly neither exposed to nor under the control of the opponents.
> How is that related to the adversary choosing the cipher?
As I noted some time ago, your writings made the point
that the choice of cipher was secret, but were clearly
oblivious to the fact that authentication of the choice
is more important. The details of your protocols have
never appeared, so we cannot tell whether the attack
would work. The fact that you still compare the
negotiation of the cipher to modem protocols, and call
it "an ordinary handshake selection, not a cryptographic
protocol" is rather ominous.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 20:35:21 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> Maybe true of your setup, but many of us have learned enough to
seriously
> reduce the hacker risk. Even if a hacker steals my computer and has
years to
> play with it, I'd bet my life that he won't crack my passwords. For
your
> system, a nosy room mate can boot the computer and have 100% access
to the data.
>
> In my case, and I'm sure for many other people out there, there are
things on
> the computer that are better not exposed, even by accident. Things
that if made
> public could have serious life-altering consequences. Just letting
anybody who
> can hit the power switch on the machine see these things might not be
a good
> idea. If you don't care about your data being exposed, why bother
encrypting it
> on your computer in the first place. 99% of my email doesn't go out
encrypted,
> there just isn't a need for it. What does get encrypted deserves the
highest
> level of security I can manage.
>
> What if your floppy gets lost, stolen, damaged, erased by a magnet,
what then,
> just forget about all your encrypted data? I'd rather have a
password protected
> backup of the key somewhere.
Obviously you guys lack innovative thinking. You can always copy your
peekboo private/public key. Paste em in the message window and encrypt
with your own password. This is what I did for a backup.
In your mind simply putting a bios password will stop all hackers. If
this is true (or let's say a win95 login password) then do you really
need to encrypt your key?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 20:38:53 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Johnny Bravo) wrote:
> There is no requirement that a password has to consist of random
alphanumeric
> characters and symbols. This strawman has been beaten to death many
times
> recently in password threads.
>
> Your example password has about 92 bits of entropy, the following
passphrase
> "mince sequin drama gorky ajax yoga loan" has 90 bits of entropy and
could
> easily be remembered with a mnemonic.
> "MINCE the SEQUIN shirt for the DRAMA in GORKY park, AJAX wants a
YOGA LOAN."
> If this was your password you would have little trouble remembering
it after
> using it a few times a day for a week or so. This is how I can
remember a 130
> bit password, even one I haven't used more than once or twice a
month. The
> mnemonic is easy to remember, and with the mnemonic, you easily
remember what
> the words in the password are.
You don't represent a majority of the computer user demographic
though. Most people at Nortel for example use silly passwords like
LM230-1, etc...
> Hardly secure, if someone gets your floppy, or just makes a copy
while you are
> not watching it, your security is blown. If you lose the floppy, or
the floppy
> goes bad, you lose your key. For the moment, the only storage media
we have
> complete physical control at all times over is the one between your
ears.
But the chances of someone stealing my floppy disk is about the same as
me inventing a brain ray and stealing your thoughts.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Tue, 02 Nov 1999 20:42:36 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
> To reply to you, and Mr. John Kennedy: if you are using an encryption
> scheme
> through an internet connections, the files on your PC are vulnarable!
> File
> permissions can screw up and hackers can end up getting to your files
> (including
> your private key which you have simply fwrite()ed to your hard disk).
> In fact,
> for a good hacker, getting this file would in fact be a peace of cake
> (even with the
> good permissions set). This is why we usualy encrypte the private
key,
> using some
> sort of password scheme. Even more far fetched, you should always
> delete your
> key from *memory* once you have finished with it, and never save it as
> cleartext
> on execution. Even data that has been erased from your hard disk *is*
> recoverable.
>
> Most encryption systems rely on schemes protocols that are mostly
> unbreakable,
> it's usualy the way people put does protocols together that makes the
> system vulnarable.
> You had a big hole in your system by fwriting your private key to disk
> as a cleartext...
> Look at any system that has been cracked: hotmail, netscape,
encryption
> on cell phones,
> etc...
>
> One way to keep it safe, if you realy do not want to use passwords, is
> to write your
> private key on diskette only, but this is usually unpracticale, people
> don't usualy
> want to bother with that.
I honestly believe that encrypting the private key is not a major
security winner for single users. Ya, if I used this computer with 20
other people it may be a problem, but I don't and most others don't.
Plus you assume good passwords are chosen to encrypt the private key.
I would rather make the private key inaccessible then encrypt it (which
in theory makes it inaccessible anyways).
I am thinking of adding a 'encrypt peekboo.dat' feature to peekboo, but
I don't see that as a 'major security' bonus.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Tue, 02 Nov 1999 20:45:15 GMT
In article <[EMAIL PROTECTED]>,
Boris Kazak <[EMAIL PROTECTED]> wrote:
> Dream or realistic, but the good rule of thumb is that you keep your
> source
> code secret only if you are ashamed of it...
Even my peekboo code is bad [i.e messy] but I released it. For several
reasons actually.
a) Maybe someone will pick it up and clean it up? [now I am dreaming].
b) Maybe someone can improve [i.e speedwise] the algorithms contained
therein
c) Newbies wanting to read source...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: announcement: steganography program "steghide"
Reply-To: [EMAIL PROTECTED]
Date: Tue, 02 Nov 1999 20:55:55 GMT
On 31 Oct 1999 09:06:57 GMT, David A Molnar wrote:
> I just think that we need a strong guarantee of "the adversary
> can't find where the message is."
interresting, i will think more about it. some unorganized thoughts
about it:
- i don't want to have any constraint on the encrypted data format.
- the aim of stegano is to hide the presence of the message, so an
observer must not be able to notice it.
- if i change the least significant bit of the pixel value, and the
observer has the original picture, it would be better to use a picture
format with compression with loss (like jpeg) because there are often
is subject to roundoff error.
So if i recompress the picture with another compresser, the picture
will not be the same, even if the newly recompressed picture doesnt
contain any message.
it would be harder for the observer to find the pictures with message.
- The aim is to make the message looks like random so no known
patterns/caracteristics.
- scramble the message with part of the picture with stay unmodified.
i realize i dont explain my idea clearly... not clear enougth for me...
anybody get pointer on steganography and picture (influence of roundoff
in jpeg, or use the caracteristic of the human eyes, the fact that
the human see more easily the delta on some colors than other) ?
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 20:49:35 GMT
Reply-To: this news group unless otherwise instructed!
On Tue, 02 Nov 1999 04:15:14 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> That was an old thread. True a random file tends not to compress.
>Bad a random file also decompresses to a very large file with my
>method. Find Clintons last message.
Hmmm... Okay.
Next question: does a random file decompress out to a random file?
Also, how well does this resultant random file from a bad key compress
with a different compression routine? Could an angle of attack be
formed by comparing your o-o-o re-compressed data with data compressed
by a n-o-o-o?
Because, by nature, your decompressed file will compress back into the
same file. But, if the resultant decompressed file can't be
compressed by a n-o-o-o then this tells the attacker something.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 20:57:45 GMT
Reply-To: this news group unless otherwise instructed!
On Sun, 31 Oct 1999 05:14:36 GMT, Clinton Begin <[EMAIL PROTECTED]>
wrote:
>Yep. It worked. Here are the results.
>
>10/30/99 05:53p 2,048 Random.tmp
>10/30/99 05:58p 2,094 RANDOM.H3
>10/30/99 11:00p 6,336 RANDOM.H2
How well does RANDOM.H2 compress using, say, PKZIP?
Because, if it doesn't compress down to near Random.tmp when using ZIP
then this may be angle of attack. ... and that's not good!
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Idea for Twofish and MARS
Date: Tue, 02 Nov 1999 21:01:48 GMT
In article <01bf255f$d0f59720$17e9a8c0@pinguin>,
"Niels Ferguson" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote in article <7vmu9l$gl$[EMAIL PROTECTED]>...
> > One of the main features of DES was that certain bits affected more
than
> > one s-box selection. After looking at TwoFish and MARS again last
> > night, I came up with an idea that could improve them.
> >
> > Twofish has a G function which consists of two F-functions, and PHT,
and
> > the addition of two round subkeys. Before the plaintexts are passed
> > through the F-functions, one of them is rotated by 8 bits. I was
> > thinking that if the inputs to both F-functions were rotated by 4
bits,
> > one left and one right for instance, the output of each s-box would
be
> > affected by two inputs.
>
> The standard terminology that we use is that we call the round
function the
> F-function, and it consists of two g-functions, a PHT, and the key
> addition. Using the standard terminology makes it a bit easier for
others
> to understand.
Ooops, I got the F and G functions backwards. Sorry. I didn't have a
reference handy when I wrote this up, sorry.
>
> The rotation by 8 bits was inserted to ensure that the two `halves' of
the
> F-function are different. In most implementations it is free from a
> performance point of view because accessing the S-boxes is done on a
byte
> level anyway, and the 8-bit rotation can be implemented by accessing
the
> input bytes in a different order.
>
> Your suggestion to rotate the inputs by 4 bits would provide some
diffusion
> between bytes. As you point out, every output byte from an S-box would
then
> depend on two input bytes.
>
> The diffusion in Twofish is performed by several elements. Within the
round
> function, the S-boxes provide diffusion within a byte (i.e. between
the
> bits of a byte). The MDS matrixes and the PHT provide diffusion
between the
> bytes, and they are very effective at it. Each of the eight output
bytes of
> the F function depends on each of the eight input bytes. So each input
byte
> of the F-function in the next round depends on all of the input bytes
of
> the F-function in the current round (plus one or two bytes from the
right
> half of course). In short, I do not see that Twofish needs any extra
> diffusion between the bytes.
>
> Your rotations might fulfill a similar role to the one-bit rotations
that
> are in the data-path, in that they break up the byte-aligned structure
of
> the cipher. On many platforms one-bit rotations are faster then
four-bit
> rotations. I would therefore not want to swap the one-bit rotations
for the
> suggested four-bit rotations.
Hmmm, I did not know that. That's a definate performance issue right
there.
>
> One could argue that the cipher would be `better' with the added
rotations.
> First of all, it is not clear that the extra rotations improve the
> security. You would have to repeat all of our analysis, as well as all
the
> analysis done by other people. That is well over a man-year of work.
The
> second observation is that the extra rotations have a cost in
performance.
> It is not clear that this is the best way to increase the security if
you
> are willing to decrease the performance. On a Pentium-Pro, adding two
4-bit
> rotations to each round would probably cost as much as adding an extra
> round at the end. (This is the trade-off we looked at for the one-bit
> rotations.) The real question becomes: would you rather have 17 rounds
of
> Twofish, or 16 rounds of Twofish-with-extra-4-bit-rotations?
>
> [...]
> > Anyway, these are just idea I came up with. It just seemed that
nobody
> > was doing anything like this. The only reason I picked 4 for the
> > rotates was that you would have 1/2 of each of two bytes determining
the
> > output of an 8xN (or in MARS, 9x32) s-box.
>
> It is very easy to make variations on a cipher. One has to be very
careful
> when doing so; there are many examples in literature of how very minor
> changes can have a negative effect on the security. DES is a good
example:
> almost any small change (such as changing the order of the S-boxes)
weakens
> it.
I understand that it takes time to do the analysis. I just came up with
that thought and felt it warrented attention since I did not see this
type of idea implemented very often. Also, I forgot to mention that my
understanding of MDS matrixes is very limited. I not exactly sure how
they worked.
As for being careful about making minor modifications to algorithms,
that's why I brought this up here. I wanted to throw it out for review
to see what people thought. Perhaps in a future algorithm someone will
use my idea. Maybe not.
>
> > csybrandy.
>
> It is great to see that people are taking an active interest in the
AES
> process. If you have any comments on any of the finalists, I urge you
to
> also submit them to NIST as formal comments. (These are due somewhere
next
> spring.) There is little time for the entire process, and every
> contribution can help in selecting the best standard.
Guess this means I'll have to collect all my postings on the AES
discussion boards.
csybrandy
>
> Niels
>
> =========================================================
> Niels Ferguson, http://niels.ferguson.net/
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Re: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 22:11:56 GMT
In article <[EMAIL PROTECTED]>, this news group unless otherwise
instructed! wrote:
>On Tue, 02 Nov 1999 04:15:14 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> That was an old thread. True a random file tends not to compress.
>>Bad a random file also decompresses to a very large file with my
>>method. Find Clintons last message.
>
>Hmmm... Okay.
>
>Next question: does a random file decompress out to a random file?
well you think if the data is random that a random file when depressed
would give a random file. But it usually decompress to a much large file
so I am not sure what programs that test this resulant file would give you.
My guess is that it will think it is not random but I have not tested this.
>
>Also, how well does this resultant random file from a bad key compress
>with a different compression routine? Could an angle of attack be
>formed by comparing your o-o-o re-compressed data with data compressed
>by a n-o-o-o?
I am not sure just what you mean here.
>
>Because, by nature, your decompressed file will compress back into the
>same file. But, if the resultant decompressed file can't be
>compressed by a n-o-o-o then this tells the attacker something.
I think the assumption is all files compress ( well change) with a
compressor so just what do you mean.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
** 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
******************************
