Cryptography-Digest Digest #688, Volume #13 Wed, 14 Feb 01 16:13:00 EST
Contents:
Re: What is an Inorder Algorithm? (Dave Seaman)
Re: Test and input wanted on new encoder. ("Frog2000")
Re: What is an Inorder Algorithm? ("Robert Hill")
Re: What is an Inorder Algorithm? (Richard Heathfield)
Re: Sky TV ("Julian Lewis")
pgp and 3Com ("Archon")
/dev/random under Linux (JCA)
Re: Big Numbers in C/C++ ("Michael Scott")
Re: Factoring (and not the Philippino :) (Benjamin Goldberg)
Re: /dev/random under Linux (Benjamin Goldberg)
Re: /dev/random under Linux (Mike Rosing)
CD ENCRYPTION (cuzinlarry70)
Re: Big Numbers in C/C++ (JCA)
Re: CD ENCRYPTION ("Sam Simpson")
Re: CipherText patent still pending (Kenneth Almquist)
Re: CipherText patent still pending ("Douglas A. Gwyn")
Looking for APRCLB (an improved version of APRCL by Wieb Bosma) ("Dann Corbit")
Re: National Security Nightmare? ("CMan")
SHA-1 (was Re: Password authentication ...) (David Hopwood)
Re: Random Numbers (David Hopwood)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dave Seaman)
Crossposted-To:
comp.lang.c,alt.comp.lang.learn.c-c++,sci.math,comp.lang.c++,comp.lang.java.programmer,comp.programming
Subject: Re: What is an Inorder Algorithm?
Date: 14 Feb 2001 09:18:24 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Riordan wrote:
>[snip]
>> Imagine the following tree-like structure
>> A
>> / \
>> B C
>> Then postorder would process in the order:
>> B, C, A
>> Pre-order would go:
>> A, B, C
>> & In-order would go:
>> B, A, C
>I am not quite sure of that. According to Knuth, vol. 1,
>one will have:
>Postorder: B, A, C.
>Preorder: A, B, C.
>Endorder: B, C, A.
We are talking about binary trees here, not arbitrary trees and not
forests. According to section 2.3.1 of the third edition, "Traversing
Binary Trees", the algorithms are:
Preorder traversal
------------------
Visit the root
Traverse the left subtree
Traverse the right subtree
Inorder traversal
-----------------
Traverse the left subtree
Visit the root
Traverse the right subtree
Postorder traversal
-------------------
Traverse the left subtree
Traverse the right subtree
Visit the root.
Therefore Riordan's explanation is correct according to Knuth.
--
Dave Seaman [EMAIL PROTECTED]
Amnesty International calls for new trial for Mumia Abu-Jamal
<http://www.amnestyusa.org/abolish/reports/mumia/>
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Test and input wanted on new encoder.
Date: Wed, 14 Feb 2001 09:36:07 -0500
Thanks for all the responses via e-mail.
--
http://welcome.to/speechsystemsfortheblind
"Frog2000" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> I'd appreciate any input, especially on the algorithm for this encoder.
> Encoder is in executables and DLLs. The algorithm should give a good
method
> for testing.
>
>
> --
> http://welcome.to/speechsystemsfortheblind
>
>
>
>
------------------------------
Crossposted-To:
comp.lang.c,alt.comp.lang.learn.c-c++,sci.math,comp.lang.c++,comp.lang.java.programmer,comp.programming
From: "Robert Hill" <[EMAIL PROTECTED]>
Subject: Re: What is an Inorder Algorithm?
Date: Wed, 14 Feb 2001 14:39:33 GMT
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>
>I am not quite sure of that. According to Knuth, vol. 1,
>one will have:
>
>Postorder: B, A, C.
>Preorder: A, B, C.
>Endorder: B, C, A.
The terminology "preorder, postorder, endorder" is one that Knuth used
in the first edition (1968) of volume 1, but came to regret soon after.
By the second edition (1974) he had changed it to
"preorder, inorder, postorder".
------------------------------
Date: Wed, 14 Feb 2001 14:47:54 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.c,alt.comp.lang.learn.c-c++,sci.math,comp.lang.c++,comp.lang.java.programmer,comp.programming
Subject: Re: What is an Inorder Algorithm?
Dave Seaman wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >Riordan wrote:
>
> >[snip]
>
> >> Imagine the following tree-like structure
> >> A
> >> / \
> >> B C
>
> >> Then postorder would process in the order:
> >> B, C, A
> >> Pre-order would go:
> >> A, B, C
> >> & In-order would go:
> >> B, A, C
>
> >I am not quite sure of that. According to Knuth, vol. 1,
> >one will have:
>
> >Postorder: B, A, C.
> >Preorder: A, B, C.
> >Endorder: B, C, A.
>
> We are talking about binary trees here, not arbitrary trees and not
> forests.
Just a nit - The OP didn't specify binary trees, or indeed trees of any
kind.
What he /did/ specify was pretty well every newsgroup under the sun.
Utter foolishness.
<snip>
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: "Julian Lewis" <[EMAIL PROTECTED]>
Subject: Re: Sky TV
Date: Wed, 14 Feb 2001 15:47:52 +0100
Reply-To: "Julian Lewis" <[EMAIL PROTECTED]>
>
> Not in America, the greatest country in the world.
> -*---*-------
Except if you are a black pregnant nun and on death row
------------------------------
From: "Archon" <[EMAIL PROTECTED]>
Subject: pgp and 3Com
Date: Wed, 14 Feb 2001 16:45:24 -0800
I have a 3Com NIC which runs dynamic access. when I try to secure my adapter
with pgp, to make a vpn connection, it tells me that the incorrect adapter
is secured.
Can anyone help me with what to do ?
/Esben
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: /dev/random under Linux
Date: Wed, 14 Feb 2001 07:39:12 -0800
I wonder if anybody is aware of any studies concerning
the goodness of the random data spit out by /dev/random
under Linux?
I am trying to collect sufficient amounts of such data myself
so that I can subject it to the Diehard tests, but I am getting
sick and tired of having to move the mouse or typing rubbish
in order to keep the entropy pool reasonably active.
In addition, the fact that such pool becomes really active only
when I indulge in such activities, which are far from random,
makes me somewhat suspicious.
Finally, I suspect there must be studies out there that go to
greater depths than I ever could.
Any pointers will be most welcome.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Big Numbers in C/C++
Date: Wed, 14 Feb 2001 10:30:30 -0600
See http://indigo.ie/~mscott
Mike Scott
"Edward Rustin" <[EMAIL PROTECTED]> wrote in message
news:Pine.SOL.4.21.0102141212200.21409-100000@tao...
> Hi,
>
> Does anyone know where I can find information about working with big (1024
> bit+) numbers under C or C++?
>
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Factoring (and not the Philippino :)
Date: Wed, 14 Feb 2001 17:49:21 GMT
Michael Brown wrote:
[snip]
> The only problem that I have at the moment is for solving for when the
> 2 LSBs of the product are not both 1 (however, this should immediately
> kill ~50% of current RSA keys I presume? That's an interesting
> question - do 50% of prime numbers have a second least significant bit
> of 1?). The algebraic approach works, and is fairly easy to see how to
> implement (constant*a combination of a's and b's), but hard to
> actually implement.
Since all prime numbers >2 are odd, all prime numbers used by RSA will
have the LSB set.
--
A solution in hand is worth two in the book.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: /dev/random under Linux
Date: Wed, 14 Feb 2001 18:04:11 GMT
JCA wrote:
[snip]
> In addition, the fact that such pool becomes really active only
> when I indulge in such activities, which are far from random,
> makes me somewhat suspicious.
Even though which keys are typed and the (deltax,deltay) of the mouse
may be quite nonrandom, the LSB of the clock at each keystroke or
movement is fairly unpredictable.
--
A solution in hand is worth two in the book.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: /dev/random under Linux
Date: Wed, 14 Feb 2001 12:32:41 -0600
JCA wrote:
>
> I wonder if anybody is aware of any studies concerning
> the goodness of the random data spit out by /dev/random
> under Linux?
>
> I am trying to collect sufficient amounts of such data myself
> so that I can subject it to the Diehard tests, but I am getting
> sick and tired of having to move the mouse or typing rubbish
> in order to keep the entropy pool reasonably active.
>
> In addition, the fact that such pool becomes really active only
> when I indulge in such activities, which are far from random,
> makes me somewhat suspicious.
>
> Finally, I suspect there must be studies out there that go to
> greater depths than I ever could.
>
> Any pointers will be most welcome.
I've been interested but haven't had time to get into it much.
check out "man 4 random" and chase down the source code. There's
nothing to be suspicious of, it's how it works.
Eventually I'd like to add an external hardware RNG to my linux
box and I always assumed /dev/random was the way to go. I guess
I'll have to figure it out when I get there (gonna be a while....)
Patience, persistence, truth,
Dr. mike
------------------------------
From: cuzinlarry70 <[EMAIL PROTECTED]>
Subject: CD ENCRYPTION
Date: Wed, 14 Feb 2001 18:57:56 GMT
Hello
Can someone tell me if this is possible or if there is applications that
do this.
I have many files with private documents, spreadsheets, and other very
private information. I would like to burn all of these files onto CDs.
However, I would like it so that when the CD is entered in the drive,
you have to type in a password so that you can "unlock" the CD for
viewing the files. Once the CD is unlocked then information can be read
freely and no other passwords have to be entered. I'm imagining a
program that is located on the CD that scrambles the files and then
unscramples them when it is time to open them.
There are two thinkg to note:
1. The CD has to be able to be "unlocked" on any computer and not
require speacial software because the CDs will be distributed to select
people. For example, I tried the E4M program (encrytption for the
masses),
and it didn't work because if the end user does not have E4M intalled,
then they
can't recognize the file.
2. Please don't suggest a password protected .zip or .rar file. I
tried this and it takes 10 years for all of the files to be de
compressed. There are numerous files and they need to be accessed
quickly.
I appreciate any help. Hopefully there is a free program that will do
this.
Thanks
--
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Big Numbers in C/C++
Date: Wed, 14 Feb 2001 10:36:54 -0800
Use your favorite search tool and search for LiDIA (Arjen Lenstra's
C++ library) or GMP (the GNU arbitrary precision library.)
There are more out there, but I happen to be familiar with these two.
Edward Rustin wrote:
> Hi,
>
> Does anyone know where I can find information about working with big (1024
> bit+) numbers under C or C++?
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: CD ENCRYPTION
Date: Wed, 14 Feb 2001 20:00:34 -0000
Try Scramdisk in 'Traveler Mode'.
Follow-ups to alt.security.scramdisk please.........
--
Regards,
Sam
http://www.scramdisk.clara.net/
cuzinlarry70 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello
>
> Can someone tell me if this is possible or if there is applications that
>
> do this.
>
> I have many files with private documents, spreadsheets, and other very
> private information. I would like to burn all of these files onto CDs.
> However, I would like it so that when the CD is entered in the drive,
> you have to type in a password so that you can "unlock" the CD for
> viewing the files. Once the CD is unlocked then information can be read
>
> freely and no other passwords have to be entered. I'm imagining a
> program that is located on the CD that scrambles the files and then
> unscramples them when it is time to open them.
>
> There are two thinkg to note:
>
> 1. The CD has to be able to be "unlocked" on any computer and not
> require speacial software because the CDs will be distributed to select
> people. For example, I tried the E4M program (encrytption for the
> masses),
> and it didn't work because if the end user does not have E4M intalled,
> then they
> can't recognize the file.
>
> 2. Please don't suggest a password protected .zip or .rar file. I
> tried this and it takes 10 years for all of the files to be de
> compressed. There are numerous files and they need to be accessed
> quickly.
>
> I appreciate any help. Hopefully there is a free program that will do
> this.
>
> Thanks
>
>
>
> --
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: CipherText patent still pending
Date: 14 Feb 2001 20:09:53 GMT
> On Fri, 9 Feb 2001 17:13:38 GMT, in <[EMAIL PROTECTED]>,
> in sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>
>> Terry Ritter wrote:
>>> In some ways, the pharmaceutical analogy to cryptography is good. But
>>> our situation is that *we* *really* *don't* *know* the dangers of
>>> *any* of the ciphers we use, yet we use them anyway.
As far as I know, no one has ever proved that a drug was safe or
effective using the laws of chemistry, so the analogy holds here.
>> However, we have the analogue of clinical trials and feedback from
>> actual use by physicians. To continue the analogy, we don't throw
>> drugs out to the physicians expecting them to perform the clinical
>> trial phase for us. Prefiltering the possibilities is an
>> essential function that the pharmaceutical companies perform.
>
> One problem with analogies is that they can be subtle when they lead
> us into false reasoning, as is the case here:
>
> First, drugs are a profitable business which financially supports tens
> of thousands of careers in extensive analysis and testing; ciphers are
> not. The importance of financial support can scarcely be overstated.
> Some consequences include: 1) there is no developed process of cipher
> testing which in any way compares to the controlled trials of drug
> tests; 2) drug test results are published independent of outcome,
> while crypto results are normally published only when the cipher
> fails; 3) failure in drug tests generally leads to a sequence of
> different compounds and new tests, an iterative process much
> deprecated in cryptography.
Protecting the security of interbank transfers is one application
where the market demand has a lot in common with the demand for a
pharmaceutical drug. First, banks are willing to pay large amounts
of money for a successful solution. Second, success is obvious in
retrospect, since a bank's auditors will notice the theft of a few
hundred million dollars.
If banks were losing money because triple DES was broken, they would
probably switch to AES. If AES was also broken, they would switch to
something else. Eventually, after enough failures, the sort of
testing infrastructure which exists for drugs might be developed for
encryption algorithms. But in fact triple DES is currently doing a
fine job of protecting interbank transfers. So one reason that more
money is not being spent to ensure the security of encryption algorithms
is that the amount of money being spent now is sufficient to meet
the needs of the customers who have lots of money to spend.
> Basically, the drug business has the goal of finding or making a new
> profitable drug and they go about it to achieve success. In contrast,
> the major result of a new cipher is more likely to be argument than a
> step in product development. These are wholly different processes.
The other reason why there is not a cipher major development industry
is that the there is not a sufficient variety of "ailments" for cipher
designers to solve. Banks use a "generic" brand cipher (triple DES)
rather than a patented cipher such as IDEA. They won't switch to
something else unless the alternative provides some significant
advantage over triple DES. If triple DES only worked with financial
transactions, an enterprising cryptographer could invent a cipher that
protected erotic love letters and the result might be as popular (and
financially successful) as Viagra.
A new drug is likely to be profitable only if it does something that
existing drugs don't do. RSA was incorporated into new products,
despite having been developed in an academic setting. If you just
develop another secret key cipher, or even another public key cipher,
it is hard to turn that into a product because it doesn't do anything
new.
> New ciphers provide new opportunities for proof. The goal is to get
> both a cipher and a proof. We know that 25 years of Feistel ciphers
> and related proof approaches have not achieved the goal. If we are to
> achieve success, we should expect to have to work with new ciphers.
What we need to achieve your goal is stronger results in complexity
theory. If P = NP, then no strong ciphers exist. So the first step
to building a cipher which is provably strong against any attack is
to prove that P != NP. After this is done, we can examine the proof
and try to extend it to show that some particular encryption algorithm
is secure.
Kenneth Almquist
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Wed, 14 Feb 2001 20:25:23 GMT
Kenneth Almquist wrote:
> What we need to achieve your goal is stronger results in complexity
> theory. If P = NP, then no strong ciphers exist. So the first step
> to building a cipher which is provably strong against any attack is
> to prove that P != NP. After this is done, we can examine the proof
> and try to extend it to show that some particular encryption algorithm
> is secure.
I don't think that approach would help much. Consider that so far
as we know, P = NP but we haven't found any proof of it yet. Oops,
did all our ciphers just fall apart? No.
Any real theorems about lower bounds on work required to invert a
function would have to deal with finite cases, not asymptotic
behavior as a size parameter increases to infinity, nor typical
behavior. (There have been cryptosystems whose typical case would
be intractible, but for which certain special cases could be cracked,
putting the attacker in possession of an equivalent key, which then
allowed recovery even in the typical cases.)
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Crossposted-To: sci.math.num-analysis
Subject: Looking for APRCLB (an improved version of APRCL by Wieb Bosma)
Date: Wed, 14 Feb 2001 12:12:39 -0800
Does someone know of an implementation of this algorithm or even a paper
describing it?
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Wed, 14 Feb 2001 14:09:49 -0700
Or possibly disinformation.
"Oh please Mr. Terrorist, don't use that unbreakable Phil Zimmerman code..."
said brer rabbit. "Oh please, anything but that nasty old PGP!!!"
Yeah, right!
JK
"JPeschel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Douglas A. Gwyn [EMAIL PROTECTED] writes:
>
> >JPeschel wrote:
> >> Hmmm... my bother-in-law at Ft Meade sent me this one.
> >..............^ Freudian slip?
> >
> Oops, well, for chrissake, don't tell him! :-)
>
> >Thanks for the link to the "news" story. (The quotes
> >are because it's not new news.)
>
> 'Twas new news to me!
>
> Joe
> __________________________________________
>
> Joe Peschel
> D.O.E. SysWorks
> http://members.aol.com/jpeschel/index.htm
> __________________________________________
>
------------------------------
Date: Wed, 14 Feb 2001 21:08:02 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: SHA-1 (was Re: Password authentication ...)
=====BEGIN PGP SIGNED MESSAGE=====
"Henrick Hellstr=F6m" wrote:
> I could give you two good reasons:
> =
> Steak is less biased than SHA1. SHA1 fails the random excursions tests,=
> whereas Steak doesn't.
I would be astonished if a valid, correctly applied, general-purpose [*]
randomness test was found to consistently fail SHA-1. Precisely which
test are you referring to?
[*] i.e. excluding tests contrived to depend on SHA-1 or to test for
the Merkle-Damg=E5rd construction.
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOonM0TkCAxeYt5gVAQELVggAskhMsv5FxR3L8dWammMsWqUl739E+uUA
0Z7N2sP3ez3PwHjjqiftDx5kydVAYMn9+abieLciiO8ngLfxb+tPiKIXw+gnLZwK
g59BDsgEuNCYiwtQjMXaIp7dNUS18pQDIWzRJiTBUfgkFEf96K6Zdbyg14EVFcu4
nUyCC8wRVuZsOg/KIC4fRfRZu080nFDLJilCm+T18PPLtT9uz/FrH/VCEfQJMgzA
o5C55mnIN1YhJGLyHbMz3F8f8WKKjs6ezLG+vMKKeK0+ys78aHEceT19B72l9zdH
rmXxpjBCJNgNwwPugVkpXmrtWUmEozdb+0WA4S6EVX7WcMTWXurg4g=3D=3D
=3DEugt
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 14 Feb 2001 21:09:02 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Random Numbers
=====BEGIN PGP SIGNED MESSAGE=====
Joseph Ashwood wrote:
> From here we have to examine what we are doing with this stream. A close
> examination of RC4 reveals that it becomes semi-predictable around the
> gigabyte mark, let's be pessimistic and set it's terminal distance to
> 1000000000 bit (1Gigabit), from for the sake of simplicity we assume smooth
> diffusion of entropy across those bits. From this we can state that each bit
> contains (on average) 127/1000000000 bits of entropy at a minimum, but much
> higher amounts of unpredictability. For the upper bound simply assume smooth
> diffusion across the length of the data being used, this becomes minimum(1,
> 127/length) bits of entropy per bit, it is very important to note the use of
> minimum here because a bit cannot contain more than 1 bit of entropy.
[Below I'll use "entropy" to mean information content; strictly speaking
entropy would be negative.]
Entropy is defined in terms of a probability distribution, which
(particularly in cryptology) must be considered in terms of the knowledge
of whoever is observing it.
- From the point of view of someone who has the key, the entropy of
the keystream is exactly zero.
- From the PoV of a computationally unbounded attacker, this entropy is
also exactly zero, provided sufficient keystream is available to
uniquely determine the RC4 key.
- From the PoV of a computationally bounded attacker who cannot break
RC4 (but who can take advantage of the biases described in published
papers), the entropy of any collection of n keystream bits is just
under min(128, n) bits.
Note that the entropy of the stream must be distinguished from the entropy
of the key. If the adversary is presented with the problem of guessing the
key without access to the keystream, then the entropy figure relevant to a
security analysis is 128 bits. If it is required to guess a particular bit,
given any amount of keystream but without being able to break RC4, then the
figure is just under 1 bit. If it is required to guess n bits, then the
figure is just under min(128, n) bits. It's meaningless to divide any of
these values by the total length of keystream (especially by some arbitrary
and ill-defined "terminal distance"), since the entropy of a section of
keystream does not increase linearly with length; in this case it increases
up to about 128 bits, then levels off.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOondeDkCAxeYt5gVAQFqaQgAinib92Ej1dhaa/yvUKJjX4Ec8kzsI7CX
c4OwJgMRNQUsBY6zf2CeMzPtsS9be+VZpD531LdFomZCicGyv1IMSCSjU+GvpTKa
LGZS6D2H4djWk1oleBdaOHk5Urb35olwga24dHm2ILqn9nxCgopGee7gQ9xl5Fha
Ud6/wha8XHifH/xuydPGuY0T51gCniRg8VseAhSUvEuBov65BI9gL3sHB466CQar
Dxo3IZXu4gSSpw4dRFQqwDdI1yAOiHfbPkl6kO2evKALYUD29/ynNqugCpZQnL++
XXFVMpUjVnUcGrFj2JxtZj2vh8s9EVmqlMcwRA5oH0C/ZL7vXhi/7w==
=UmV+
=====END PGP SIGNATURE=====
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
