Cryptography-Digest Digest #456, Volume #12 Wed, 16 Aug 00 05:13:00 EDT
Contents:
Re: 215 Hz five-qubit quantum processor ("David T. Wang")
Quick Question (Part Two) ("Steven Knight")
Re: 215 Hz five-qubit quantum processor (Steve Newman)
Re: Unauthorized Cancel Messages (Ron B.)
Re: 215 Hz five-qubit quantum processor (Paul Rubin)
Re: Big Brother Is Reading Your E-Mail (Michael Brown)
Re: Quick Question (Part Two) ("Paul Pires")
Re: What is up with Intel? ("Paul Pires")
How to design a new *secure* network protocol from scratch? (proton)
Re: Proposal of drafting rules of conduct of posting (Mark Currie)
Crypticon novel book ("DEXMilano")
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: 215 Hz five-qubit quantum processor ("Dennis O'Connor")
Re: OTP using BBS generator? (Mok-Kong Shen)
Re: Choosing parameter sizes (was Re: OTP using BBS generator?) (Mok-Kong Shen)
Re: 215 Hz five-qubit quantum processor (Nick Maclaren)
Re: Proposal of drafting rules of conduct of posting (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "David T. Wang" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 16 Aug 2000 05:24:05 GMT
In comp.arch [EMAIL PROTECTED] wrote:
: Wow .. this technology is moving fast! In 2Q98 there were still
: many physicists doubting that anyone could ever make a model that
: could remain coherent for more than one or two operations at a time,
: and now here's IBM in 3Q00 demo'ing a 215 Hz system!
: It sounds like practical quantum computing might intersect the
: domain of digital computing sooner than anyone expected 8-|
: IBM's system is a one-function device, but what a function!
: Finding the period of a function as a one-step calculation! It
: makes me wonder how long it will be before our computers are
: hybrid systems, with fast digital processors remaining at the
: heart of the system, but with single-function co-processors
: standing by to perform "hard" operations as needed.
: It reminds me of the P/NP problems the professor would give us
: in college, where he'd say "here, assume you have a conventional
: computer that runs pascal, and a magic function that solves this
: NP problem in P time. Write a function to solve this other NP
: problem in P time by using this magic function."
: Seems to me that if a quantum computer like IBM's can solve the
: period of an arbitrary function in P time (indeed, in O(1) time),
: then it might also be able to solve the halting problem in P time
: for at least some subset of algorithms (or at least be used by a
: conventional computer to solve the halting problem, a la AVG's
: classroom exercises). The mind boggles at what we could do with
: that.
: Question -- is keeping an N+1 qubit computer coherent a *lot*
: harder than keeping an N qubit computer coherent? IE, does it
: get more difficult as an exponential, polymetric, linear, or some
: other function of qubits, roughly speaking? Or is everyone still
: scratching their heads and unable to say?
The problem of using technologies such as these would be to interface
them with the existing infrastructure, and the communcation latencies
involved. That is, unless these special purpose gizmos can somehow
take over all of the computational load, then they have to talk to some
other form of intelligence, and eventually I/O. A quantum computer
can indeed be very exciting if it can decrypt 1024 key encrpytion
in a single "cycle". (Sneakers?) However, then the next logical
question is, how long does it take to get the quantum computer, or
for that matter, any special form of computing element to be setup
to the point when it can compute what we want it to compute, and then
get the information out to a point and place where we can understand
the result.
This has been the same serious problem as several other interesting
technology such as reconfigurable processors. Sure once you set it up
to do that exactly one thing, it can do it very fast, but it takes much
too long to set the whole darn thing up. Some of the process technology
types I spoke with a couple of years back suggested that they can even
use the transistor itself as a computing element. It does exponentials !
They also claim that they can do sines and cosines. Ofcourse the
problem is, how do you interface to this specialized 1 transistor
exponential computation machinery? A bunch of A->D then D->A converters,
some more signal processing in there to filter out the wrinkles due to
process variances?
IMO, the "golden days" of computer architects and engineers are gone.
The world doesn't revolve around fast processors anymore. The focus
has been shifting ever so slowly from concentrating on how to perform
computations quickly to figuring out how to move the data really fast
from point A to point B. In that train of thought, even if IBM announced
a "128 bit quantum computer", I would most likely just keep my head
buried and continue to pound away at my keyboard. If however, someone
figures out a clever way to "setup the quantum state" in a few seconds
(or ns, or minutes.. Just not years) and subseqently receive the result
of the computation in an equally short and reasonable amount of time,
then I would really sit up and take notes. This "secondary" development
on this technology, although not as glamourous to the general public,
would instantly grab my attention, because that would mean that there
is a way I can actually take advantage of this technology, and not just
as a scientific curiosity.
--
SETI@HOME Hall of Shame Project
80386DX33, 128KB cache. IIT 80387 MathCo. 32 MB. Win95.
Status: 100.000% complete. CPU Time: 2353 Hours 15 minutes 31.8 sec
------------------------------
From: "Steven Knight" <[EMAIL PROTECTED]>
Subject: Quick Question (Part Two)
Date: Wed, 16 Aug 2000 06:53:55 +0100
Now I know this is not the right NG but I have been unsuccessful in all C++
NG's
Could anyone give me C++ code on some simple algorithms
Much appreciated
Steven
------------------------------
From: [EMAIL PROTECTED] (Steve Newman)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: Wed, 16 Aug 2000 05:58:52 GMT
In article <8nctf9$5tf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
Rubin) wrote:
> The class of problems a quantum computer can probablistically solve in
> P-time is called QBP. It's believed to be larger than P but it still
> is no larger than NP. Factoring and other search-type problems sit
> inside QBP, but sorry, the classical halting problem is still undecidable.
How much larger than P?
It occurred to me some years back that with the appropriate "magic
box", you could trivially implement a theorem prover for arbitrary
theorems. Simply generate all possible strings up to a certain
length, and run each string through a theorem checker to see if it
constitutes a proof for the theorem. This requires a theorem
checker, but that's not hard to write.
Could this algorithm be implemented in a (sufficiently advanced)
quantum computer? Presumably the length of the theorem would be
bounded by some value proportional (at best) to the number of bits
supported by the computer. Still, this would be a heck of a thing
if it worked.
Computers have already caught up with human chess players... maybe
in a few more decades, mathematicians will succumb?
(Seems unlikely somehow, but still an interesting thought.)
-- Steve Newman
------------------------------
From: Ron B. <[EMAIL PROTECTED]>
Subject: Re: Unauthorized Cancel Messages
Date: Wed, 16 Aug 2000 06:05:29 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Tue, 15 Aug 2000 13:48:54 GMT, Ron B. <[EMAIL PROTECTED]> wrote:
>It appears to me that someone is sending bogus cancel messages to
>sci.crypt and the alt.security.* groups. My newsreader shows
>several "This message is no longer available" messages for several
>legitimate messages. This are clearly not anti-spam cancels as they
>are new
>responses to postings. Has anyone else seen this?
I've contacted support at gte.net. It was a problem with the local
server for my area.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
iQA+AwUBOZovJAzUoy7OvTSOEQJV1ACffOaKyvN20/4orsWcWGLoRY2skk0AmLWG
Fn0nB457KPqYBYay+9lN9vk=
=8Z1i
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 16 Aug 2000 06:37:27 GMT
In article <[EMAIL PROTECTED]>,
Steve Newman <[EMAIL PROTECTED]> wrote:
>In article <8nctf9$5tf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul
>Rubin) wrote:
>
>> The class of problems a quantum computer can probablistically solve in
>> P-time is called QBP. It's believed to be larger than P but it still
>> is no larger than NP. Factoring and other search-type problems sit
>> inside QBP, but sorry, the classical halting problem is still undecidable.
>
>How much larger than P?
It's known that NP >= QBP and that QBP >= P. It's not known whether
NP > P. Therefore it's not known whether QBP > P.
However, general belief seems to be that NP > QBP and QBP > P.
More than that is hard to say.
>It occurred to me some years back that with the appropriate "magic
>box", you could trivially implement a theorem prover for arbitrary
>theorems. Simply generate all possible strings up to a certain
>length, and run each string through a theorem checker to see if it
>constitutes a proof for the theorem. This requires a theorem
>checker, but that's not hard to write.
This doesn't tell you whether a theorem is true, of course. Input the
extended Riemann hyponthesis and start the prover, stopping it when
the strings reach a billion characters. Say it stops without finding
a proof. You still don't know whether there is a proof of ERH that
happens to be a billion and one characters long. Some awfully long
proofs have in fact been published. The theorem classifying the
finite simple groups fills something like 10,000 journal pages.
>Could this algorithm be implemented in a (sufficiently advanced)
>quantum computer?
Probably no better than on a classical computer. The problem you're
describing ("is there a proof of X, that's < N characters long?") is
clearly NP-hard.
>Computers have already caught up with human chess players... maybe
>in a few more decades, mathematicians will succumb?
>
>(Seems unlikely somehow, but still an interesting thought.)
You don't find out til afterwards :).
------------------------------
From: Michael Brown <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Big Brother Is Reading Your E-Mail
Date: Wed, 16 Aug 2000 18:54:30 +1200
> I think your method is more alchemy then science, since I can't
> read XL files I can't see your method.
Fine. What format do you want it in?
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Quick Question (Part Two)
Date: Wed, 16 Aug 2000 00:05:29 -0700
Steven Knight <[EMAIL PROTECTED]> wrote in message
news:8nda9l$sa4$[EMAIL PROTECTED]...
> Now I know this is not the right NG but I have been unsuccessful in all
C++
> NG's
>
> Could anyone give me C++ code on some simple algorithms
>
> Much appreciated
>
> Steven
Pick Up Bruce Schneier's book "Applied cryptography", you will find it on
Amazon. It is really well written with lots of charts and pictures. Plus
algorithms.Plus source code. About the simplest is RC4 -A.K.A.- ARCfour. But
DES isn't hard either.
There is even a companion disk with source code.
Hey Bruce! Do I get a commission?
Paul
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: What is up with Intel?
Date: Wed, 16 Aug 2000 00:21:11 -0700
Jonathan Thornburg <[EMAIL PROTECTED]> wrote in message
news:8nbedi$ngu$[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> >I recall hearing as long ago as 1983 about a small company
> >(whose name I have forgotten but would recognize if I heard)
> >that held the patent on use of XOR to undraw/redraw, as in
> >cursor bitmap images. Since this is obvious and essential
> >technology, it raised quite a stink when they tried to
> >collect royalties.
>
> Another such case... a company in Russia recently received a Russian
> patent on the combination of concave and convex surfaces, and surface
> thicknesses, in a beer bottle. They're currently trying to get 1.5%
> royalties from all the beer manufacturers in Russia. Sigh...
>
> [[no, this is not an urban legend... source is an article by a
> local resident in the most recent issue of the Manchester Guardian
> Weekly newspaper]]
Well, I'm glad you qualified the source :-)
Paul
>
> --
> -- Jonathan Thornburg <[EMAIL PROTECTED]>
> http://www.thp.univie.ac.at/~jthorn/home.html
> Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
> Seen on usenet (dueling .signature quotes):
> #1: "If we're not supposed to eat animals, why are they made of meat?"
> #2: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: How to design a new *secure* network protocol from scratch?
Date: Wed, 16 Aug 2000 07:42:16 GMT
Me and a bunch of other people are planning on re-implementing
the network layer in our respective projects to form a new
shared protocol specification.
In a case where (A) connects to (B), both ends will have
knowledge of all plaintext passwords involved.
Now what im trying to figure out is the smartest and most
secure way of authenticating each end with eachother and
establishing an encrypted session.
Parameters that needs to be passed is;
authentication information (obviously),
session encryptiong method (whatever is implemented, or "none"),
session encryption keys (if encryption != "none"),
network link options (capabilities of software and such),
etc
My first thought for authentication is to produce a hash
of (A)+(B) plaintext passwords. (A) could then search its
list of known passwords until it found a match.
Something in the back of my head says that there might be
problems with this method that I dont know of yet.
Using public key might be another option, but Im not too
good with RSA and I am blissfully unaware of the inner
workings of Diffie-Hellman/DSS.
The link will be used for text-only-communications
(apart from any encryption).
The projects involved (IRC-bots) are very prone to hacker
attacks so Im trying to get all of this right from the
start.
Specific algorithms are less important since they will
probably be implemented as options as time goes by,
much like with PGP and SSH.
I would be very grateful for any help and insight provided.
/proton
------------------------------
Subject: Re: Proposal of drafting rules of conduct of posting
From: [EMAIL PROTECTED] (Mark Currie)
Date: 16 Aug 2000 07:42:15 GMT
I essentially agree with you and I would support any move to improve the
quality of the dialogs. However, I have the feeling that it will not work.
Apart from obvious nastiness which is unnecessary, one of the other problems
that I have found, even with e-mail, is that when you can't see the other
persons face, you can often misinterpret the harshness of a point, and usually
interpret it more negatively than it was originally intended to be.
Mark
------------------------------
From: "DEXMilano" <[EMAIL PROTECTED]>
Subject: Crypticon novel book
Date: Wed, 16 Aug 2000 09:50:35 +0200
I've seen news about a novel (I don't remember the Uathor) named Crypticon.
Is there anyone read it?
Comments?
dex
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Wed, 16 Aug 2000 10:30:05 +0200
Terry Ritter wrote:
>
> <[EMAIL PROTECTED]> wrote:
>
> >Terry Ritter wrote:
> >>
> >
> >> I would say that I do have such an analysis, and it does back me up:
> >> If we use the BB&S construction, we are *guaranteed* not to use a
> >> short cycle. If we don't, then we are just very, very *unlikely* to
> >> use a short cycle. To me, the distinction is the essence of what we
> >> want from a proof of strength. If we were willing to accept a little
> >> weakness here and there, it seems unlikely that we would have much
> >> interest in cryptographic proof.
> >
> >Please correct me if I am wrong. I guess that you have
> >investigated the cycle lengths of the direct output of
> >the congruence relation but not the cycle lengths of
> >the LSB, which could be comparatively much shorter.
> >Further there seems to be no 'apriori' reason that there
> >should exist a neat and simple relation between these
> >two types of cycle lengths.
>
> No correction is needed, since you are right. I have no special
> information on the LSB question.
Thank you for the answer. This means that the situation is
much WORSE than what an quasi-observer of this thread like
me up till now imagines. Namely, if we don't take measures
to ensure having large cycles of the direct output of the
congruence relation (as you have emphatically argued for),
then we have even much LESS chance of being able to obtain
large cycles of the LSB!! As you pointed out previously,
this implies an ESSENTIAL weakness that the analyst could
exploit. More explicitly, I have said that if the cycles
are mostly very small, then finding these would be easy
(instead of needing 'exponential time' or what not) and
further that in the extreme case, cycles of length of
1 and 2 would mean that the bit sequence is perfectly
determined and trivial! I have moreover posed the
question of whether BBS have provided certain definite
informations on the distribution of the cycle lengths
of LSB. From the responses of the experts I got till
now, it seems that BBS have not even given informations
on the distribution of the cycle lengths of the direct
output of the congruence relation! These facts, together
with David Hopwood's information that BBS left
'explicitly' open the question of the relationship
between the said two types of cycles lengths, seem to
sufficiently justify the conjecture that there is
somewhere a theory GAP in BBS's proof of security, in
my guess probably on the path from the difficulty of
predicting the direct output to the congruence relation
to the difficulty of predicting the LSB. (There is, as
far I am aware, NO clear-cut and useful relationship
between these two types of entities in general!) Of
course, due to my humble math knowledge, I could only
conjecture. I like however to sincerely appeal to ALL
the experts on BBS who have participated in this
thread to carefully examine whether the above arguments
do have (undeniable) logical weights and (in case of
my misunderstanding and error) eventually clearly
dispose of these not only with a bit concrete and
easily understandable explanations but also provide
pointers to the paragraphs of the original BBS article
so that one could find more supporting materials, if
needed. This issue is evidently EXTREMELY important,
for otherwise the 'provably security' of BBS would
have been a simple FICTION!
I like to take this opportunity to once again point
out the importance of experimentally checking the
statistical properties of the LSB of BBS, in ways
EXACTLY as every other PRNG ever used in practice
has been checked. (What qualifies BBS to be an
'exception' in this??) My tiny example of a LSB
sequence showing the poor quality in respect of
serial correlations might have been a pure chance
effect, being with some probability an extremely
rare occurence among the ensemble of LSB sequences
generated, but UNTIL this has been confirmed
(theoretically or experimantally) to be indeed the
case, the result MUST be considered as an ESSENTIAL
evidence for doubting the usability of BBS in any
crypto applications.
I sincerely hope that this thread will produce a
final clarification of the (long since questioned
and many times heatedly disputed) issue on BBS and
not be 'diverted' to a sink of 'nil' through being
'distracted' by another thread (appeared yesterday)
which falsely claimed that agreement had already
been reached in this thread. In fact, NO general
agreement of the sort mentioned in that thread has
yet been reached, but it seems that we are really
emerging from the fog and finally on a clear path
to the goal of finding out whether BBS REALLY
provides the fabulous 'provable security' or not.
Many thanks in advance.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Dennis O'Connor" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: Wed, 16 Aug 2000 01:16:47 -0700
> Wow .. this technology is moving fast! In 2Q98 there were still
> many physicists doubting that anyone could ever make a model that
> could remain coherent for more than one or two operations at a time,
> and now here's IBM in 3Q00 demo'ing a 215 Hz system!
It wasn't a 215 Hz system, It was a molecule that
takes 1/215th of a second to solve the problem.
It's still research. The paper didn't say (nor did
it pretend to say) how and when (or even if)
practical devices could be built from the technology.
Still interesting tho.
--
Dennis O'Connor [EMAIL PROTECTED]
Vanity Web Page: http://www.primenet.com/~dmoc/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Wed, 16 Aug 2000 10:32:33 +0200
John Savard wrote:
>
> On 15 Aug 2000 16:54:32 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote, in
> part:
> >Terry Ritter <[EMAIL PROTECTED]> wrote:
>
> >> That's a wrong answer: The construction as described in BB&S first
> >> guarantees that cycles of a given length must exist, and then shows
> >> how to check that x0 is on such a cycle. The check is thus absolute
> >> proof that a short cycle has not been selected.
>
> >No, it only shows the cycle length for the sequence <x_i>, not the
> >sequence of parity bits.
>
> Since the BBS modulus can't be a power of two, I don't think you have
> to worry about that.
Do I understand correctly that you claim that the cycle
length of <x_i> equals the cycle length of the parity bits
(either the normal definition or LSB)? Thanks.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Choosing parameter sizes (was Re: OTP using BBS generator?)
Date: Wed, 16 Aug 2000 10:35:44 +0200
David Hopwood wrote:
> Mok-Kong Shen wrote:
> > Mark Wooding wrote:
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > > My point is that at any given time, e.g. now, we'll have difficulty of
> > > > rigorously quantifying the 'difficulty' in question? Should we measure
> > > > it in terms of cpu-time of factoring the given numbers by a
> > > > 'particular' algorithm, or what? (The choice of the algorithm would be
> > > > an issue.)
> > >
> > > Cost of the cheapest implementation, in dollars, normalized according to
> > > running time (and probability of success, for special-purpose
> > > algorithms). This takes into account the heavy memory requirements and
> > > other similar issues raised by algorithms such as the number field
> > > sieve.
> >
> > I am afraid that such a measure tends to be rather inaccurate
> > or dependent on factors that are not ubiquitously present
> > and hence more or less vague for the reader.
>
> Yes, and that's why a fairly generous "fudge factor" should be added to the
> key lengths predicted to be necessary from cost, time, and/or space estimates.
> Fortunately this is quite practical, because the time needed to perform a
> cryptographic operation for a modulus of length k bits only increases as
> roughly k^c, where c is typically between 2 and 3. Hence we can choose
> parameter sizes that hopefully compensate for any inaccuracies in the model
> (and to a certain extent for algorithmic improvements in factoring, if they
> are not too large).
Thank you. I suggest using the term 'safety factor' which
sounds better and is commonplace in engineering.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Nick Maclaren)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Date: 16 Aug 2000 08:42:41 GMT
In article <8ndil2$ql8$[EMAIL PROTECTED]>,
Dennis O'Connor <[EMAIL PROTECTED]> wrote:
>> Wow .. this technology is moving fast! In 2Q98 there were still
>> many physicists doubting that anyone could ever make a model that
>> could remain coherent for more than one or two operations at a time,
>> and now here's IBM in 3Q00 demo'ing a 215 Hz system!
>
>It wasn't a 215 Hz system, It was a molecule that
>takes 1/215th of a second to solve the problem.
>
>It's still research. The paper didn't say (nor did
>it pretend to say) how and when (or even if)
>practical devices could be built from the technology.
But it did say when they couldn't! I.e. it said that scaling the
design is non-trivial, to put it mildly, and you can reasonably
expect that there will NOT be a breakthrough in the next couple
of years. At least not based on this approach.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: [EMAIL PROTECTED]
Tel.: +44 1223 334761 Fax: +44 1223 334679
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Proposal of drafting rules of conduct of posting
Date: Wed, 16 Aug 2000 11:15:01 +0200
Mark Currie wrote:
>
> I essentially agree with you and I would support any move to improve the
> quality of the dialogs. However, I have the feeling that it will not work.
>
> Apart from obvious nastiness which is unnecessary, one of the other problems
> that I have found, even with e-mail, is that when you can't see the other
> persons face, you can often misinterpret the harshness of a point, and usually
> interpret it more negatively than it was originally intended to be.
I agree in principle with you. This is why a telephone
call (even better with picture) is sometimes better than
a letter and important commercial or political contracts
have to be made with the partners present in person.
However, there are commonly used conventions of extracting
the 'semantics' from a document. One can't with 100.0%
security do that but in most case of ordinary life I
would say that one has at least 95% of chance of truly
ascertaining whether a given writing contains
(intended) malicious expressions, including derision,
affront, insult and (explicit) lies and similar such
stuffs. As long as such phenonema continue time and
again to be encountered in the group, there is ZERO
chance of tomstd's dream (of seeing a number of top
crypto scientists on his wish-list visiting us) ever
coming true!
M. K. Shen
------------------------------
** 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
******************************
