Cryptography-Digest Digest #657, Volume #12 Mon, 11 Sep 00 18:13:01 EDT
Contents:
Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Rich Wales)
Re: CAST-Cipher / CAST-Algorithm ([EMAIL PROTECTED])
Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Yiorgos
Adamopoulos)
Re: Getting Started, advice needed (FAQs , yes I read them) ("Paul Pires")
Why is TwoFish better than Blowfish? ("David C. Barber")
Re: Getting Started, advice needed (FAQs , yes I read them) ("Paul Pires")
Re: Why is TwoFish better than Blowfish? (Tom St Denis)
Re: Why is TwoFish better than Blowfish? (John Myre)
Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks (Robert H.
Risch)
Re: Scottu19 Broken ("Paul Pires")
Financial Cryptography '01: Final Call for Papers (Paul Syverson)
Problem with Tiger hash algorithm and binary files ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto,us.legal
Subject: Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks
Date: 11 Sep 2000 19:09:51 -0000
[EMAIL PROTECTED] wrote:
> The ``defendant'' [in a Greek trial] starts by calling
> whoever s/he wants. Then the prosecutor. The judge may
> re-examine whoever witness s/he wants.
One big difference between this and the US (also Canadian and British)
legal system is that, in the US, the prosecution goes first. The idea
is that until the prosecution has presented its accusations (together
with evidence and witnesses), there is no case, and the defendant has
no obligation to present anything at all.
On occasion, after the prosecution has finished presenting its case
in a criminal trial, but before the defense gets its turn -- again,
I'm talking about the US here -- if the judge does not believe the
prosecution has a credible case, he/she can call a halt to the trial
and instruct the jury to find the defendant not guilty (called a
"directed verdict of acquittal"). This generally happens only if the
prosecution's case is clearly defective (i.e., even if everything
alleged by the prosecution were true, it still wouldn't be enough to
support a conviction).
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CAST-Cipher / CAST-Algorithm
Date: Mon, 11 Sep 2000 19:09:52 GMT
Hi,
The specification of both CAST-128 and CAST-256 are avalible from
Entrust's website.
http://www.entrust.com/resourcecenter/whitepapers.htm#technical
/ foo
In article <8obpr9$r75$[EMAIL PROTECTED]>,
"Patrick Harenberg" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> can anyone of you send or tell me where to get a good description of
the
> (function of the) CAST-Cypher / CAST-Algorithm (256-bit version
pereferred).
> It would also be great if you coud send me or tell me where to get an
> implementation (C++-source-code preferred) of said cipher / algorithm.
>
> It would be great if you could help me.
>
> Please send your answers to: [EMAIL PROTECTED]
>
> CU
>
> Patrick Harenberg
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Yiorgos Adamopoulos)
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto,us.legal
Subject: Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks
Date: 11 Sep 2000 19:23:28 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Rich Wales wrote:
>[EMAIL PROTECTED] wrote:
>
> > The ``defendant'' [in a Greek trial] starts by calling
> > whoever s/he wants. Then the prosecutor. The judge may
> > re-examine whoever witness s/he wants.
>
>One big difference between this and the US (also Canadian and British)
This is our difference. We can have multiple turns :-) Ususally the
defendant (if it is possible) establishes that he is a credible citizen
who in no way could have done what he is accused of. Then the
prosecutor says ``well he is not such a nice person because ...'' and
they circle around (I am trying to simplyfy things here and if you have
more questions I think I will bring a lawyer in the group :-)
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 12:53:42 -0700
Andy C <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 10 Sep 2000, [EMAIL PROTECTED] (Scott Fluhrer) spake in
> <8phpk5$plr$[EMAIL PROTECTED]>:
>
> >Paul Pires <[EMAIL PROTECTED]> wrote the original break
>
> >Actually, this attack can be strengthened somewhat, in that it can be
> >applied to any block (and, it relies on a known plaintext block, rather than
> >a chosen one as you appeared to have implied). Suppose you know/guess the
> >value of plaintext block 10. Then, you use the above attack to derive the
> >value of tempKey at the start of the encryption of block 10. Then, looking
> >at the last two steps of the iteration for block 9:
> >
> > tempData[counter] = temp1;
> > tempKey = tempKey + temp1 - 26087;
> >
> >or, in other words:
> >
> > NEWtempKey = OLDtempKey + CiphertextBlock - 26087;
> >
> >(where NEWtempKey is the value of tempKey at the start of the encryption of
> >block 10, OLDtempKey is the value of tempKey at the start of the encryption
> >of block 9, and CiphertextBlock is the value of the 9th ciphertext block).
> >
> >The attacker knows the ciphertext for block 9 (tempData[counter]), and he
> >knows the new value of tempKey, and so he can compute the previous value of
> >tempKey. And, he can work his way back to the beginning of the cipher.
>
> And thus recover the starting key? The software I was looking at uses the
> same key for a whole session - so recovering it once allows the whole session
> to be recovered. *BUT* the lifespan of session information usefulness is
> only 2-3 minutes,
Doesn't matter. What is the lifespan of the Key? It is important to note that
the
secrecy of your information is protected by your key but in this system, the key
is only protected by the secrecy of the information. And not very well at that.
This is not good. It doesn't matter what each messages functional lifespan is.
If
you use this system, you must keep it secret as long as the key is used AND
for as long as any information protected by that key needs to be secret, not
just that piece itself.
If you mean that you have a way of securely distributing new keys often enough,
then you have cable TV and plush carpeting in an outhouse. Your encryption
quality
doesn't live up to your key management.
>so this may be a "safe" method, if an "automated" way of
> breaking the keys back is not found.
I just described one. Pancho fixed it. A good programer could write you up
an app from this. Your key in miliseconds if any plaintext is known. a little
longer if plaintext needs to be guessed but this is always much easier than
guessing the key since the plaintext has value, structure and meaning
probably known in a general way to your adversary. If it was random
gibberish, Why hide it? If your adversary is oblivious to your traffic. why
does he worry you? If you want to be safe and assume a worst case, go
all the way and assume he is very formidable and knowledgable.
Maybe even sneaky.
>By the way, in case you are concerned,
> we are not doing anything "illegal" with such a short key and timespan - this
> is for something more on the recreational side of the internet.
>
> Thank you for this explanation of how the algorithm can be reversed from a
> known plaintext block. This begs the question - how does one go about
> guessing a "known" plaintext in any reasonable amount of time? Just trying
> to get the thought processes in my head.
Depends on what the plaintext is and how much you know about it. If it is
known to be common text in english for example, Then you know a lot. Look
for letter frequency, Certain characters commonly followed by others or never
followed by others. Capitalization and punctuation are other big give-aways. If
an adversary knows you start out with some predictable header information.
Date, time, name, ID, settings, then you are well and truely hosed.
>
> Any particular places I should go to read and learn?
Bruce Schneier's book Applied Cryptography is always good general starting
point. I'm sure you'll get a lot more suggestions from folks in here who
actually
know this stuff :-)
Paul
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Why is TwoFish better than Blowfish?
Date: Mon, 11 Sep 2000 13:06:48 -0700
TwoFish is newer, and I would think better, than BlowFish (unless the AES
requirements required a worse cipher), but I've never seen a list of reasons
just why. While I expect that Bruce is the logical person to answer this
(btw, is my 2nd edition Applied Cryptography still the current version?),
even a pointer to a web-page would be fine.
*David Barber*
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 13:15:25 -0700
Andy C <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 10 Sep 2000, [EMAIL PROTECTED] (Paul Pires) spake in
> <U_Yu5.60123$[EMAIL PROTECTED]>:
>
> >Why would anyone brute force the key. It seems to me that if
> >you can be made to encrypt some known material at the
> >beginning of a file, I get your key using only a pencil and
> >paper.
>
> Well, I brute forced it because I'm no cryptanalyst, although I'd love to
> learn enough to at least be an amateur one. Which is what I'm trying to get
> here - an idea of how to go about looking at such a thing.
>
> And pardon the bad source - it has some rather obvious errors that I didnt
> correct in my haste to post. Rather anxious to actually be able to post
> something other than noise to the group...
>
>
> >first tempKey = theKey;
> >
> >> temp1 = data[counter] + tempKey;
> >> temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> >> temp1 = ((temp1 << 23) | (temp1 >> 9));
> >> tempData[counter] = temp1;
> >> tempKey = tempKey + temp1 - 26087;
> >
> >Let's refrase the first cycle:
> >
> > temp1 = plaintext + the honest to god key;
> > temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > temp3 = ((temp1 << 23) | (temp1 >> 9));
> > ciphertext= temp3;
> > tempKey = tempKey + temp1 - 26087;
> >
> >This is reversible.
>
> Thanks for the clarification of the algorithm, I thought as much - I think
> the encode/decode functions are simply inverses of each other using the same
> key. If I have read th FAQ and Schneier right, this makes it symmetric? And
> the "autokey" is where it changes the key based on the data - kind of a
> "chaining" thing?
Symmetric means that it uses the same key to encrypt as it does to decrypt.
What you have here is reversible which is bad, bad, bad. It should use some
processes that are indeterminant in the reverse direction so that it cannot be
profitably run backwards. i.e from ciphertext to Key.
>
> >If I have the first ciphertext block then...
> >temp2 = (Ctext>>23)|(Ctext<<9);
> >temp1= ((temp2+26087)>>19)|((temp2+26087)<<13);
> >
> >If I have just the first plaintext block then:
> >
> >temp1-plaintext = your key...
> >
> >Unless I really screwed up here.
> >
> >Feel safe?
>
> No, and thats good. I had a feeling this could have been rather esaily done
> by someone "in the know".
I'm not worthy. Someone in the know (as opposed to me) would eat
this for lunch and still be starved :-)
>
> Is there a way to actually write a "decode" routine - in other words, what I
> set out to do was creat an "anti-algorithm", one that could be fed a block of
> unknown ciphertext, and spit out the key. I was thinking that was possible,
> but maybe a known or chosen plaintext would be needed. What would you think
> about in terms of doing something like that? Its not really needed, but
> would be a rather neat thing to try to come up with (and show off).
Sounds like a good first project. Don't cheat. Think, reason it out, research,
study
And only ask for help when you are really stuck.
Paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Mon, 11 Sep 2000 20:31:22 GMT
In article <8pje3d$1t1o$[EMAIL PROTECTED]>,
"David C. Barber" <[EMAIL PROTECTED]> wrote:
> TwoFish is newer, and I would think better, than BlowFish (unless the
AES
> requirements required a worse cipher), but I've never seen a list of
reasons
> just why. While I expect that Bruce is the logical person to answer
this
> (btw, is my 2nd edition Applied Cryptography still the current
version?),
> even a pointer to a web-page would be fine.
>
> *David Barber*
Let's see, um Twofish is faster, supports a larger block size, is a
heck of alot more versatile size/speed wise and effectively supports
required key lengths. Twofish can be implemented on anything from 18k
gatearray hardware to a PIII with respective efficiency.
Blowfish is simple, big and effective only on desktop computers...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Why is TwoFish better than Blowfish?
Date: Mon, 11 Sep 2000 14:52:32 -0600
"David C. Barber" wrote:
>
> TwoFish is newer, and I would think better, than BlowFish (unless the AES
> requirements required a worse cipher), but I've never seen a list of reasons
> just why.
The ciphers were designed with different requirements.
(1) Blowfish encrypts 64-bit blocks, while Twofish encrypts 128-bit
blocks. The latter is an AES requirement. I'd guess that Blowfish's
block size is simply to be compatible with other ciphers of the time
(specifically DES).
(2) Blowfish has a very slow key setup, which I *think* is to make
it safer when using short keys (due to export restrictions or to
silly passwords). Part of the AES contest is speed, including
key setup, so "intentionally slow" wouldn't cut it.
(3) Twofish also tries to meet the AES requirement of working well
in restricted environments (e.g., smartcards), which does not appear
to have been a consideration for Blowfish.
Which is "better"? It depends. So far as I know, Twofish is at
least as secure, and at least as fast. On the other hand, Blowfish
is somewhat simpler. In most cases Twofish would be the better
choice, but not always.
> While I expect that Bruce is the logical person to answer this
> (btw, is my 2nd edition Applied Cryptography still the current version?),
Yes.
> even a pointer to a web-page would be fine.
>
> *David Barber*
http://www.counterpane.com/labs.html under Algorithms (left side).
Or is that not what you meant?
JM
------------------------------
From: Robert H. Risch <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto,us.legal
Subject: Re: (Jury Selection) Re: Carnivore article in October CACM _Inside_Risks
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Sep 2000 21:14:21 GMT
On 11 Sep 2000 19:23:28 GMT, [EMAIL PROTECTED] (Yiorgos
Adamopoulos) wrote:
>In article <[EMAIL PROTECTED]>, Rich Wales wrote:
>>[EMAIL PROTECTED] wrote:
>>
>> > The ``defendant'' [in a Greek trial] starts by calling
>> > whoever s/he wants. Then the prosecutor. The judge may
>> > re-examine whoever witness s/he wants.
>>
>>One big difference between this and the US (also Canadian and British)
>
>This is our difference. We can have multiple turns :-) Ususally the
>defendant (if it is possible) establishes that he is a credible citizen
>who in no way could have done what he is accused of. Then the
>prosecutor says ``well he is not such a nice person because ...'' and
>they circle around (I am trying to simplyfy things here and if you have
>more questions I think I will bring a lawyer in the group :-)
Don't underestimate the huge difference in who is asking the
questions. American trials often have 100% of all questions to
witnesses, asked by the lawyers. Also the lawyers, very often, keep
objecting to the questions asked by the other lawyers. There are so
many procedural rules about what and how questions are to be asked
that often, as much time is spent on arguing such things as on
examining the actual evidence. Among the rules, is the ability of a
lawyer to recite a speech to a hostile witness and force him to answer
yes or no as to whether what the lawyer just said is true. The
witness can only explain his answer if a the lawyer on the same side
as the witness later asks him "non leading" questions that are crafted
to refute the former lawyer's speech. Any such thing goes on in a
Greek Court?
RHR
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Scottu19 Broken
Date: Mon, 11 Sep 2000 14:15:03 -0700
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Hmm. It's not common to anonymously spread FUD about someone else's
> technology - and then to subsequently confess (without any sign of
> duress being applied) that you're actually someone with a known
> distaste for the author.
>
> Oh well, full marks for revealing phreakerboyz' identity, anyway.
He got me too. I could kick myself. Look at the following snip
out of PB's post.
(
Oh now I have to give reasons? Nah. NSA likes breaking all crypto
espescially from fanatics.
P/b
Tom
)
Not only did he use his signature phrase "Nah", He signed it.
Paul
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Paul Syverson <[EMAIL PROTECTED]>
Subject: Financial Cryptography '01: Final Call for Papers
Date: 11 Sep 2000 17:50:13 -0400
Final Call for Papers
Financial Cryptography '01
February 19-22, 2000
Grand Cayman Marriott Beach Resort
Cayman Islands, BWI
Original papers are solicited on all aspects of financial data security and
digital commerce in general for submission to the Fifth Annual Conference on
Financial Cryptography (FC01). FC01 aims to bring together persons involved
in the financial, legal and data security fields to foster cooperation and
exchange of ideas. Relevant topics include
Anonymity Protection Infrastructure Design
Auditability Legal/ Regulatory Issues
Authentication/Identification Loyalty Mechanisms
Certification/Authorization Payments/ Micropayments
Commercial Transactions Privacy Issues
Copyright/ I.P. Management Risk Management
Digital Cash/ Digital Receipts Secure Banking Systems
Economic Implications Smart Cards
Electronic Purses Trust Management
Implementations WaterMarking
INSTRUCTIONS FOR AUTHORS: Electronic submission strongly encouraged.
(Instructions available at http://www.fc01.uwm.edu). Alternatively,
send a cover letter and 15 copies of an extended abstract to be
received no later than October 13, 2000 (or postmarked by October 6,
2000 and sent via airmail) to the Program Chair. The extended abstract
should start with the title, names of authors, abstract, and keywords
followed by a succinct statement appropriate for a non-specialist
reader specifying the subject addressed, background, main
achievements, and significance to financial data security. Submissions
are limited to 15 single-spaced pages of 11pt type and should
constitute substantially original material. Panel proposals are due no
later than November 27, 2000 (or postmarked and airmailed by November
20). Panel proposals should include a brief description of the panel
and a list of prospective panelists. Notification of acceptance or
rejection of papers and panel proposals will be sent to authors no
later than December 8, 2000. Authors of accepted papers must
guarantee that their papers will be presented at the conference and must
be willing to sign an acceptable copyright agreement with Springer-Verlag.
Use the above address for electronic submissions or send hardcopy to:
Paul Syverson, FC01 Program Chair
Center for High Assurance Computer Systems (Code 5540)
Naval Research Laboratory
Washington DC 20375 USA
email: [EMAIL PROTECTED]
Web: www.syverson.org
phone: +1 202 404-7931
PROCEEDINGS: Final proceedings will be published by Springer Verlag in
their Lecture Notes in Computer Science (LNCS) series. Preproceedings
will be available at the conference, but final versions will not be
due until afterwards, giving authors the opportunity to revise their
papers based on presentations and discussions at the meeting.
Program Committee
Matt Blaze, AT&T Labs - Research
Yair Frankel, Ecash
Matt Franklin, UC Davis
David Kravitz, Wave Systems Corp.
Arjen Lenstra, Citicorp
Philip MacKenzie, Lucent Bell Labs
Avi Rubin, AT&T Labs - Research
Jacques Stern, Ecole Normale Sup�rieure
Kazue Sako, NEC
Stuart Stubblebine, CertCo
Paul Syverson (Chair), Naval Research Laboratory
Win Treese, Open Market, Inc.
Doug Tygar, UC Berkeley
Michael Waidner, IBM Zurich Research Lab
Moti Yung, CertCo
Important Dates
Extended Abstract Submissions Due: Oct. 13, 2000
Panel Proposal Submissions Due: November 27, 2000
Notification: Dec 8, 2000
Electronic submission information:
See http://www.fc01.uwm.edu
General Chair
Stuart Haber, InterTrust STAR Lab
Electronic Submission chair
George Davida, UWM
Further Information about conference registration and on travel, hotels, and
Grand Cayman itself will follow in a separate general announcement. FC01 is
organized by the International Financial Cryptography Association.
Additional information will be found at http://fc01.ai
------------------------------
From: [EMAIL PROTECTED]
Subject: Problem with Tiger hash algorithm and binary files
Date: Mon, 11 Sep 2000 21:55:06 GMT
Does anyone have a C routine to produce a hash on an arbitrary file
using the Tiger algorithm? The distribution (I downloaded it from
http://www.cs.technion.ac.il/~biham/Reports/Tiger/) provides no main C
routine, only a test program.
I wrote one (pretty ugly but see buffer.c below) on a Sun Sparc running
Solaris 2.5.1 to read a file into an array and hash its value, but I ran
into the following ugly (newbie most likely) hurdle:
First, I am reasonably confident that the routine works on plain text
files, for I created several sample files - each contained a sample
string as shown in the 'testtiger.c' test program that accompanyed the
distribution - and the resultant hash is identical in each case.
However, it appears that the routine fails on arbitrary files, viz.
binary files. For example, when reading a binary file into an array, the
first null character (0) encountered will terminate the string (array).
As a typical example, if I run something like: `od -c /bin/ls`, I can
see that character 7 is a null. Of course, as soon as this character
gets put into the array, you can forget about anything else getting
appended. It's now termianted! Consequently, the array that I pass to
the tiger hash will now contain only the characters up to where it
terminated. This will obviously result in the wrong hash for the given
file. As far as I can tell, the tiger hash *WANTS* an array of
characters.
Is there some magic way of getting around this? Should I be passing
these pieces in one chunk at a time, and if so, how can I implement
this? What is the syntax required, and how will the routine know when to
spit out the hash? Also, if passing in in chunks, will I not be missing
the 0's that terminated each given string since each 0 will be
interpreted as the end of its respective string and not the last
character in the string?
If anyone has figured this out, or could offer any help, life would be
much better!
Thanks
George | [EMAIL PROTECTED]
Compiled code as: make testtiger (creates tiger.o, testtiger and
sboxes.o)
Next, ran gcc -o buffer buffer.c tiger.o sboxes.o
/* buffer.c - Reads a file into a buffer (array) and hashes the array */
#include <stdio.h>
#include <fcntl.h>
typedef unsigned long long int word64;
typedef unsigned long word32;
typedef unsigned char byte;
void tiger(byte*, word64, word64*);
main(int argc, char *argv[])
{
char *buffer;
FILE *fp, *fopen();
word64 res[3];
long count = 0;
long i = 0;
int c;
/* Ensure user is providing a file name */
if (argc == 2)
{
/* open file */
if (( fp = fopen(argv[1], "r")) == NULL)
{
printf("Can't open %s.\n", argv[1]);
exit(1);
}
else /* Determine number of characters in this file */
{
/* Grab a single character until end of file */
while ((c = getc(fp)) != EOF)
{
count++;
}
count--;
fclose(fp);
}
}
else
{
printf("Incorrect number of arguments\n");
}
/* Allocate a proper buffer space based on our count. */
buffer = (char *) malloc(count);
/* Re-open our file */
if (( fp = fopen(argv[1], "r")) == NULL)
{
printf("Can't open %s.\n", argv[1]);
exit(1);
}
else
{
/* While not end of file, read a single character and add to buffer
*/
while ( feof(fp) == 0)
{
buffer[i++] = getc(fp);
}
}
i = i - 2;
buffer[i] = '\0'; /* Terminate array (string). */
#define hash(str) tiger((byte*)str, strlen(str), res); \
printf("%08X%08X %08X%08X %08X%08X\n", \
(word32)(res[0]>>32), \
(word32)(res[0]), \
(word32)(res[1]>>32), \
(word32)(res[1]), \
(word32)(res[2]>>32), \
(word32)(res[2]) );
hash(buffer);
}
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
