Cryptography-Digest Digest #504, Volume #10 Wed, 3 Nov 99 23:13:02 EST
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Geoffrey T. Falk)
Re: Q: Removal of bias ([EMAIL PROTECTED])
A new thread disappeared ? (Mok-Kong Shen)
relative security of hashes, md5 vs. snefru (zentara)
Re: Q: Removal of bias (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Terry Ritter)
Re: Q: Removal of bias (jerome)
Public Domain DES type Encryption Lib? (Greg)
Re: Decreased risk using two encryption algorithms?
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Don Taylor)
What "BEGIN INTERNET CONNECTION KEY" is ? (Sang Yam)
questions about twofish ([EMAIL PROTECTED])
Re: Interesting LFSR (David Wagner)
Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto Comments...)
(jerome)
----------------------------------------------------------------------------
From: gtf[@]cirp.org (Geoffrey T. Falk)
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 23:42:26 GMT
In article <[EMAIL PROTECTED]>, CoyoteRed <CoyoteRed> wrote:
>On Wed, 03 Nov 1999 07:57:33 GMT, David Bernier <[EMAIL PROTECTED]>
>wrote:
>
>>Also, enclosing the entropy generator in a Faraday cage seems to me
>>to be a reasonable security precaution because:
>>(a) it attenuates interference from electro-magnetic radiation
>> coming from the outside...
>
>This is good because you may pick up noise from motors and such that
>is not random.
An attacker could also "broadcast" particular signals to you..
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
ADDRESS ALTERED TO DEFLECT SPAM. UNSOLICITED E-MAIL ADS BILLED $500
Geoffrey T. Falk <gtf(@)cirp.org> http://www.cirp.org/~gtf/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 23:40:22 GMT
Mok-Kong Shen asked:
> Could anyone give references to practical results of removal of
> bias in random number/bit sequences, showing the efficiency of
> the techniques?
What do you know about your input stream and what
do you require for the output stream? If I
described a method that returns the stream
0,0,0,0,... with probability 0.5 and the stream
1,1,1,1,... with probability 0.5, you would
probably object, even though for all i, the i'th
bit is equally likely to be 0 or 1.
Also, what's the definition of efficiency in this
context?
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: A new thread disappeared ?
Date: Thu, 04 Nov 1999 00:50:17 +0100
Yesterday morning I saw a new thread with a post containing a
proposal to encrypt message P with two algorithms using a random
string R and send out two ciphertexts. His wordings could be
expressed like this:
C_1 = E_1(R)
C_2 = E_2(P xor R)
But several hours later, when I tried to look at it again, the
thread disappreared. I like to know whether this is a problem
specific to my news server (i.e. you still see that article) or
other people also experienced the same rather strange phenomenon.
Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (zentara)
Subject: relative security of hashes, md5 vs. snefru
Reply-To: ""
Date: Thu, 04 Nov 1999 01:17:53 GMT
Hi,
I've read the faq on hashes, but it dosn't explain the
worthiness of the hash.
If 8 pass snefru is better than 4-pass, is it better than md5sum?
Am I comparing apples to oranges?
What do we mean by better? Merkle says it mathematically, that
if a combination can be found such that H(x)=H(y), where x does not
equal y, then the hash is cracked.
I'm more concerned with it's use in verifying files, especially in
detecting files hacked in such a way, that the md5sum would match.
The linux group is starting to use signed files made with gpg, to
verify files, suggesting that it is stronger than md5sum.
How does it qualitively compare to 8 -pass snefru?
Is this too broad of a question? What are your opinions
on the best method of verifying files, in descending order?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Removal of bias
Date: Thu, 04 Nov 1999 01:25:18 +0100
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen asked:
> > Could anyone give references to practical results of removal of
> > bias in random number/bit sequences, showing the efficiency of
> > the techniques?
>
> What do you know about your input stream and what
> do you require for the output stream? If I
> described a method that returns the stream
> 0,0,0,0,... with probability 0.5 and the stream
> 1,1,1,1,... with probability 0.5, you would
> probably object, even though for all i, the i'th
> bit is equally likely to be 0 or 1.
>
> Also, what's the definition of efficiency in this
> context?
Suppose one does a frequency count and finds that there is quite
a bit deviation from uniform distribution and applies different
methods to obtain a sequence of improved distribution, I like to
know which method is better, i.e. how they compare with one another
in practice, including also the computational costs. (The word
'efficiency' was used in the imprecise sense of normal conversation.
Sorry, if this was misleading.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 04 Nov 1999 00:46:45 GMT
On Tue, 02 Nov 1999 20:22:10 GMT, in <7vnh5d$fh6$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote:
>
>> Oddly, this doesn't sound like anything we have been talking about. I
>> have never heard -- and certainly never made -- a suggestion that the
>> adversary will choose the cipher.
>
>You certainly have heard such a suggestion. Yes, you
>failed to consider the chosen cipher attack, and now
>it seems that you confuse failure to recognize the
>problem with not having it.
A "chosen cipher attack" would imply that the opponent could choose
the cipher to be used. That is not possible here.
Under my proposals (multi-level ciphering, dynamically changing
ciphers, and many ciphers), the cipher would be chosen at random from
the set of ciphers acceptable to both ends. The cipher lists may or
may not be secret, but the negotiation and selection *would* be
secret. This process would be conducted under cipher.
Clearly, negotiations can occur under cipher only *after* an original
cipher and key have been selected. This is the normal key management
problem. Cipher negotiation does not solve that.
If user authentication is to be effective, it must occur *before* we
start talking under cipher: We cannot hope to identify a
man-in-the-middle from information which we share with the other end.
So before we share anything of consequence we must already be sure
there is no MITM. One possibility is to authenticate the other end by
authenticating (certifying) our public keys. Dynamic cipher
negotiation and selection occurs only after this.
>> On the contrary, I have suggested
>> that each user be able to create a list of ciphers they will accept,
>> and then negotiate agreement -- automatically, in the background, and
>> secretly, under the cover of cipher. This would be an ordinary
>> handshake selection, not a cryptographic protocol, but nevertheless
>> clearly neither exposed to nor under the control of the opponents.
>> How is that related to the adversary choosing the cipher?
>
>As I noted some time ago, your writings made the point
>that the choice of cipher was secret, but were clearly
>oblivious to the fact that authentication of the choice
>is more important.
OBVIOUSLY, any cipher code can be compromised. That is the case with
any cipher system. That is why DES was originally for hardware only.
We don't want to use compromised code. And simply making the source
available for review is unlikely to be helpful to most users.
Presumably, various free cipher systems will be sufficiently well
known and analyzed to be trustable. Some users may want to obtain
their ciphers from a reliable commercial source. But surely nobody
imagines going out on the net and saying "hey, somebody send me <xxx>
cipher," and then trusting anything which came in.
Yes, the cipher code itself must be trustable.
>The details of your protocols have
>never appeared, so we cannot tell whether the attack
>would work. The fact that you still compare the
>negotiation of the cipher to modem protocols, and call
>it "an ordinary handshake selection, not a cryptographic
>protocol" is rather ominous.
How hard do you want to make this?
Selecting a cipher from among a list of approved ciphers simply does
not require a cryptographic protocol. I'm sure we could do all sorts
of fancy things, and it may be that the selection channel should have
additional protection. But the selection itself is straightforward.
It is just like two people talking. It is unimportant which cipher we
select, as long as both ends agree. The idea is not to select the
"best." Indeed, we want to *avoid* selecting "the" best cipher, so
that we can select arbitrarily from among a rather large set.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 04 Nov 1999 01:00:46 GMT
On 31 Oct 1999 02:39:57 GMT, in <7vga5t$i9m$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>Terry Ritter ([EMAIL PROTECTED]) wrote
>
>]
>]Whatever frequency "inaccuracies" may exist, will continue to exist,
>]in the exact same way, over time. We don't expect crystal oscillators
>]to accumulate or generate entropy.
>
> That's not entirely accurate. Since the quartz crystals dissipate mechanical
> energy (by not being ideally elastic), they must then neccessarily produce
> random, thermal vibrations (look up fluctation-dissipation
> theorem in Graduate Stat. Phys. text)
Quartz crystals do dissipate energy, they just dissipate very little
energy.
I suspect that thermal energy in crystals will produce electrical
noise, but of course thermal noise is uncorrelated across the surface
plating, so it will mostly "average out." We know that any such noise
is far below the level of normal crystal operation, even when crystals
are used at very low powers (as in narrow-band IF filters in
receivers), because if crystal noise was an issue, there would be
crystals optimized to produce the minimum amount of noise.
>]
>](Small frequency drifts over minutes or hours or days do exist which
>]have a thermal origin. Start-up variations may be very similar from
>]one start to the next.)
>
> It's not just drifts. That is, I would expect those drifts to be like
> brownian random walk. It would probably make a neat exercise for
> a Graduate level statistics course.
You expect incorrectly. Crystals have been used in radio engineering
since the 20's, and their basic properties are well known. The
crystal resonant frequency does vary with temperature, and this is
repeatable, not random.
>]
>](Picosecond-scale phase variations do exist which are noise-like; I
>]attribute those to thermal noise in the analog-to-digital squaring
>]process. But these tiny cycle-by-cycle bipolar variations average out
>]to what we know as the frequency, and are not detectable using normal
>]computing equipment.)
>
> No, no, no. You are not correct.
In crystal oscillators, only the tiny cycle-by-cycle "phase" jitter is
noise-like, and that is not detectable with normal computing
equipment. This phase noise is detectable with precision radio
equipment, or with precision logic and super-high-frequency clocks
intended to measure periods of fast signals. Phase noise "averages
out" over the many cycles needed to establish frequency by counter or
timing methods.
You may wish to read an earlier Usenet discussion about pulling
randomness out of PC crystal oscillators:
http://www.io.com/~ritter/RAND/NICORAND.HTM
And you may wish to look at the background technical information on
the Fox Crystals site:
http://www.foxonline.com/techinfo.htm
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Q: Removal of bias
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 00:59:30 GMT
On Wed, 03 Nov 1999 17:58:33 GMT, Scott Nelson wrote:
>
>Assuming a biased bit which is '1' .75 and '0' .25
>(entropy = 0.8112781)
>Using XOR to combine N bits,
> 1 bits: Entropy = 0.8112781
> 2 bits: Entropy = 0.9544340
> 3 bits: Entropy = 0.9886994
> 4 bits: Entropy = 0.9971804
>(after 12 bits, it's 1.0 to seven places.)
i don't understand what do you mean by "after 12 bits, it's 1.0 to
seven places" can you please explain ?
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Public Domain DES type Encryption Lib?
Date: Thu, 04 Nov 1999 01:05:00 GMT
Does anyone know where I can get a block cipher of a DES type
of say 56, 64, or 128 bit strength, that is public domain and
I can merge into my own software?
--
The only vote that you waste is the one you never wanted to make.
RICO- a small surrendering of our civil liberties.
Asset Forfieture- a large confiscation of our civil liberties.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Decreased risk using two encryption algorithms?
Date: 4 Nov 99 01:21:27 GMT
Brent J. Nordquist ([EMAIL PROTECTED]) wrote:
: Suppose you then encrypt X and X' using two different algorithms, perhaps
: one that relies on factoring and one that doesn't, and transmit both
: messages.
I once saw an article in Cryptologia that called this the Aryabhata
cipher, although that wasn't accurate, others have said.
The catch is that it doubles the length of your message, and is not
believed to be more secure than simply encrypting the message in one
method and then in the other. But it seems to offer better resistance to
analysis than ordinary double encryption, even if it, of course, offers
nothing against a brute-force search.
John Savard
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Thu, 04 Nov 1999 02:33:55 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>to save space, snipping a bunch of stuff that we seem to be in
>agreement on, generally....
>
>On Wed, 3 Nov 1999 02:36:58 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>>Tom <[EMAIL PROTECTED]> wrote:
>>: On Sun, 31 Oct 1999 11:03:30 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>:>Tom <[EMAIL PROTECTED]> wrote:
>>:>: (SCOTT19U.ZIP_GUY) wrote:
>>:
>>: The "so what" is that this one-one-one scheme is being touted as an
>>: absolutely better way to compress than standard compression [...]
>>
>>I'm not touting it as such. A o-o-o compression schem that leaves the
>>file unchanged may frequently be /worse/ than using a decent compressor.
>>
>>o-o-o *on it's own* does not necessarily offer any security.
>>
>What I'm begnning to wonder is if the information that's said to be
>added information in non o-o-o can really be considered to be a
>byproduct of the standard compression algorithm not fully compressing,
>similar to that of low ratio o-o-o leaving patterning behind. DS has
>claimed that the two types of information present different types of
>weaknesses, but this leads me to question if it's true if the type of
>plaintext file (and thus it's patterning) is known.
I think your actaully Tommy St Dennis since you don't seem to understand
what is goin on. And seem not to actaully read the posts.
Again if you don't use o-o-o compression you open your self up
to cipher only attacks. Do you understand this point before we go
into other areas to explore.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: Don Taylor <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Crossposted-To: comp.compression
Date: 3 Nov 1999 19:43:09 -0600
In comp.compression Tim Tyler <[EMAIL PROTECTED]> wrote:
> In sci.crypt <[EMAIL PROTECTED]> (i.e. my good self) wrote:
> : The document is located at http://www.alife.co.uk/securecompress/
> An alternative to this scheme has been proposed to me by email.
> This scheme /appears/ to be simpler and offers better performance.
> It has fewer constraints on the dictionary used.
> I expect to be away from usenet for a week.
> On the offchance that nobody else presents the scheme in the interim,
> I hope to write more about it upon my return ;-)
I though of something this morning. I sent a version of this to Tim
Tyler asking him if I had done something completely silly. He was busy
with other things but was kind enough to take a few minutes of his time
to make some comments. He seemed to think that I might not be
completely confused about this. But, any mistakes in this are still
all my responsibility.
==============
It seems that most difficulties that people are debating in this
one-to-one compression discussion are because of the way that the
problem has been phrased. If I look at all the conditions and try to
rethink this JUST using those conditions I think I come to a very
different place, but that I still seem to satisfy those conditions.
I think that much of the confusion results from using the same alphabet
for both halves of each dictionary entry.
Consider the following dictionary
a 1
apple 2
banana 3
house 4
...
Now, I claim that the dictionary contains all the words that might be
used in messages, we just mandate that it contains the vocabulary that
people will use for messages. But we do make the vocabulary large
enough that it contains an adequate set for communication.
The left hand side consists of words created from an alphabet while the
right hand side consists of only numeric codes, these are NOT strings
of digits, they are just codes. All words in all messages will be
separated from each other by a single blank. And the translated codes
will just be concatenated.
Translation becomes transparently obvious, get the next word, look up
that word in the dictionary and output the code. To reverse the
translation, get the next code, look it up, and output the word. (and
we can encode that number into the underlying stream for the message to
be sent in a suitable and obvious way).
It is guaranteed that it is 1-1. Take any string of words and they
become the obvious string of codes. Take any string of codes and they
become the obvious string of words.
All the questions about whether the message is maintained by any number
of translations back and forth is settled in a single stroke. All the
issues of prefixes and suffixes are settled. But the whole business of
prefixes and suffixes and how words might be looked up doesn't really
seem to be the essential core of what was originally being debated,
which was whether there could be a one-to-one comression scheme.
The codes are shorter than the words, because I claim that for any
'reasonable' human vocabulary the number of bits needed to represent
the average message using codes is less than the number of bits needed
to represent the message using characters, because of the redundancy
built into the construction of human words. So we have accomplished
the desired compression using this scheme.
For example, we can allow say 2^16 different words, a very reasonable
vocabulary for any specialty, and in english, with an average length >5
bytes for words constructed from characters, the compressed result only
requires a length of 2 bytes to express the code for each translated
word.
(And we can even do further tricky things *with the representation of
the codes* that would unambiguously let more common words be
represented by shorter codes, but that is a separate issue and I don't
want to make this more complicated, it can be done in an understandable
and unambiguous fashion.)
SO, the question: hasn't this satisfied the conditions, replacing long
words by shorter replacements AND made this 1-1 AND guaranteed that no
number of repeated translations will ever give anything other than
something valid on the other side AND done this with an adequate
vocabulary for message communication?
I have stared at this for a while and I think it satisfies the rules,
even better than some of the examples that have been tossed out.
If you think that I have missed something I would love to have that
pointed out to me. And if you think that this has cut to the essential
core of the 1-1 compression that was being proposed then perhaps we can
move forward and explore the central issues.
(I think it is POSSIBLE to provide an escape valve to allow words that
are not in the dictionary to be handled also but I would have to
scribble for a while to make certain that I have not broken this by
doing so)
thanks
don
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
Date: Thu, 04 Nov 1999 09:59:02 +0800
From: Sang Yam <[EMAIL PROTECTED]>
Subject: What "BEGIN INTERNET CONNECTION KEY" is ?
I use the Lotus Go Webserver's mkkf.exe utility to export the key from
Lotus Domino's keyfile.kyr and the exported file is enclosed by "BEGIN
INTERNET CONNECTION KEY" and "END INTERNET
CONNECTION KEY. What kind of format this file is ? Also, does anyone
know any reference for those "BEGIN.....", e.g. "BEGIN CERTIFICATE",
"BEGIN CERTIFICATE REQUEST", "BEGIN RSA PRIVATE KEY" ?
--
Best Regards,
===================================
:) Sang Yam :)
Media Information Technology Ltd
Tel: (852)2887-7441 ext 114
Fax: (852)2887-7449
mailto:[EMAIL PROTECTED]
http://www.media-i-t.com
------------------------------
From: [EMAIL PROTECTED]
Subject: questions about twofish
Date: Wed, 03 Nov 1999 16:21:22 -0800
In counterpane's optimized twofish, there are different options you can
choose during compilation like zero, partial, or full key.
First,
What are the advantage/dis-advantages.
Do they affect security, or is it just a memory/speed trade-off.
Second,
What's the difference between using the 192 bit key option, and using
the 256 bit key option with 64 bits zeroized (both still have same key
space).
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Interesting LFSR
Date: 3 Nov 1999 18:13:18 -0800
In article <[EMAIL PROTECTED]>,
John E. Kuslich <[EMAIL PROTECTED]> wrote:
> For each byte of key generated, the SR is first shifted one byte then a
> new byte is loaded into the empty end of the SR which is computed on the
> following basis:
>
> All odd bytes are XORed and used as an index to a table, also all even
> bytes are Xored and used as an index to a different table. The tables
> are not single valued i.e. and index od 0x15 may reference a value of
> 0xFE or an index of 0x25 may also index a value of 0xFE. Most of the
> table values are unique, but not all. Each table has 256 byte vaues.
>
> Both these odd and even values are then Xored and used for the new byte
> at the empty end of the SR.
(I assume you compute the new value before you shift.)
Why not just run it backward, keeping track of the _set_ of all possible
states? If you implement it, I strongly suspect you will find that this
set usually stays very small.
(Sometimes some states have multiple predecessors, which grows the set,
but also some states have no predecessors, which shrinks the set, and the
two effects are expected to cancel each other out almost exactly. I'll
omit the mathematical calculations.)
Worth a try...
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto
Comments...)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 02:18:24 GMT
On Mon, 01 Nov 1999 15:37:47 GMT, Doug Stell wrote:
>
>This is very true for the reasons Bruce states. Years ago, there was
>almost no open cryptographic research and the NSA had plenty of
>resources. In recent years cryptography is a very active area in
>industry and academia, while the NSA finds themselves with very
>limited resources. My NSA contacts have openly stated that they expect
>most work, including algorithm work, to be done in the open community,
>including -gasp- the IETF. We now find NSA people participating in the
>open community, publishing papers, providing valuable assistence and,
>after some initial scepticism, being accepted.
You seem reasonable and you arn't the first one to say that the NSA
is no more far ahead the open community, one of them is diffie,
so i will assume it is true during this post and try to see the
consequences.
1. If i read correctly, you speak about the cryptography but not the
cryptanalyse. You even point that the open community has a "lack
of motivation at cracking system". is the NSA working only on
cryptanalysis ?
2. You give an example of a weakness in a key schedule in which they
are one year ahead. I am aware that it is a isolated example
which cant be generalized but lets assume they are only 1 year
ahead on cryptanalysis and not only on this example.
The open community do find attacks against systems, but either they
aren't pratical or the cryptosystem wasn't really trusted at the
begining (ie. it was written by beginners or by a compagny known
to make unsecure products).
So if the NSA is just a bit higher than that, they can't get
information from cryptanalysis because from the assumption, NSA was
still unable to break any serious system 1 year ago.
so how do they get their informations ? eavedropping of uncrypted
communications ? backdoor ? traffic analysis ?...
ps: I just want to understand. I am not a paranoid anti-NSA and won't
reply to such posts.
------------------------------
** 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
******************************
