Cryptography-Digest Digest #634, Volume #9 Tue, 1 Jun 99 21:13:02 EDT
Contents:
Re: The BRUCE SCHNEIER Tirade (Tim Redburn)
Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: bareface ratio (DJohn37050)
Re: bareface ratio (the psychology of newsgroups) (Sundial Services)
Re: Reasons for controlling encryption (Sundial Services)
Re: Generating Random Numbers ("Grimace")
Re: PGP Key security? (Bill Roberts)
Re: bareface ratio (Jerome O'Neil)
random numbers in ml ([EMAIL PROTECTED])
ECM factoring question (Logic)
Re: Paper on Making Usenet "unerasable"? (Markus Kuhn)
Re: Obscure Code (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Tue, 01 Jun 1999 21:58:47 GMT
On Sun, 30 May 1999 02:11:14 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
>Redburn) wrote:
>>If you believe that a OTP is generally practical, why would
>>anyone have a need to use SCOTT19u.zip ?
>
> They don't have. As some one once said you only have to die and
>pay taxes and there are some who don't even pay taxes/
>
I didn't mean they would be forced to, but you cliam your encryption
product to be the best around and anyone with a need for security, who
has any sense, should be using it, but what I suggest is as follows.
The practical proplems of using scott19u.zip are similar if not
identical to the problems of using a OTP, and therefore if someone
finds a practical use for scott19u.zip then they would be better
off going for the proven OTP.
>>Any way, isn't the maximum key length of SCOTT19u.zip the
>>same as the maximum file length it can encrypt ?
>
> Tim no the maximun length is a function of your virtual memory. On
>a 4 meg machine I have encrypted files 8 megs in lenght
>
My mistake, I trawlled through the source for half an hour to confirm
this.
Please, please, please, please, please, please, please can you release
a tidied up version of the source that can be easily read by a human -
at the very least use descriptive variable names - these are tokenized
by the compiler so long names won't affect the running of your
program, but it will make the source a heck of a lot easier to read.
The macros used for the 19bit access also make it extremly hard
to read, but add nothing to security - the NSA, MI6 , DFS, and other
gourps (only joking on the DFS one before any complains) would give
new recruits the task of 'deciphering' your source and then
it would probably only take a few days to crack your algorithm
(Yes - that is my opinion based solely on the fact that you, the
designer, couldn't accurately determine the
effective key length of your own algorithm)
>>
>>In effect, if you want to use SCOTT19U.zip at it's
>>maximum strength, then you have all the problems of a OTP, ie a huge
>>key that needs securely transmitting, storing or remembering,
>>with the added bonus of *provably* less security.
>>
>
> Actally if you want to use it at full strength the keyenc.key file is
>a little over one meg in size. however there are many ways to send
>portions of text that can be use for the key. But as other methods
>you still would need some sort of key sequence to use to unlock the
>key. IF it becomes comprimised you need a new key.
> But it is not a OTP you can use the same key several times
>so don't confuse the two.
>
Every time you reuse a key, you double the amount of information
that an attacker has as to the value of the key. With all your
paranoia over security, million bit keys, etc, I would have thought
that reusing a key would be the last thing you would do.
As far as I can tell, but for the reasons mentioned above - ie
hard to read source code, I can't be sure, I think that the
main security of scott19u.zip lies in substituting from the
key dependant S-Box.
If that is the case, then the more blocks the key is reused
on, the more chance of patterns showing up.
>>If you disagree with these comments please explain the following:
>>
>>1. How does someone use scott19u.zip for email communication and
>> how does this differ, in practical terms, from using a OTP for the
>
> I use it with my son we don't have problem. I encrypt then pkzip the
>file so that it gets bigger and mail the file like any other zip file. He
>then unzips the file so it gets smaller and then decodes it.
>I have not changed keys with hin for at least a year so unlike an OTP
>we don't need a new key and we don't need to keep track of where
>we are if we where using a long key
>>
>> same purpose ?
Not really convenient, is it ?
>
>>
>>2. How does someone use scott19u.zip for hard disk file encryption,
>> and how does this differ, in practical terms, from using a OTP for
>>
>> the same purpose ?
>
> You should get the program it only encrypte files so not sure what
>you are trying to get at.
>
Apologies, I didn't state it very clearly, I meant encrypting single
files on a hard disk, as opposed to email where there is a sender /
receiver.
Becasue of the size of the key, it is not possible to memorize it, so
some means of securely storing it is necessary. most people
have only small amounts of information that needs really securely
storing (ie their bank details, medical records, emails etc, in which
case if they have a way of securely storing the scott19u.zip key, then
why not just use that means to store the data they need securing.
Also,long keys, while offering potentially high security (dependant of
course on many other factors), have to be stored somewhere.
They are then vulnerable to searches by police with search warrants,
MI6 etc sneaking into your house etc. While 128bits might not offer
huge security (dependant on your opinion) they are at least
memorizable and if handled properly, ie not written down, they are
secure from search warrants, intruders etc.
>
>>
>>3. Is there a situation I haven't thought of where scott19u.zip is
>> practical but a OTP isn't? If there is please describe it.
>
> I can't read your mind but if it is very close and narrow it would
>be a waste of both our time so say where it can be used and where
>it can not. You should have the brains to know when an OTP is best
>and when it is not.
>
Is there a situation where scott19u.zip is convenient, (and I
don't just mean to the NSA, MI6, DFS etc) ?
>>
>>I presume that because you accept a OTP's provable security,
>>then you would agree that where practical, a OTP should be used.
>
> Yes where practical that is where a OTP should be used. By
>defination. I gave examples in other posts that you have read so
>no need to repeat them.
>
I'm writing this offline, because phonecalls in the UK are charged
on a time basis, and I can't afford to spend a longtime online
searching deja news for bits and pieces of useful information
buried deep within your usual rantings. If you separated
your posts into two sections, a facts section and a rants and
raves section, it would help ..... well, it's just a suggestion....
If you think people should use your algorithm then you should give
them all the information they need, whenever they ask for it nad
even when they don't -but only if it's genuine.
There could be some newbie reading this now that is thinking
of seriously using scott19u.zip .........deep breath.......and they
may need to know these things, who hasn't had the luxury
of past posts, and who is also in the same position as me and
many others in the UK over phone call charges.
>
>>
>>Just one final question .......... why use scott19u.zip ?
>
>
> I suppose the best reason to use scott19u.zip is when one needs to
>encrypt files for his self that he does not want some one else to read or
>if you have a close friend or two banks for file data being changed it is
>quite useful. "the all or nothing feature" insures that if you recevie a file
>then you either get the whole thing or none of it. This would be a great
>help so mistakes are not made when decoding inferior methods you can
>get errors in the middle of files so that one thinks the file is ok. But it is
>not. Of course there are other ways to send CRC or checksums but if
>your going to encrypt you might as well do at all in one with out adding
>extra words for a checksum. Or you could get double confidence add
>your checksum in file and use scott19u for the whole thing. Hay if you
>don't like it don;t use it.
Don't worry, I'm not using it, I'm just looking forward to the day
that someone actually manages to 'decipher' your source code
and show that it is less secure than blowfish........ I believe it's
only a matter of time, that time period being determined by how
soon you *********stand up to the challenge******* and
provide clear easily readable source code, (with the exception
of yourself, not one person that I know of has had any positive
comments to say about the readability of your source code by humans),
or .....better still.... provide a clear concise description of the
algorithm (ignore file handling and any other parts not directly
related to cryptography), in such a way the somebody could implement
the algorithm itself in their own apps.
Oh well........ heres to dreaming ....... I'm sure all these things
have been requested before.........well.... if you're too scared to
rise to the challenge .........thought so ........ carry on handwaving
and insulting all those that are trying to help you.
> And as you know every day on this form I jump to say hay this is a good
>place to use it. So don't act dumb I am not going to type pages and pages
>of stuff
>
Please remind me of those places ......I haven't got time to go
through your past posts to extract them.
- Tim.
>
>David A. Scott
>--
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Challenge to SCOTT19U.ZIP_GUY
Date: Tue, 01 Jun 1999 21:58:49 GMT
========================================================================
**** Some Background info for Newbies ****
========================================================================
David A Scott released an algorithm
he called scott19u.zip. He has made many
claims about the security his algorithm
offers.
However after being available for
quite some time now, no-one has yet shown
it to be insecure. Paul Onions did show
a known plaintext attack (I don't know the
details), but David modified his algorithm
to avoid this attack.
Usually, if an algorithm has not been broken
for a couple of years, then people start to consider
it to be secure. However, this is not the case
with the scott19u.zip algorithm.
Why's that ? Well, no accurate concise
descrption of the algorithm has been provided
by the designer. He claims the source code
is there and this is the best description that anyone
could possibly have. If you think he may have a
point here, it's a fair bet you haven't
looked at the source code he provides.
Judging by the posts to this group I am
not the only one that would like to have
a go at breaking scott19u.zip, however,
every body has been severely hampered by
source code that is not human readable (even
for programmers) and the lack of a clear, accurate
description.
So here's where the challenge comes in .......
==================================================================
******* THE CHALLENGE ******
==================================================================
David, if you think the algorithm is as secure
as you claim, then take the following challenge.....
Rewrite the source code in a form that is
easily readable by humans. Use descriptive variable
names, avoid macros, etc..
Take a few days to write an accraute, concise
descrption of the algorithm that can be used by
those who have no programming background to
have a go at analysing it.
Make the source and the description
available as a single download, so that
people can read them offline.
The description can
be in any format as long as most people are likely
to have software to view it (postscript, html, word,
pdf, wordpad, or any other popular format).
Please also include clear, tidy diagrams.
============================================================================
If you take this challenge seriously, and your algorithm
isn't cracked in the next few months, then others
may start to have some confidence in your algorithm and
possibly even take it seriously.
As it is, it's a fair bet that you are the only one thats
currently using it.
Please respond to this post with a post confirming
if you accept this challenge or not.
If you don't accept it, please, calmly give your reasons for
all to read.
- Tim
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: bareface ratio
Date: 1 Jun 1999 21:20:07 GMT
This is a very good insight.
Don Johnson
------------------------------
Date: Tue, 01 Jun 1999 14:42:51 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.perl.misc
Subject: Re: bareface ratio (the psychology of newsgroups)
Greg Bartels wrote:
>
> just an interesting phenomenon I've noticed
> on newsgroups in general.
>
> bareface ratio:
>
> the number of people who respond
> to tell you your information is wrong
>
> versus
>
> the number of people who respond
> to your requests for information
> on the same topic.
>
> this seems to be about 3 (or more) to 1,
> depending on the topic.
>
> so, if you have a question, and no one
> is responding, you can still get the
> answer, all you have to do is make something
> up first (bareface it), and the
> corrections will flood in.
>
> Greg
A disturbingly astute observation, Greg. Maybe we all should take the
lesson that the signal-to-noise ratio of the newsgroup would be improved
three-to-one if flamers simply ... didn't.
"Silence is efficient."
------------------------------
Date: Tue, 01 Jun 1999 15:03:34 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Reasons for controlling encryption
Paul Koning wrote:
>
> Bill Unruh wrote:
> >
> >They already do that. Read ITAR or the EAR in the USA. Lots is
> > exempted from the regulations (including bank transfers, etc)
>
> I don't think so. It's common to say things like "40 bit crypto is
> exempt" or "bank applications are exempt" but that's not what the
> regulations actually say. Instead, nothing is exempt, but different
> uses and different strengths are covered by different sets of rules.
> Depending on which set applies to you, the amount of hassle imposed
> varies greatly. But if you assume that certain application X isn't
> covered, you may be in for an unpleasant surprise.
Plus the fact that ITAR itself is under the gun, and the whole body of
law within 100 miles of it is now under legislative review. Obviously
the existing regulations aren't working or aren't appropriate any more.
The $1.99 question is exactly what to replace it with... even if that's
"nothing."
------------------------------
From: "Grimace" <[EMAIL PROTECTED]>
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: Generating Random Numbers
Date: Tue, 1 Jun 1999 23:10:54 +0100
Rochus Wessels wrote in message ...
>I didn't write this message.
>And it deleted my original answer, which
>were two useful references:
>
>http://www.counterpane.com/yarrow.html
>http://www.cs.berkeley.edu/~daw/rnd/
Ah, interesting. I can't remember if it did that originally...
I *think* it's a bot, that stores a big list of genuine posters --
their names and email addresses, by the looks of it -- and posts
garbage messages appearing to originate from them.
I know not the purpose. However if it's killed your original message,
it looks like this is a mildly more sophisticated version of the
original scam.
Ho and-very-much hum.
-Graeme.
------------------------------
From: [EMAIL PROTECTED] (Bill Roberts)
Subject: Re: PGP Key security?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 01 Jun 1999 23:04:19 GMT
On Mon, 31 May 1999 01:50:00 +0100, "james b"
<[EMAIL PROTECTED]> wrote:
>Have just got PGP 6.0 and have a couple of questions regarding security of
>the key when using Windows 98.
>
>Just how secure is my passphrase from prying eyes?
Your pass phrase is never saved to disk. It is run through the Hash
function to produce a key which is then used to decrypt your secret
key. The key is kept in memory for only a limited time before it too
is erased. If you do not show the typing on the key entry box, the
only way someone can read your pass phrase is to watch you type it in.
If you do show the phrase, someone would have to be looking at the
screen as you type it. In any case, your key is as secure as your
pass phrase. If you have chosen a reasonable pass phrase, it would be
extremely difficult for someone to crack your key (ie several billion
years with a super computer).
>
>Is there an optimal keylength? (Or is that a very silly question)
Try to choose a phrase with over 20 characters, mix case, add numbers,
punctuation, and purposely misspel a word or two (My dawg haz flez,
plez!)
Bill Roberts | Rutgers '66
[EMAIL PROTECTED] | Owego, NY
Fix reply to in order to reply
PGP fingerprint: D7C4 BCEF 0B53 C703 088B D893 6294 1117 EDF1 37FC
------------------------------
From: Jerome O'Neil <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Re: bareface ratio
Date: Tue, 01 Jun 1999 16:35:02 -0700
David Cassell wrote:
> Especially if you add one teeny, tiny error that is
> more-or-less irrelevant to the original point of
> the thread.
I have derived a new unit of measurement for measuring usenet threads
called the 'pedant.' A long thread's length is guaranteed to be at least
two pedants long.
O'Neil's corollary to Goodwin's Law: "The length of a thread needed to
prove Goodwin's Law is inversely proportional to it's pedant measure."
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
[EMAIL PROTECTED] - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: random numbers in ml
Date: 2 Jun 1999 00:31:19 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
I'm including a routine that seems to generate pretty good random numbers
for a fairly large period. I can't detect any patterns from *any* of the
five byte seeds that I have tried out so far:
Seed #1 Tested: $00 $00 $00 $00 $01 Result: good.
Seed #2 Tested: $E7 $00 $00 $00 $00 Result: good.
Seed #3 Tested: $AA $AA $AA $AA $AA Result: good.
Seed #4 Tested: $55 $55 $55 $55 $55 Result: good.
Seed #5 Tested: $3C $3C $3C $3C $3C Result: good.
Seed #6 Tested: $C3 $C3 $C3 $C3 $C3 Result: good.
Seed #7 Tested: $33 $CC $33 $CC $33 Result: good.
Seed #8 Tested: $CC $33 $CC $33 $CC Result: good.
Seed #9 Tested: $F3 $30 $0C $CF $AA Result: good.
Seed #10 Tested: $1E $E1 $1E $E1 $1E Result: good.
Seed #11 Tested: $E1 $1E $E1 $1E $E1 Result: good.
Aside from the 5 byte seeds above, the routine examined below contains two
more bytes that should be cleared to zero or $00, which I don't consider to
be part of the seed, but other people could certainly make the argument
that they are also part of the seed, and if you filled them up with an
assortment of bits, you'd be making it that much more random.
Now, seeds 3 through 11 were selected with some care for an equal number
of 1 bits and 0 bits. The first two seeds, however, were chosen because
they seemed to be 'minimal' seeds that still were capable of producing
(apparently) very good random series of numbers.
I tested the results for as many as $18000 iterations each, and weighed
the nybbles produced (two at a time), and noted no heavy predisposition
for one nybble any more than any other. Also, I tested the results by
storing bytes in a hi-res screen, and got a very good image of random
'noise.' Finally, I tested to see if it was just as noisy, if I stored
every third random number, instead of every random number generated.
Still just as noisy. Did the same thing for every fifth, and then, later,
for every seventh. Apparently subsets of the random numbers possible, are
just as random.
Using the MAS-128 symbolic assembler for the C-128, (where 'mov' means
LDA argument1 STA argument2, for all legal addressing modes), here is the
source code that I cooked up:
110random lda seed eor temp
120 lsr sta temp
130 adc seed
140 rol adc temp
150 sta seed
160
170 lda seed+1 eor temp+1
180 ror sta temp+1
190 adc seed+1
200 rol adc temp+1
210 sta seed+1
220
230 adc seed+4
240
250 pha
260 mov seed+1 seed
270 mov seed+2 seed+1
280 mov seed+3 seed+2
290 mov seed+4 seed+3
300 pla
310
320 sta seed+4
330 rts
340
350seed hex 00 00 00 00 00 ; five bytes
360
370temp hex 00 00 ; two bytes
380
390; ________________________________________________________________
400; | |
390; | If your symbolic assembler can't handle multiple instructions |
400; | per line of source code, get a better assembler. |
410; | |
420; | Random Number Generator |
430; | |
440; | by |
450; | |
460; | Matthew Montchalin |
470; | |
480; |________________________________________________________________|
Lines 260 through 290 were inspired by the routine that Jim Butterfield
posted a couple months ago. So far as I can tell, the random number
generator tends to run into a pattern that is probably 65,536 bytes or
more long. The bias, regardless of seeding (assuming at least minimal
seeding, as given above, in seeds 1 and 2), is towards bytes with an equal
distribution of 0's and 1's, which is a good thing. But it seems that in
the course of $FFFF iterations, you aren't very likely to get a series of
null bytes generated. By looking for series of null bytes, you can
probably discern how many bytes long the seed is...
rng rnd 6502 asm source code
--
------------------------------
From: [EMAIL PROTECTED] (Logic)
Subject: ECM factoring question
Date: 1 Jun 1999 17:57:30 -0500
When doing elliptic curve factorization, we choose an initial point P on the
curve. We then calculate the "multiples" of P recursively by performing the
group operation on it with a sequence of primes under the chosen bound B.
As I understand it, in practice, this sequence is the sorted list of prime
powers less than B, where the prime itself replaces each of its powers in
the list, e.g. 2,3,2,5,7,2,3,11 and so on.
In practice, we rarely find a factor in one trial of ECM (unfortunately).
Normally we are forced to calculate the multiples of P through the entire
sequence. Suppose we instead calculated the multiples of P by each prime
until we exceeded B, e.g. 2,2, ... ,2^x<=B, 3,3, ... , 3^y<=B, ...
Under the assumption that most trials of ECM yield no factors, could we not
gain a slight increase in speed by somehow taking advantage of the fact that
we are calculating the same multiple several times (at least for the smaller
primes)? Would this make the code simpler as well?
I suppose there are times we would not want to do this, in which case we could
use the traditional sequence. But in the right circumstances, could this
sequence be faster/simpler?
Thank you.
------------------------------
From: [EMAIL PROTECTED] (Markus Kuhn)
Subject: Re: Paper on Making Usenet "unerasable"?
Date: 1 Jun 1999 22:45:41 GMT
In article <[EMAIL PROTECTED]>, Sundial Services
<[EMAIL PROTECTED]> writes:
|> > ... In this way, a legal argument could be constructed such that
|> > a court ordering the removal of a document would be stymied by the
|> > overriding legal need to do as little damage as possible to other
|> > documents not related to the suit in question.
... a *highly* hypothetical legal argument, one might add. Judges are
usually quite good in seeing through all such theoretical schemes and
still preventing you from doing something illegal, no matter how much
cryptography you throw at it.
|> Sounds interesting, but I don't know how many judges who like to hear
|> the words "No, I can't." They kinda sorta have lots of really nasty
|> ways to persuade people to do their bidding...
I am sceptical whether this is possible in a really robust way.
If documents are both publicly available and highly interrelated,
then the judge can always download/decode all not-prohibited documents,
erase the offending one, and put the rest back onto your servers.
If you drive the interdependency to extremes in a distributed system,
then you also start to get both extremely inefficient and extremely
unreliable. I have seen numerous suggestions for sort-of holographic
filesystems, but for each of these I see realistic ways of how a judge
can either request that they be shut down or how someone can just flood
the system with child pornography to the point where it becomes
useless for any purpose and must be shut down entirely. The judge could
also order that various filters be installed that prevent not the
storage, but the accessability of the documents in a controlable
way. In the end, a highly intelligent judge will always find a way
to prevent you from violating the law, and the more effective of these
ways are usually not at all related to cryptography. Proposals for
file systems that evade legal restrictions look at first very impressive
on paper, but when it comes to implementing and actually defending them
in the real world over a long time, things become extremely tricky.
The real trick is usually to replicate the data so quickly across so
many legal domains that a single judge without international cooperation
has problems to shut down every single server. However, you will have to
find a lot of volunteers all over the world who are willing to face a
legal dispute for you, and that is usually very difficult.
Your dream of a non-revocable MP3 piracy service will therefore
remain a dream.
One reference on the topic (perhaps the one that started this field
of research) is Ross Anderson's "Eternity Service" paper given at
Pragocrypt. <http://www.cl.cam.ac.uk/ftp/users/rja14/eternity.ps.Z>
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Obscure Code
Date: Wed, 02 Jun 1999 01:19:35 GMT
In article <7j1aia$pjh$[EMAIL PROTECTED]>, "Oliver J. Hanau" <[EMAIL PROTECTED]> wrote:
>Does anyone now if there is any kind of source on producing obscure
>code, i.e. code that is hard for an attacker to analyze/debug?
>(Assuming the decryption process takes place in an insecure
>environment, and the attacker attempts to find the key and possibly
>also the algorithm.)
>
>I know that the whole point of such obscure code is *not* to let
>people know how it's done, but maybe there is something despite that
>fact? A source stating that there aren't any sources would also be
>fine.
>
>As this is for an important side-note of a li'l thesis I'm putting
>together, I'd prefer a off-line sources (book/magazine).
>
>Thanks a bunch,
>Oliver.
>
>
>
You can look at the code which can be found by poitners from my
site. It is code written in C for a PC but many who look at it get very
confused and they think it is obscure.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.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
******************************
