Cryptography-Digest Digest #682, Volume #9 Wed, 9 Jun 99 17:13:05 EDT
Contents:
Re: rc4 vs. rand() (Andrew Haley)
Re: being burnt by the NSA (Patrick Juola)
Re: Blowfish or RC4/5 in Visual Basic (Roger Carbol)
Re: being burnt by the NSA (Gordon Grieder)
Re: Challenge to SCOTT19U.ZIP_GUY (Lincoln Yeoh)
Re: CRC32 (Jerry Leichter)
Re: faster exponentiation with data compression techniques (root)
Re: File Wiping Question (Sundial Services)
question about original RSA research ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY (Andrew Haley)
Re: being burnt by the NSA (Greg Bartels)
Re: Looking for a password encryption algorithm (Ari
=?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?=)
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: being burnt by the NSA ("Renegade")
Re: DES (Paul Koning)
Shared secret protocol (Logic)
Re: being burnt by the NSA ("Douglas A. Gwyn")
Re: being burnt by the NSA ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: rc4 vs. rand()
Date: 9 Jun 1999 14:04:38 GMT
[EMAIL PROTECTED] wrote:
: > If you're going to make a lot of money then feel free to make
: > a donation to Ron Rivest.
: And I will steal your program, and may make a donation...
: I personally think that using the cipher in non-profit situations
: should not be an issue (consider free chat rooms etc...) but in
: commercial situtations I think paying up is an honest thing todo.
Why? Do you not think that if RSA had wanted RC4 to be unfree they
would have patented it?
: Of course we can always use free ciphers can't we?
In what way is RC4 unfree?
Andrew.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: being burnt by the NSA
Date: 9 Jun 1999 10:07:40 -0400
In article <[EMAIL PROTECTED]>, Greg Bartels <[EMAIL PROTECTED]> wrote:
>I bought a book, a couple months ago, its title was
>"Breaking DES",
>
>it contains VHDL code (in a scanner/OCR friendly format, no less)
>which compiles to build a DES cracking machine.
>The claim was that the machine would cost $200,000 to build
>and would recover a DES key within 2 weeks.
>
>really fuzzy on the specifics, going from memory.
>exact title, cost claims, and cracking speeds may differ
>from actual reality.
>
>I'll look it up tonight.
Ooooh, *BAD* title. Most people don't regard exhaustive enumeration
of the DES keyspace as a "break", simply because the keyspace is so
obviously small and DES is so obviously being used past its designed
lifetime.
As it happens, I believe that Linear Cryptanalysis (discussed briefly
in Schneier's _Applied Crypto_) constitutes a "break" in the more
accurate sense; it's requires less work to break a DES key via
LC than via brute force.
But, as was pointed out earlier, there's always 3DES...
-kitten
------------------------------
From: Roger Carbol <[EMAIL PROTECTED]>
Subject: Re: Blowfish or RC4/5 in Visual Basic
Date: Wed, 09 Jun 1999 15:46:32 GMT
Pontus Hanserkers wrote:
> Is there anyone out there that have an working Blowfish or RC4/5 code in
> Visual Basic.. I tried to code it my self but my cryptography skills
> are pretty low, so I never got it working..
Yes! Check out my Blowfish DLL, written in Visual Basic
for Visual Basic. It can be downloaded from
<ftp://ftp.replay.com/pub/replay/pub/crypto/LIBS/blowfish/BLOFSH10.ZIP>
And it's entirely free.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: Gordon Grieder <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 09:49:35 -0500
[EMAIL PROTECTED] wrote:
>
> > You also neglected to mention SHA-1, which is an NSA product and is
> > widely respected and trusted in the open-literature community.
>
> This is true. I am sorry Mr. NSA. I live in Canada what have they
> done for *me* lately? :) (Well in canada we have our Ceciss or
> something like that. Basically they are the unknown secret agents in
> Canada. Woowee!).
>
Tom,
It's CSIS (Canadian Security Intelligence Service)
http://www.csis-scrs.gc.ca/
I suggest reading Spyworld by Mike Frost, an ex-CSIS employee. It's
fascinating reading from a man in the field.
http://www.amazon.com/exec/obidos/ASIN/0385254946/qid=928939241/sr=1-70/002-3162625-3271835
back to lurking...
--
Gordon Grieder
[EMAIL PROTECTED]
http://www.grub.net "Purveyors of Fine Crud."
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Wed, 09 Jun 1999 15:17:19 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 07 Jun 1999 14:28:29 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
wrote:
> This means the code for building the tables may really
>be hardwired for the PC since who knows what those
>bits are really used for. Yes Oliver I think you find what
>we use to call on the Univac as a "feature" and I will
>fix it. Yes it was not my intension to write out of the
>rt area. So it is an error. But how many of you have written
>a program this long with out a printer and not made any
>errors.
This is one of the reasons we would like to know WHY you are doing certain
things.
Because without any "Why"s it is a lot more effort guessing whether certain
things are intentional features or unintentional "features".
A description of your algorithm and specifications would help.
If more people understood what you are trying to do, then they can possibly
appreciate it and maybe even give good suggestions from improving it.
Checking source code without comments and specifications is like asking us
to check an engine for flaws without any blueprints and specifications.
People may find the engine runs slowly, but then is it supposed to run slow
or is something wrong? A bad engine or is it a bad design? Without
specifications or blueprints it's hard to tell. Might be a normal tractor
engine for all we know.
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Jerry Leichter <[EMAIL PROTECTED]>
Subject: Re: CRC32
Date: Wed, 09 Jun 1999 13:01:02 -0400
| ...No CRC is secure (in the sense of a "secure hash")...
This is true, but it's worth pointing out a subtlety: A *secret* CRC
polynomial provides a primitive related to (but by no means the same as)
a secure hash. Rabin has an old paper on this called something like
"Fingerprinting with Random Polynomials". Basically, if you choose a
CRC polynomial suitably (from among primitive polynomials? - the exact
condition escapes me, but there are simple, efficient ways to do it) and
compute an n-bit "fingerprint" of a piece of data using that polynomial,
then an attacker has essentially a 1 in 2^n chance of being able to
construct a different piece of data with the same fingerprint.
If the attacker knows the polynomial constructing the different piece of
data is trivial. Also, if you reveal more than a few data/fingerprint
pairs based on the same polynomial, an attacker can learn what the
polynomial is. (Even revealing one data/fingerprint pair gives away
some information, perhaps too much.)
Rabin's proposed use is that you select your polynomial at random, keep
the fingerprints secret, and use them later to detect alteration.
Of course, these days you would probably use a secure hash function,
which doesn't require keeping the fingerprints secret. (On the other
hand, the security in Rabin's scheme is easily provable; the security of
secure hash functions is still based on faith.)
-- Jerry
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Re: faster exponentiation with data compression techniques
Date: 9 Jun 1999 17:06:35 -0000
Hi,
Can't help you with the articles I'm afraid, I'll check next time I
visit the uni library.
I would however like a copy of you're source if you're willing to share
it. (I'm doing some research into compression and the second title on
your wishlist intrigued me, allthough the source may not have much in
common with paper number two I'd like to see if I could find some
connections myself.) If you happen to have a digital copy of [1] I'd
like a copy of that too...
Thanks in advance,
Ebo.
Pedro FXlix wrote:
>
> I've been reading the paper
> [1] "Exponentiation in finite fields: theory and practice" by J. von sur
> Gathen et all.
>
> This reference discusses a couple of algorithms for the contructions of word
> chains with a minimal number of steps, using dictionary techniques from data
> compression, namely the ones proposed by 1) Yacobi and 2) Bocharova &
> Kudryashov.
> In this context I would like to read the papers:
>
> I. Bocharova and B Kudryashov,"Fast exponentiation in cryptography", ...
> I. Bocharova and B Kudryashov,"Fast exponentiation based on data
> compression"
>
> Unfortunately I don't have acess to any of the sources.
> Does any one knows of electronically available copies of any of these
> papers.
> Any extra information on this subject would be welcomed, namely more recent
> results.
>
> In the context of [1] I'm implementing the algorithms
> Brauer (another name for the m-ary method), Yacobi, Bocharova and lookback
> for the construction of the dictionary D and word chain W' for D given a
> word chain w in D*. The main purpose is the evaluation of these algorithms
> in specific contexts (word lengths, probability distributions of the sourse,
> ....)
> I'm doing it in C++ using STL containers and algorithms, so it is rather
> simple to read.
> I would be happy to share it with any one interested.
>
> Thanks
>
> P. Felix
------------------------------
Date: Wed, 09 Jun 1999 07:52:19 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: File Wiping Question
Albert P. Belle Isle wrote:
> All the afore-mentioned disk wiping functions are really only needed
> because most commercial software doesn't take such precautions,
> including the Windows operating system.
>
> (Since NT zeroizes objects on re-allocation, they are still filled
> with old data while sitting on disk waiting for that re-allocation.
> Any attacker connecting to the disk containing the volume as a slave
> drive can thus read it. Only users constrained to use the host's copy
> of NT are kept from such pre-zeroizing access. That's one reason that
> physical security of the machine is required for even the lowly C2
> certification of NT.)
It has always astounded me that an operating system cannot be bothered
to use a simple "REP STOSB" instruction to zero out the remainder of a
cluster before writing it to disk! :-/ Even the original DOS could
easily have afforded to do that!
------------------------------
From: [EMAIL PROTECTED]
Subject: question about original RSA research
Date: Wed, 09 Jun 1999 16:33:39 GMT
I'm a student of computer science and I'm doing a research about
RSA. If anybody knows were can i find some info about the original!!
research done to invent RSA, or info about the first product related
with RSA , or any info about the original research please send me email
Thanks in Advance
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Andrew Haley)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: 9 Jun 1999 17:45:13 GMT
SCOTT19U.ZIP_GUY ([EMAIL PROTECTED]) wrote:
: In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
: >Tim Redburn wrote:
: >> Do you understand what is being asked yet ?
: >
: >My suggestion is that he read *and understand* the classic book,
: >"The Elements of Programming Style" by Kernighan & Plauger, or the
: >recently published "The Practice of Programming" by Kernighan & Pike.
: I have been a programmer for over 30 years.
What can I say about someone who has been a practitioner for 30 years
yet is still incompetent? If you read and understood Kernighan &
Plauger you might become a good programmer.
The code you've published so far is abysmal.
: I could give a dam what they say about style.
I presume this means that you "couldn't give a damn"?
: Style is just a tem used so that programmers who can' program waste
: a lot of paper and then management is under the illusion that they
: porduces something. Style is used to force creative programs in a
: mold that they don't need.
And how would you know that?
Andrew.
------------------------------
From: Greg Bartels <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 14:15:03 -0400
Patrick Juola wrote:
>
> In article <[EMAIL PROTECTED]>, Greg Bartels <[EMAIL PROTECTED]> wrote:
> >I bought a book, a couple months ago, its title was
> >"Breaking DES",
> >
> >it contains VHDL code (in a scanner/OCR friendly format, no less)
> >which compiles to build a DES cracking machine.
> >The claim was that the machine would cost $200,000 to build
> >and would recover a DES key within 2 weeks.
> >
> >really fuzzy on the specifics, going from memory.
> >exact title, cost claims, and cracking speeds may differ
> >from actual reality.
> >
> >I'll look it up tonight.
>
> Ooooh, *BAD* title. Most people don't regard exhaustive enumeration
> of the DES keyspace as a "break", simply because the keyspace is so
> obviously small and DES is so obviously being used past its designed
> lifetime.
>
> As it happens, I believe that Linear Cryptanalysis (discussed briefly
> in Schneier's _Applied Crypto_) constitutes a "break" in the more
> accurate sense; it's requires less work to break a DES key via
> LC than via brute force.
>
> But, as was pointed out earlier, there's always 3DES...
>
> -kitten
1) I'll double check the title tonight, so that might be
inaccurate.
AM I THE ONLY PERSON WHO"S HEARD OF THIS BOOK?
or is the book a load of bull?
2) $200,000 to get any DES key in 2 weeks, may or may not be
considered "breaking DES", but if you happened to be in the
buisness of breaking, say, bank keys, you could probably
recover you're money within the year.
3) I think it might have mentioned that further improvements
would make the system both cheaper and faster.
they gave specifics, but I cant remember what they were.
I seem to remember the book saying recovery time could
be a couple days.
If I remember, I'll look it up tonight.
waiting for iButtons with megabit one time pad storage,
a 8+ character password to decrypt the OTP, and a USB port to
upload/download the key. I'll give one to each of my friends.
Greg
------------------------------
From: Ari =?iso-8859-1?Q?V=E4h=E4=2DErkkil=E4?= <[EMAIL PROTECTED]>
Subject: Re: Looking for a password encryption algorithm
Date: Wed, 09 Jun 1999 10:13:14 +0300
Paul Koning wrote:
>
> Try any good crypto hash (MD5, SHA-1, etc.)
Any good trying to add crypt like salt to shuffle results around? If I have
understood correctly, given the same input the various hashes will produce
the same result.
> > This is the situation: The passwords are to be stored in a database and
> > the client software will access the database via server programs.
> > Unfortunately the server programs are stateless, therefore a real
> > key-exchange type protocol cannot be implemented.
>
> And of course, since it's stateless, it can't be secure...
Well, yes. But that's the way it is. I have met with the original designers
of the system and asked about all these "features". I have not received any
answers.
> > The communications medium
> > cannot be considered secure, although non-authorized clients (or client
> > programs) are not a problem.
>
> It's not secure but unauthorized clients aren't a risk? So what
> ARE the risks?
For example this: an administrative application produces a view to the
error log of the system. As part of the elaborate error information, the
transferred message is stored and shown. And when dealing with plaintext
passwords... you guess the rest.
Basically, the whole system is used within a very strict private networking
environment. A lot could be done, but at the moment not much is required. I
would not talk about security and this system in the same sentence, but the
users do. And pay.
Ari
--
*******************************************************
Ari Vähä-Erkkilä Consultant, Twin Systems Oy
Office: +358-(0)9-5840 4815 [EMAIL PROTECTED]
Mobile: +358-(0)40-586 6980 [EMAIL PROTECTED]
Fax : +358-(0)9-176 718
*** http://www.twin.fi/ *** http://www.iki.fi/vake/ ***
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Wed, 09 Jun 1999 18:27:24 GMT
[EMAIL PROTECTED] wrote:
> > would it make sense to use a block cipher (like DES) on the
> > 8x8 box? (or maybe the key, at the same time expanding it to
> > 256 bytes?) It looks like it might prevent some bad keys from
> > hurting the algorithm...
Tom, please stop stealing other people's writing. This needs
a "Particle wrote:" in front of it. Doesn't Dejanews put the
citation there for you?
> No the sbox must form a function.
Please stop using terms who's meanings you do not know.
Given Particle's scheme, the s-box does form a function.
For for RC4 to work as intended the the s-box must meet
the stronger criterion of forming a permutation of the
integers [0..255].
> The shuffle algorithm is the
> simplest method to form a highly non linear function.
Please stop fabricating results. The RC4 shuffling method
is simple and vastly outperforms the Two-deck shuffling
technique. But we've no reason to say it's the simplest
in general.
Sorry if you find this insulting, but all of the noted
problems appear often in your huge volume of posts.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: rc4 vs. rand()
Date: Wed, 09 Jun 1999 19:00:21 GMT
In article <7jmblu$r6u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Please stop using terms who's meanings you do not know.
> Given Particle's scheme, the s-box does form a function.
> For for RC4 to work as intended the the s-box must meet
> the stronger criterion of forming a permutation of the
> integers [0..255].
This a function!!! If the table forms a 1:1 mapping of inputs to
outputs the table is a function.
> Please stop fabricating results. The RC4 shuffling method
> is simple and vastly outperforms the Two-deck shuffling
> technique. But we've no reason to say it's the simplest
> in general.
I never said twodeck (I made the assumption that it was good so I could
cover other areas...). RC4 is by far the simplest method I have seen,
in fact I would be interested in seeing other methods.
> Sorry if you find this insulting, but all of the noted
> problems appear often in your huge volume of posts.
No problem. But the sbox does form a function. It can be inverted.
The contents of the sbox is a permutation of 0..255, but when you use
it like y = f(x) -> y = sbox[x] is the same idea.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Renegade" <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 9 Jun 1999 15:03:28 -0500
> The total US national foreign intelligence program budget is about
> $27 billion, of which about $3.1 billion goes to CIA and about
> $3.6 billion goes to NSA. NRO gets about $6.2 billion.
What is the source? Are budgets public information now? This looks like a
shell game to me, those numbers seem to be way out of whack.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Wed, 09 Jun 1999 11:04:48 -0400
[EMAIL PROTECTED] wrote:
>
> > DES;
> > 1 That initial permutation; is it actualy worth anything
> > cryptograpicaly?
>
> No, according to AC they are used to optimize hardware implementations.
That's the commonly-quoted excuse but I know of no
reason why it is valid.
> Many software implementations skip it.
Not if they are DES they don't. You can build a proprietary
cryptosystem that isn't DES but is just as strong by leaving
out IP/FP, but if you want it to be DES you have to include
those stupid things. Fortunately, there are ways to do it
in software that aren't all that expensive. Eric Young has
a nice one in his DES implementation. (Reading it will give
you a major headache trying to figure it out, though... :-) )
paul
------------------------------
From: [EMAIL PROTECTED] (Logic)
Subject: Shared secret protocol
Date: 9 Jun 1999 15:10:34 -0500
I am looking for a particular shared secret protocol which I have not seen
described in any literature I have. I would appreciate any comments,
pointers or discussion. I describe the basic setup and the requirements,
followed by a boring solution to serve as a reference.
OVERVIEW
========
We have several people who must have remote access (using a personal
password) to a database containing secrets. People are occasionally added
and removed from the list of users authorized to access this database.
Similarly, secrets in the database are occasionally added, changed, or
removed.
I have sketched a list of requirements below. I consider those marked
with a "*" to be advantages, but not strictly necessary.
REQUIREMENTS
============
1) A complete compromise of the server, and consequently the database,
should not reveal the secrets stored in the database, either by direct
extraction or by snooping network traffic, processes, etc.
2) No sensitive information should travel in plaintext across the network
as users access this database or when users or secrets are added, deleted,
or changed.
3) No authorized user, including the database administrator, should be
able to determine another authorized user's database access password.
4) No user should be able to access the database once he is no longer
authorized (obviously).
Note: In practice, the secrets stored in the database are passwords to
other machines. When a user's access to the database is removed,
naturally the passwords will be changed. To avoid confusion, I will
continue to call these stored passwords "secrets".
5) Changing the secrets in the database should require no action on the
part of the users except, of course, the administrator.
* 6) The authorized users should not be required to "carry around" a key
with them. They should be able to access the database from any terminal
with the client software installed, knowing only their database access
passwords.
* 7) The system should not depend on a higher (e.g. SSL) layer of
transport protection or authorization when a user accesses the database.
EXAMPLE SOLUTION
================
This is the basic (read: boring), straightforward public-key
implementation that you would probably expect, but I present it here for
discussion purposes. Consider it only a sketch to convey the general idea.
I haven't worked out the details. I used RSA as the public-key scheme in
this example.
Each of (n) authorized users has a personal RSA key. On the server is
stored each user's N and encryption exponent e.
Each user's N, d, and e are chosen as follows. Each user generates a
unique N. Then, he chooses an access password which he will later use to
access secrets stored in the database. This password is hashed in some
way to create a sufficient decryption exponent d. The encryption exponent
e is then determined from this d. e and N are then sent to the server by
some secure process I have yet to determine.
The database administrator then encrypts each secret with the new user's N
and e, and stores these encrypted secrets in the database.
When a user wishes to get these secrets, he uses a terminal equipped with
the client software to send his username to the server. The server then
sends back a list of secrets, each previously encrypted under the user's
RSA key. The server also sends the N part of the user's RSA key. Then
the user enters his password to the local client software, which hashes it
to determine the decryption exponent d. The client software then decrypts
and displays the plaintext secrets to the user.
When a secret is changed, the database administrator simply uses each
user's stored N and e to encrypt the new secret, replacing the old
encrypted secret entries for each of the users.
When a user's access is removed, the database administrator simply removes
his RSA key from the server, deletes his entries in the database, and
creates new secrets using the method described above.
ANALYSIS
========
As I said above, this is a straightforward implementation. It meets the
requirements. Naturally, many little details would have to be worked out,
and checks placed in the process, but it will work.
This scheme has the disadvantage of requiring a large number of database
entries to be stored on the server (one for each user/secret combination).
It has the smaller disadvantage of requiring many public-key operations
when secrets are changed or fetched.
So, I am looking for a solution which does not have these disadvantages
but still meets the requirements. Does such a system exist? I would
appreciate any futher analysis on my example system, or pointers to better
systems.
Thank you.
- Andy Brown
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 20:56:02 GMT
Patrick Juola wrote:
> Ooooh, *BAD* title. Most people don't regard exhaustive enumeration
> of the DES keyspace as a "break", simply because the keyspace is so
> obviously small and DES is so obviously being used past its designed
> lifetime.
> As it happens, I believe that Linear Cryptanalysis (discussed briefly
> in Schneier's _Applied Crypto_) constitutes a "break" in the more
> accurate sense; it's requires less work to break a DES key via
> LC than via brute force.
The working cryptanalyst regards a system as broken when he can
recover plaintext and/or key with a reasonable expenditure of
resources, under circumstances that occur reasonably often.
In that sense, DES was only broken recently (so far as the public
knows), via the machine decribed in the EFF book "Cracking DES".
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 20:57:04 GMT
Greg Bartels wrote:
> AM I THE ONLY PERSON WHO"S HEARD OF THIS BOOK?
> or is the book a load of bull?
If you're talking about "Cracking DES", the machine was built
and does work.
------------------------------
** 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
******************************
