Cryptography-Digest Digest #422, Volume #10 Sun, 17 Oct 99 14:13:03 EDT
Contents:
Re: Newbie Cryptology question : is user 'key unkown' crypting possible? (Chad
Hurwitz)
Re: where to put the trust (wtshaw)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Bernstein and letting the court write (or rewrite) laws (wtshaw)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (wtshaw)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Mok-Kong Shen)
Re: Biometric Keys are Possible (Mok-Kong Shen)
accurate decryption (eminor54)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Johnny Bravo)
Character Frequencies Tables for languages other than English ("Stu Jenkins")
character frequency tables for non english languages ("Stu Jenkins")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Chad Hurwitz)
Subject: Re: Newbie Cryptology question : is user 'key unkown' crypting possible?
Date: 16 Oct 1999 20:42:35 -0700
In article <[EMAIL PROTECTED]>, Steve K <[EMAIL PROTECTED]> wrote:
>On 16 Oct 1999 12:56:46 -0700, [EMAIL PROTECTED] (Chad Hurwitz)
>wrote:
>
>I'm fairly new to all this myself, but how about having your two
>parties connected in near-realtime via an SSL session, during the key
>generation & time stamping process?
>
>Of course this leaves the possibility of spoofing and man in the
>middle attacks open, but these are addressed extensively in the
>literature, and you will probably need to include countermeasures to
>them no matter what you do.
>
>The peanut gallery has spoken.
that would work, since then the checksums would be recorded
during the creation of the file and the server would verify the time with the
checksum with the file upload (that could take place later) perfectly.
Unfortunatley i'd rather find a way around needing to be connecting to the
net durring file creation. The creation of these files is very
difficult and if the net goes down it would be unfair for the individual
requesting verification to be unverified only because of the net.
but this may be the only way to do it.... just wondering if anyone has
key generation technique that will generate a key and encrypt a message
with out "easily" revelaing the key to the user of the program generating
the encryption.
thanks for the response though :)
--
/-------------------------------------------------------------------\
| spam if you can, spam if you dare, spam if you must, i won't care |
| spam is futile, spam is free, spam is filtered, so i won't see |
\-------------------------------------------------------------------/
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: where to put the trust
Date: Sat, 16 Oct 1999 23:08:19 -0600
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote about Ciphile crypto:
>
> Hmmm. you claim modern algorithms are bunk and your fake OTP is
absolutely secure?
> Please clarify. What is the unicity distance (c.f., Shannon) of your system?
>
> Would you care to place a small monetary wager on the strength of your
software?
Let's put some real number in play here. Go for an SSS#.
By the way, did a program in Dallas today; I mentioned many of the folks
we know, honoring many with a mention that some would leave out. As well
as my GVA, Scott's ciphers and Ciphile stuff is grouped as coming from
Maverick cryptographers. Hope you guys don't mind; so it is.
Call me the name dropper, but some others were remembered as well, all in
good taste and worthy credit. I suppose I left out lots of those I should
give equal billing.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 17 Oct 1999 05:00:35 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Bernstein and letting the court write (or rewrite) laws
Date: Sat, 16 Oct 1999 23:50:53 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Johnny Bravo) wrote:
> On Fri, 15 Oct 1999 15:56:32 -0700, Sundial Services
<[EMAIL PROTECTED]>
> wrote:
>
> >I don't mean to start any flame war here, but I guess I do feel that the
> >place to create law and policy is the Congress and in the Executive
> >branch, not the Judiciary. It's an age-old problem of course, inherent
> >in our system of "checks and balances," which system is deliberately
> >designed that it be so! But cryptography was hardly on the Framer's
> >minds when they drafted the Amendment.
>
> I doubt that television, radio, or the internet was on their minds
either, do
> you think that the above mediums do not deserve any protection because
> they weren't invented in the late 1700s? Many of the current religions
did not
> exist then, do they deserve the protection of the first amendment?
Thomas Jefferson, inventor?/adapter? of what is call the Jeffersonian
Cylinder, known as the Father of American Cryptography, a sometimes
important scribe on things revolutionary, including our own...
Benjamin Franklin, inventor, statesman, dallier, and our man-about-town
(Paris), known for secret missions, secret messages, not too secret other
affairs....
Recall the XYZ Affair...
These men knew nothing of cryptgraphy and its value? You have got to be joking.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sun, 17 Oct 1999 00:10:37 -0600
In article <[EMAIL PROTECTED]>, John Kennedy
<[EMAIL PROTECTED]> wrote:
> On Sun, 17 Oct 1999 01:29:39 GMT, [EMAIL PROTECTED]
> (John Savard) wrote:
>
> >I could be wrong, but I believe it to be - with some effort - possible
> >for a user to memorize data, _in a suitable form_, from which a key of
> >sufficient (genuine) length can be derived. As there are many cases
> >where there is simply no reasonable alternative to a user-memorized
> >secret, I believe this is a vitally important point.
>
> And I think there are memorization techniques that will enable one to
> remember highly secure pass phrases.
>
> If you can memorize one long pass phrase you can use it to protect an
> unlimited number of other secrets that cannot be memorized.
> >
Both of you are absolutelly right for people what are not lazy beyond
belief. Even stumble bums like me can rememer enough material to be tried
and tried again.
The human is both a fragile and a hearty creature, both foolish and wise.
All amenities aside, Shaw's Law, as printed in Murphy's Laws is, "Design a
system that any fool can use and no one but a fool will use it."
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 12:20:57 +0200
Patrick Juola wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >Why do you care so much about interoperability? For a specific group
> >of communication partners to communicate securely, it suffices that
> >they argree on a specific software/hardware to use.
>
> Because the whole point of computer -- or more generally, communications --
> networks is to permit communication between widely distant and possibly
> unfamilar parties. One of the nice things about the telephone is that
> someone can telephone me from almost anywhere in the world, irrespective
> of whether or not they've communicated with me before or whether or not
You missed my point. Highly secure communication is different from
public communication (e.g. a message through courier is different
from an announcement in the newspaper). The communication partners
in the first case know each other's identity and they agree on a
certain secure means of communication before actually exchanging
messages. If the security requirement is high engough, they can
(normally) afford higher cost, lower throughput, more inconvenience,
etc. etc. So there are different encryption algorithms suitable for
different environments. Is triple DES interoperable with single DES?
Why is triple DES currently in use at all?? The suggestion of Don
Johnson to have super-AES doesn't exclude the use of AES and vice
versa. Even if AES were provided as a standard to encrypt all
people's e-mail on the internet, you are still free to employ
additional encryption to your messages (unless some crypto law
forbids that, because three-lettered agencies want to read everything).
To repeat, you use multiple encryption WHEN (and only when) you need
higher security. If multiple encryption with a number of top AES
candidates is a standard, it doesn't mean that 'everywhere'
there has to be facilities provided for that. (Personal analogy: I
don't feel a need of fax, because the rate of incoming messages is
very low. So I don't spend the money to buy a fax machine, while
lots of my friends do. Later, when the situation changes, I might
decide to have fax facility.)
I suppose I have also answered the parts that I snipped.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sun, 17 Oct 1999 12:21:05 +0200
John Savard wrote:
>
> And there is a reason I underlined the word *passwords* in the
> preceding sentence. Because it is the crucial point where I think
> Bruce may have been mistaken. It is possible for the user of a
> cryptographic system to memorize a pass phrase. It is possible to use
> the same kind of tricks with a pass phrase as are used with short
> passwords to increase entropy - insert an incongruous word, rather
> than a non-alphabetic character, into the phrase. One can require two
> or three pass phrases to be entered to produce the key.
>
> I could be wrong, but I believe it to be - with some effort - possible
> for a user to memorize data, _in a suitable form_, from which a key of
> sufficient (genuine) length can be derived. As there are many cases
> where there is simply no reasonable alternative to a user-memorized
> secret, I believe this is a vitally important point.
Certainly, even bad pass phrases have some entropy. So using a
sufficient number of pass phrases (or a sufficiently long one) can
deliver any required amount of entropy. I guess that doing so might
be considered not very user friendly by the system designers,
though, as you said, the justification is questionable.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Biometric Keys are Possible
Date: Sun, 17 Oct 1999 12:37:35 +0200
[EMAIL PROTECTED] schrieb:
>
> Bruce Schneier's latest Crypto-Gram caused me to think about how biometric
> information could be used for cryptographic keys.
>
> Some quantities, like the number of fingerprint ridges between two
> features, are discrete. Extracting them from a scan of a fingerprint is
> still a complicated process, requiring advanced software.
>
> But many biometric characteristics are analog quantities. With such
> quantities, there is the inescapable problem that some physical values
> will be very close to the boundary between producing two different codes
> for the value of the quantity.
>
> No scheme can change this fact; if different output values are possible,
> the transition between them must take place somewhere.
>
> However, a system used for shaft encoders and the like, Gray code, can
> ensure that codes for consecutive numeric values differ by exactly one
> bit.
>
> Why is this useful? Isn't a cryptographic key that is wrong in one bit
> still useless?
>
> Ah, but along with a user's ID, a system can store the check bits of an
> error-correcting code that can correct a limited number of single-bit
> errors in the user's biometric data.
>
> Doubtless someone has thought of this before, and this idea is the subject
> of a patent somewhere, but I thought it worth mentioning that this kind of
> technique exists as an option.
I suppose the analogue quantities you mentioned are in practice all
digitalized today before further processing. There are certainly
errors, either inherent in the measurement process or due to change
(with time) of the biometric quantities themselves. To take
care of such errors is in the proper domain of the science of
pattern recognition. By the way, employing biometric data involves
the risk of the data being copied and replayed in certain situations.
M. K. Shen
------------------------------
From: eminor54 <[EMAIL PROTECTED]>
Subject: accurate decryption
Date: Sun, 17 Oct 1999 06:51:54 -0400
This may be slightly off- topic, but I was wondering - how can one
defend against this scenario - you have a decrypted mesage intercepted
by someone in authority who wants to accuse you of a crime. They are
unable to decrypt the message themselves and of course, you dont give
them the key. However, they then contrive a phony decryption that is
incriminating, yet you cant prove to anyone that it's a fake without
revealing the true message. What defenses exist in a case like this? Is
it possible to show that the fake message is indeed a fake without
revealing the true text?
Thanks
Bill Heiss
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Sun, 17 Oct 1999 08:48:28 GMT
On Sun, 17 Oct 1999 01:29:39 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
>I think it *is* correct that users can't memorize _passwords_ which,
>because they have digits or punctuation marks thrown in, have enough
>entropy in them to be adequate in themselves.
It certainly is possible if you are willing to work with it. How much entropy
would you assign to the following password.
TTNqwbTfbjiottblsdt.iopwwnpofttowbdd.,.titq.
At least 200 bits , and is easily reproducible if I'm willing to spend about
15 seconds recreating it every time I type it in. And if that isn't enough, it
would be trivial to make it even longer. This would be easier to memorize than
a six word Diceware passphrase of about 77 bits, though it would take longer to
type.
>And there is a reason I underlined the word *passwords* in the
>preceding sentence. Because it is the crucial point where I think
>Bruce may have been mistaken. It is possible for the user of a
>cryptographic system to memorize a pass phrase. It is possible to use
>the same kind of tricks with a pass phrase as are used with short
>passwords to increase entropy - insert an incongruous word, rather
>than a non-alphabetic character, into the phrase. One can require two
>or three pass phrases to be entered to produce the key.
As, I've demonstrated above. It is trivial to turn passphrases into secure
passwords. Now if he said that you can't remember a passphrase composed of
enough random characters to be secure, I would agree with that. However, a pass
phrase is nothing more than a password with spaces in it. :)
>(Note that I've earlier advocated stripping punctuation from pass
>phrases, since I think it's easier to memorize the words of a longer
>pass phrase than to get the punctuation exactly right every time.)
It would vary per person. If you are in the habit of good typing, it
might actually be easier to leave the punctuation in. Rather than remember to
leave it out.
Best Wishes,
Johnny Bravo
------------------------------
From: "Stu Jenkins" <[EMAIL PROTECTED]>
Subject: Character Frequencies Tables for languages other than English
Date: Mon, 18 Oct 1999 14:34:20 +0100
I am looking for character frequency tables for european and other
languages. Does anyone know where these are available?
Any help gratefully recieved.
Stu
------------------------------
From: "Stu Jenkins" <[EMAIL PROTECTED]>
Subject: character frequency tables for non english languages
Date: Sun, 17 Oct 1999 14:35:52 +0100
I am looking for character frequency tables for european and other
languages. Does anyone know where these are available?
Any help gratefully recieved.
Stu
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 17 Oct 1999 14:00:35 GMT
Just want to point out that the idea of multiple encryption using diff. algs
(Super AES), etc. is fairly obvious.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:41:11 GMT
On Fri, 15 Oct 1999 19:07:15 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>It seems odd to me that you know what is on Schneier's mind,
>
>I can only assume that it was something like your proposal he was
>criticizing, because such a criticism wouldn't make sense applied to
>what Brian Gladman was talking about.
>
>Your proposal at least appeared to have serious weaknesses, the way
>people understood it at first. (I certainly grant that you had a right
>not to be amused at some of the things that happened as the thread
>went along; you clarified some of the details of what you were
>proposing as the result of questions, and the response was "how do we
>know you didn't just steal the idea our question implied".)
We had a big discussion based on my proposals in April 1999, some of
which is archived on my pages (see:
http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
). And I have had various public discussions about parts of this over
several years (see from 1996, for example:
http://www.io.com/~ritter/CRYPTWAR.HTM
for example:
http://www.imc.org/workshop/mail-archive/0233.html
). But I think it was just within the last year that I realized how
important it was for people to see this before locking AES alone into
all future systems.
>>My experience is that those who
>>support the conventional wisdom will avoid anything fundamentally new
>>and disturbing at almost any cost. And if you are not part of the
>>solution, you are part of the problem.
>
>It's obviously wrong if you jump from "no cipher is proven secure" to
>"all ciphers are equally bad".
I don't believe that, I doubt I ever said it, and find it hard to
imagine that anyone could reasonably interpret my words to have that
meaning.
No matter how many clear unambiguous statements I make, however, it is
rather easy for you to misstate my position, as you yourself did in
your earlier posting:
>>It isn't the idea of having two or three AES winners that Bruce was
>>referring to, but the idea of relying on a system that is based on the
>>principle that, since *no* cipher is proven secure, one needs
>>_thousands_ of ciphers, chosen at random by one's encryption
>>program...
It is wrong to imply that there is no improvement wrought from each
dimension: multiple level ciphering, dynamically changing ciphers,
and having many ciphers to choose from. Insisting that the weakness
of the proposal is that we don't have many "good" ciphers misstates
the situation. The real weakness is that we don't know that we have
*one* "good" cipher; now what do we do about it? The problem we have
is *not* the proposals, but instead the way things are currently done.
Yet we see continued slanted misstatements, despite whole reams of
archived messages and summaries which lay it all out.
>You may rightly protest that you never
>jumped to that kind of conclusion, but at times you allowed it to
>appear that this was the basis of your multi-ciphering proposal.
I "allowed it to appear"? You say I deliberately allowed a
misconception because it would improve my position? No. Nonsense.
That did not happen.
I don't answer every message, of course. (Currently, even this amount
of time is unsustainable for me.) Sometimes I misstate, and sometimes
I do make mistakes. But intentionally leaving a false impression?
No. Why would I do that? The underlying position is solid and
correct. I have no need for misconceptions, and I feel no particular
need to "win" at any such cost.
This is not about me winning. This is about solving a serious problem
on the horizon at a time when the solution cost is relatively small.
If we wait for AES-only to get wired-in, we will have a very serious
and costly situation indeed.
>The "conventional wisdom" in cryptography, as in other fields, did not
>arise simply by whim or prejudice, but came about as the result of
>knowledge and experience. That doesn't mean it doesn't have its
>limitations and omissions - many of which I feel you have correctly
>located, and are attempting to address.
>
>To be "part of the solution", however, one has to be more than a
>"voice crying in the wilderness". And that involves paying the
>conventional wisdom its due, and recognizing that due.
There is no "due." The conventional wisdom *caused* the situation by
failing to practice the Science they claim to support. Nor are they
in any hurry to correct their error despite the fact that society will
actually depend upon this stuff. That hardly deserves respect.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:45:38 GMT
On Fri, 15 Oct 1999 06:52:02 -0700, in
<7u7bfm$[EMAIL PROTECTED]>, in sci.crypt "Roger Schlafly"
<[EMAIL PROTECTED]> wrote:
>Terry Ritter <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> The use of *keys* limits interoperability -- to those who have the
>> right keys. We now do arrange to transfer keys as needed. We could
>> arrange to transfer the name of the cipher to be used, or even the
>> cipher itself.
>
>Yes, having several ciphers is equivalent to having a couple of
>extra key bits.
>
>> ... Could Germany and Japan *prove* their ciphers
>> were weak in WWII? Would they have been better off changing their
>> (broken) ciphers?
>
>Obviously they would have tried to design better ciphers if they knew
>their ciphers were being broken. But diversity for the sake of
>diversity would not have helped htem much, and might have even
>hurt them because the alternative ciphers might be more easily
>broken..
Might, might, might. In contrast, we *know* what happens when someone
is convinced their cipher is strong enough: the classic examples are
Germany and Japan in WWII.
On the other hand, perhaps you have a better suggestion for
controlling this disturbing reality. The problem is not proposals for
change. The problem is the conventional wisdom which is insufficient
in itself.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Sun, 17 Oct 1999 15:52:00 GMT
On Fri, 15 Oct 1999 16:09:57 GMT, in <7u7jk8$o4f$[EMAIL PROTECTED]>, in
sci.crypt Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <7u6dgg$[EMAIL PROTECTED]>,
> "Roger Schlafly" <[EMAIL PROTECTED]> wrote:
>> DJohn37050 <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>
><snip>
>
>
>> > For systems with one alg, they switch over over time.
>> >
>> > I know that I MUCH prefer the possibilities of scenario B.
>>
>> Not me.
>>
>
>Option B has theoretical appeal, but it would be economically
>impossible to put into practice. It wouldn't be that hard to
>implement multiple choices in *software* and assign an OID to
>transactions so the software can choose the correct algorithm.
>
>But hardware vendors are not going to build AES based devices
>with multiple algorithms.
Modern "hardware" systems often consist of embedded processors and
"firmware" based in flash. The system itself can be designed to
choose from an array of acceptable ciphers, and also maintain a list
of a cipher *required* in a cipher stack, or *disallowed* due to new
information.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
