Cryptography-Digest Digest #665, Volume #10 Thu, 2 Dec 99 14:13:02 EST
Contents:
Any negative comments about Peekboo free win95/98 message encryptor
([EMAIL PROTECTED])
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: AES cyphers leak information like sieves (wtshaw)
Re: Why Aren't Virtual Dice Adequate? (Guy Macon)
Re: Encrypting short blocks (wtshaw)
Re: Use of two separate 40 bit >> tony >> Where you posting from ? [
([EMAIL PROTECTED])
Re: Elliptic Curve Public-Key Cryptography (Medical Electronics Lab)
Please Check my understanding of Montgomery Algorithm (Vasudev Pai)
Re: Quantum Computers and PGP et al. (Jim Dunnett)
Re: Ultimate Crypto Protection? (Jim Dunnett)
Re: Decyption proof cellphones in Europe? [x3] (Jim Dunnett)
Quantum Computers and Weather Forecasting (John Savard)
Re: Decyption proof cellphones in Europe? [x3] (Eric Pinnell)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp
Subject: Any negative comments about Peekboo free win95/98 message encryptor
Date: Thu, 02 Dec 1999 12:09:41 -0500
Any / negative comments / evaluations / possible back-door entry / stableness /
known software & hardware conflicts /
about Peekboo free win95/98 message encryptor program ?
It is listed on site http://www.counterpane.com/products.html because it is
using Blowfish [ some sort of endorsement from Blowfish creator ].
The main site is at http://www.cell2000.net/security/peekboo/index.html
The program is provided in 1 [ ONE ] executable only >> extremely secure in
extremely insecure win95 environment.
Executable is extremely small >> less than 50 kB.
Peekboo is freeware & current Source Code publicly available.
The program is modestly new [ the first Public Key on site is dated Sep 28 /
1999 ]
Peekboo is a free win95/98 message encryptor program. It has many features which
will be discussed on the other pages. It basically allows for secure
communication with any person (even people you have not physically met yet)
using any text medium (such as email or chat programs).
Current Release is v1.73 (Nov 23rd 1999)
The main problem it tries to solve is insecure transportation of text messages
over any text medium (such as email, chat and usenet). To obtain this goal I had
to add symmetric ciphers to actually encrypt the message, a hash function (which
is used in many places) and diffie-hellman key exchange. Nothing else was added
(such as swap file cleaning, file wiping) because they would not solve my
problem.
The author is claiming these features :
Diffie-Hellman Key Exchange
Secure method for people to share a private key remotely.
Simple to use.
Uses a 2048 bit strong prime as the modulus
*** Group Shared keys planned for V2.0 ***
Seven Symmetric Ciphers
Allows you to use the symmetric cipher you feel most comfortable with.
Includes: Cast, Blowfish, RC4, RC5, RC6, Twofish and Rijndael.
160 bit symmetric keys. Each message uses a independent symmetric key which is
the hash of the shared key and a 128 bit random SALT.
File Encryption
Simple to use file encryption routines.
Compact
The executable is only about 50 kb. The size is growing slowly as new features
are added, although right now it's quite comparable to the popular cryptosystems
[only 75 times smaller].
Any input will be appreciated.
--
Thanks, Richard
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 11:36:08 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
> > [EMAIL PROTECTED] (Johnny Bravo) wrote:
> > > The burden of proof is on the claimant. If has a point to make,
> > > it is up to him to prove he is right, it is not up to us to prove
> > > him wrong.
> > Well, you might be well liked in a class on legalities, but, ...
>
> Johnny Bravo is right and you are wrong. If scientists had to take
> seriously every crackpot claim, they'd never have time to make any
> real progress. It is a simple matter of practicality that the
> proponent of a new idea that challenges established knowledge needs
> to make a *convincing* case for his idea, so that at least some
> scientists will be motivated to look into it.
There are so many cases of everybody being wrong when someone else is
right. You honestly cannot reject a single detractor on sight. I assure
you that I want to see evidence of his claims if possible, or define them
at least worth more study. The last thing I am going to do is reject
claims if there is reason to believe that they might be true. Being open
to such things may seem a burden, but it is a requirement nonetheless.
Personaly, I have a few rather unpopular ideas myself, backed up by my
experience; if they prove accurate according to additional data, mine or
others, I surely will mention them again. When working on the idea of
strength, a don't-touch subject in the minds of many, surely there are
lots of Pandora's boxes to be appraised; fear of what I will find is not
my guide, just see what is there.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 02 Dec 1999 11:54:43 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
Bravo) wrote:
> If they really care they have plenty of other means to get your key.
> After all, how many of us are using TEMPST shielded computer equipment
> at home, regularly inspect both hardware and software for tampering,
> and sweep the room with the computer in it for monitoring devices.
>
Look at the activities of high-tech thieves. If security is so important,
then the ability of government to use obscure methods should be a warning
that dedicated others could do the same things. As always, identifying
the easy mark is the best preliminary step for a criminal to take before
the crime. Most users are not worthy targets, but who is to tell that
they might not be scammed or skimmed by specialists.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Thu, 02 Dec 1999 11:46:10 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Say you're compiling a dictionary of blocks, which matches blocks to
> corresponding plaintexts. Say you have a target of getting 1/8 of the
> blocks. This lets you take vague guesses at the contents of the message,
> pretty much regardless of the block size.
>
A single letter or word might make all the difference sometimes. Try this
exercise, take a book of at least 100 pages and gived several people a
minute to scan through it. Have each one write a page on what it was
about, plot, if there was one. Then, compare the results. I *guess* is
that they will be so varied as to cause argument in the group; yep, pretty
vague.
At least you are getting beyond a single block here in a definition of strength.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: sci.math
Subject: Re: Why Aren't Virtual Dice Adequate?
Date: 02 Dec 1999 09:46:40 PST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
>
>In sci.crypt Michael Kagalenko <[EMAIL PROTECTED]> wrote:
>: Tim Tyler ([EMAIL PROTECTED]) wrote
>
>: ]What do you make of Terry Ritter's thoughts on the unattainability of
>: ]demonstrably secure OTPs in practice?
>
>: Terry Ritter is illiterate in math statistics, so his opinion counts
>: for very little.
>
>Perhaps you can offer some criticism of the views in question, rather than
>attempting to cast aspersions on their author?
>
>I case you are not even familair with the views under discussion, you can
>find them at:
>
>http://www.io.com/~ritter/GLOSSARY.HTM#OneTimePad
>
>... and in the links at the bottom of ...
>
>http://www.io.com/~ritter/GLOSSARY.HTM#ReallyRandom
Good info! I have a clueless newbie question about something that
I found while reading the above:
| "Nor does even a theoretical one time pad imply unconditional security:
| Consider A sending the same message to B and C, using, of course, two
| different pads. Now, suppose the Opponents can acquire plaintext from
| B and intercept the ciphertext to C. If the system is using the usual
| additive combiner, the Opponents can reconstruct the pad between A
| and C. Now they can send C any message they want, and encipher it
| under the correct pad. And C will never question such a message,
| since everyone knows that a one time pad provides "absolute" security
| as long as the pad is kept secure. Note that both A and C have done
| this, and they are the only ones who had that pad."
It seems that the attacker needs to also have to know that A sent
the same message to B and C. Knowing B's plaintext and knowing
that B and C got the same message resolves to knowing C's plaintext.
I see no way that a man in the middle attacker can know whether or
not A sent the same message to B and C. I suppose that he could
try assuming that the message was the same and inserting a message
to C that would provoke a detectable reaction that a random garbage
would not. This also tells me that A shouldn't send encoded messages
that are the same length as the plaintext. Am I missing something?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 12:04:25 -0600
In article <[EMAIL PROTECTED]>, Markus Peuhkuri
<[EMAIL PROTECTED]> wrote:
> w> Pick a block length, pick a usable keylength, design a good
> w> algorithm, case closed.
>
> As I're read enough about poor implementations, I would not
> risk spending two years of my life in restricted freedom.
> I would like to make sure.
Studying poor implementations is essential to knowing who to avooid their
weaknesses. Aside from that, rewarded efforts to punish or prohibit good
crypto would make the actual process of good encryption more detrimental
to you than the nature of the information that might be protected. If you
bite the bullet, don't crunch down on the cap.
--
Love is blind, or at least figure that it has astigmatism.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Use of two separate 40 bit >> tony >> Where you posting from ? [
Date: Thu, 02 Dec 1999 12:54:23 -0500
When you think that way, you will have what you think should have.
The americans are not providing any restrictions on you. You are creating
restrictions for yourself.
It's getting more clear by statements such as from tony, that only people who
can think are americans [ almost ] !!!
Where you posting from ? [ just curiosity ]
--
Thanks, Richard
=====================================================
"tony.pattison" wrote:
>
> as I do not live in the land of the free, I'm not permitted to have
> more than 40 bit DES
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: Thu, 02 Dec 1999 11:52:05 -0600
David A Molnar wrote:
>
> I guess a next question ask is whether analagous attacks exist
> for "elliptic curve cryptography", or more generally whether "elliptic
> curve cryptography" is suspectible to things like chosen-ciphertext
> attacks. unfortunately this is nonsense without specifying the exact
> scheme which uses elliptic curves first.
If the protocol can be specified independently of the group structure
or type, then the question needs to be asked in terms of the protocol
security, not in terms of the underlying math.
> Are there "elliptic curve" systems for which chosen-ciphertext attacks
> are known ? (or chosen-message attacks?) I'm sorry if this is a stupid
> question; I should know more about EC. In particular, if it doesn't make
> sense to ask about EC schemes distinctly, because I can just "drop in" EC
> mult for modular mult, that'd be neat to know.
You can usually just drop in EC mult for modular exponentiation.
EC addition is a drop in for modular mult. Usually :-)
> Is there anything like Dan Boneh's "Twenty Years of Attacks on RSA"
> available for elliptic curve crypto yet ?
Not a summary yet, but in the past 15 years there have been many
suggestions which have bit the dust. To summarize: use non-singular
randomly chosen curves!
> In any case, it seems that trying to compare cryptosystems (by which I
> mean the primitive, the padding scheme, and maybe the protocol) by what
> assumptions they require becomes very murky very quickly. At the same
> time, it's as least as important to consider as questions of key length.
If it's possible, the protocol should be analyzed independently of the
math it rides on. Then similar protocols can be compared which use
different math. For example, there's an ElGamal analog for ECC. Compare
the shorter key length and time to compute with the ElGamal modular
exponentiation scheme. That's a reasonable comparison (I think).
Patience, persistence, truth,
Dr. mike
------------------------------
From: Vasudev Pai <[EMAIL PROTECTED]>
Subject: Please Check my understanding of Montgomery Algorithm
Date: Thu, 02 Dec 1999 23:31:43 +0530
==============C26BEC06269930594E3F73C0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please read through what is currently my understanding of
Montgomery algorithm
for modular multiplication. Please correct me wherever I am
wrong. I am an undergraduate student.
Also tell me if I have missed anything subtle or there is
some redundancy in the algorithm.
We represent integers x = 0,1,...,N-1 in Montgomery domain as
M(x) = xR mod N where --- (1)
R > N, R relatively prime to N, R is a power of 2. R =
2^n
Now my doubt is : Doesn't computing (1) ON HARDWARE take a
lot of time?
A divison(subtraction approximately x times needs to be done) is
required
to get the least residue on the "N hour clock".
Now please verify the correctness of the algorithm.
function Mont(x) /// x is in Montgomery form not the
integer form.
m = ( x mod R ) * N" mod R ---(2) ===> How time
consuming is this multiplication?
t = (x + m*N ) / R ===>
How time consuming is this multiplication?
if t < N
Return t
else return N -t
end Mont
and N" is found such that 0 < N" < R and RR" - NN" = 1
where R" is the inverse of R under multiplication mod N.
for example 3 is the inverse of 17(17 == 7 mod 10 ) under
multiplication mod 10.
== denotes congruency, 7 being the least of 17 residue for
mod 10.
Also the output (t or N - t) is an INTEGER not the
Montgomery representation.
So this function helps in getting back the integer
representation of a Montgomery number x. ===> Use no. 1 of
Mont(x)
So for computing x^y mod N we pass (xR mod N )*(xR mod N
) as argument
for Mont(x).
we get x^2 in MONTGOMERY representation (that is we get x^2
mod N not x^2.) ===> Use no. 2 of Mont(x)
Then pass (x^2R mod N)*(xR mod N) get x^3 and so on .....
My understanding is (xR mod N )*(xR mod N ) is an ORDINARY
product. Is finding, this product, time consuming?
So we need to go through ONE conversion to Montgomery
representation and ONE conversion back to integer representation
when computing x^y mod N.
In between the power of Montgomery's algorithm shrinks the
computing time compared to a straight computation.
I am going to implement this on an FPGA I can go for a 16
bit prototype .
If a chip were made with the fastest cell libraries,
pipelining, Wallace tree multipliers, for a 1024 bit long key
what could be the peak frequency of this chip?
Kindly cc your response to: [EMAIL PROTECTED] before 14 December
1999.
[EMAIL PROTECTED]
between 15 December 1999 to 14 January 2000.
[EMAIL PROTECTED] after 15 January 2000.
Thanks & Regards,
Pai
==============C26BEC06269930594E3F73C0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Please read through what is currently
my understanding of Montgomery algorithm
<br>for modular multiplication. Please correct
me wherever I am wrong. I am
an undergraduate student.
<br>Also tell me if I have missed
anything subtle or there is some redundancy
in the algorithm.
<p>We represent integers x = 0,1,...,N-1 in
Montgomery domain as
<p>M(x) = xR mod N where
--- (1)
<p>R > N, R relatively prime to N,
R is a power of 2. R =
2^n
<p>Now my doubt is : Doesn't computing
(1) ON HARDWARE take a lot of
time?
<br>A divison(subtraction approximately x times
needs to be done) is required
<br>to get the least residue on the
"N hour clock".
<p>Now please verify the correctness of
the algorithm.
<p>function
Mont(x)
/// x is in Montgomery form not the
integer form.
<p> m = ( x mod R ) *
N" mod R ---(2) ===> How
time consuming is this multiplication?
<br> t = (x + m*N ) /
R
===> How time consuming is this multiplication?
<br>if t < N
<br> Return t
<br> else return N -t
<p>end Mont
<p>and N" is found such that 0 < N" < R
and RR" - NN" = 1
<br> where R" is the inverse of R under multiplication mod N.
<p>for example 3 is the inverse of
17(17 == 7 mod 10 ) under multiplication
mod 10.
<br>== denotes congruency, 7 being the least
of 17 residue for mod 10.
<p>Also the output (t or N - t)
is an INTEGER not the Montgomery
representation.
<br>So this function helps in getting
back the integer representation of a
Montgomery number x. ===> Use no. 1
of Mont(x)
<p>So for computing x^y mod N
we pass (xR mod N )*(xR mod N )
as argument
<br>for Mont(x).
<br>we get x^2 in MONTGOMERY representation
(that is we get x^2 mod N not
x^2.) ===> Use no. 2 of Mont(x)
<br>Then pass (x^2R mod N)*(xR mod
N) get x^3 and so on .....
<p>My understanding is (xR mod N )*(xR
mod N ) is an ORDINARY product. Is
finding, this product, time consuming?
<p>So we need to go through ONE
conversion to Montgomery representation and
ONE conversion back to integer representation
<br>when computing x^y mod N.
<br>In between the power of Montgomery's
algorithm shrinks the computing time compared
to a straight computation.
<br>
<p>I am going to implement this on
an FPGA I can go for a 16
bit prototype .
<br>If a chip were made with the
fastest cell libraries, pipelining, Wallace
tree multipliers, for a 1024 bit
long key
<br>what could be the peak frequency
of this chip?
<p>Kindly <b> cc</b> your response to:
[EMAIL PROTECTED]
before 14 December 1999.
<p>
[EMAIL PROTECTED] between 15 December 1999
to 14 January 2000.
<p>
[EMAIL PROTECTED] after 15 January
2000.
<br>
<p>Thanks & Regards,
<p>Pai
<br>
<br>
<br>
<br>
<br> </html>
==============C26BEC06269930594E3F73C0==
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Quantum Computers and PGP et al.
Date: Thu, 02 Dec 1999 18:35:10 GMT
Reply-To: Jim Dunnett
On Wed, 01 Dec 1999 12:43:14 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>Greg wrote:
>>
>> > Quantum computers, like nuclear fusion, language
>> > translation or artificial intelligence, may prove
>> > more difficult than originally anticipated.
>>
>> I agree. But the reason I steer clear of IFP is due
>> to the large amounts of effort by many different groups
>> to develop a Quantum computer. No such specific threat
>> exists for ECDLP. And I suspect it will remain this way
>> for quite some time.
>
>A quantum computer can be used to solve the DLP over any group.
>Once we get quantum computers to work, we'll have a whole new
>game to play with crypto. Nice to know the field will never
>get boring eh? :-)
>
>It will be at least 20 years before quantum computers become
>useful in the laboratory. And it might be like fusion, "it'll
>work in 40 years" has been the mantra for about 60 now. The
>difference is that the tools needed to work on quantum computers
>are much cheaper than the tools needed for fusion reactors.
>In any event, there's no public key crypto system in existence
>today that will be useful when quantum computers work.
>
Not even OTP?
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Subject: Re: Ultimate Crypto Protection?
Date: Thu, 02 Dec 1999 18:35:09 GMT
Reply-To: Jim Dunnett
On Tue, 30 Nov 1999 23:26:48 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>amadeus wrote:
>
>: Obviously if you can produce enough good random key, fine.
>: But it doesn't have to be high quality, just unknown to the
>: enemy and sufficiently random that he cannot predict what the
>: next key byte is going to be.
>
>It has to be *pretty* high quality. Deviations from complete randomness
>will allow attackers to extract *some* information - even if the
>entropy-per-bit of the stream is relatively high.
>
>*Statistical* knowledge of what the next key byte is going to be might
>help an attacker significantly.
Agreed. It needn't be perfect, just good enough to protect your data
from whatever threat you perceive.
'Perfect random' isn't really possible. Well it may be, but how could we
tell when we had acheived it? We can only use the imperfect tests that
are available and do the best we can.
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Thu, 02 Dec 1999 18:35:11 GMT
Reply-To: Jim Dunnett
On Wed, 01 Dec 1999 13:19:52 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>Bruce Schneier wrote:
>
>> This sounds like an audio summary of Seymour Hersh's excellent New
>> Yorker article on the same topic, which can be found at:
>>
>> http://cryptome.org/nsa-hersh.htm
>>
>> It's really interesting reading.
>
>I'll say! It makes it sound like the NSA is a bunch of incompetent
>morons. How much of that is disinformation?!?!
Perhaps that's what they want you to think?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Quantum Computers and Weather Forecasting
Date: Thu, 02 Dec 1999 18:48:01 GMT
Quantum computers potentially offer the possibility of performing a
computation in parallel for an enormous number of different
combinations of input parameters, and then producing a result for only
one such combination if that combination produces a result that meets
certain criteria.
This may be useful to extend the range and accuracy of weather
forecasting.
Although chaos theory sets an irreducible limit to the useful range of
advance forecasts of weather, based on the growth of random inputs
caused by nonlinearities in the system,
in practice, the limit imposed by the limitations in the precision and
detail of input data about the state of the weather at a given moment
impose a stricter limit.
It is theoretically possible to obtain information about the missing
components of the state of the Earth's atmosphere at a given time by
the following technique: for each possible set of values for the state
of the unobserved part of the Earth's atmosphere, run the equations
backwards to obtain a long-term "prediction" of the weather on
preceding days. That hypothetical state of the atmosphere which
produces the longest-term accurate forecast in the reverse direction
is the state most likely to be correct.
Quantum computers would seem to directly lend themselves to such a
computation, should they become practical. (However, the limit on
search algorithms may be fatal, as even the square root of the number
of possibilities here is prohibitively large.)
Perhaps there is a mathematical technique possible that avoids such
extravagance, by working with the state of the weather several days
ago, and incrementally updating missing parts of the atmospheric state
in response to forecast errors. The principle would be the same: to
use the depth of available atmospheric data in time to substitute for
the lack of detail in our knowledge of the state of the atmosphere at
any one moment.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Eric Pinnell)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Thu, 02 Dec 1999 18:57:29 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 01 Dec 1999 19:54:36 +0100, Helmut Wabnig <[EMAIL PROTECTED]>
wrote:
>
>Even if the Algorithms are known, how much effort would it take
>to decrypt a transmission "on the fly".
>Think this is rather impossible, I cannot imagine a way to do it.
>Say, we could work on a recorded transmission, which in fact
>is also difficult to make, how long will it take to bring up a result?
This is easy. Simply feed all the digital information into a FIFO
buffer. Suppose it takes your computer five seconds to start the
decryption process. Simply buffer those five seconds beforehand.
If you've got a massively parallel system like NSA has, it would be
easy to decrypt in real time.
>GSM transmissions of a certain GSM unit cannot be easily
>filtered out of all the traffic on certain base station.
All you need to do is know who you want to listen to, and you can
monitor their transmissions and will. Even if they've got frequency
hopping, the techincal means exist to read the traffic.
>
>Only the net providers can access individual beares,
>or can disable encryption without notice.
Or government agencies who know how the equipment works. Or who
have tapepd into the communications network without the provider
knowing.
Eric Pinnell
Qui Desiderat Pacem, Praeparet Bellum
(Let Him Who Desire Peace, Prepare For War)
Flavius Vegetius Renatus - 3rd Century BC
------------------------------
** 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
******************************
