Cryptography-Digest Digest #396, Volume #11 Thu, 23 Mar 00 02:13:01 EST
Contents:
Re: More weapons for Mallory against Quantum Encryption ([EMAIL PROTECTED])
Re: Card shuffling (Johnny Bravo)
Re: 2048 Bit Encryption? (Anthony Stephen Szopa)
Re: Hashes! (newbie question) (Scott Nelson)
Secret Key (En|De)cryption functions ("David L. Nicol")
Re: Opinions? (Johnny Bravo)
Re: 2048 Bit Encryption? (Anthony Stephen Szopa)
Re: Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: NIST publishes AES3 papers (David A. Wagner)
Re: pgp key collision ([EMAIL PROTECTED])
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: More weapons for Mallory against Quantum Encryption
Date: Thu, 23 Mar 2000 05:20:02 GMT
In article <8bbi1f$vb8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > > know 75% of the bits!! (25% in the man-in-the-middle, 50% in the
> > > checking)
> >
> > All bits are attempted to be checked. Since they are individual
> > photons,
> > you can't always get one.
>
> Which bits are attempted to be checked in your example?
> How I would check them?
>
Based on measured error rates, strict upper
bounds can be set on the possible amount of
info known to an eavesdropper. Methods can be
used to reduce this info to an acceptable level
and then the presence of an eavesdropper can
be checked according to, for example, Bell's
theorem (or EPR correlation). Eavesdropping
cannot necessarily be prevented in the first
place but it will be detected. A non-technical
intro to this can be found at:
http://www.qubit.org/intros/crypt.html
Regarding the MITM attack, the attacker
cannot pose as Alice or Bob in the previously
mentioned Zeng-Guo quantum authentication
protocol. This is because the authentication
key is secure as it is obtained from the
quantum key distribution (QKD) which is
provably secure. Also, the authentication key
is used only once so the attacker has no info
about it. This is different than the Mitra
protocol.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Thu, 23 Mar 2000 01:07:13 -0500
On Thu, 23 Mar 2000 03:30:29 GMT, DMc <[EMAIL PROTECTED]> wrote:
>On Wed, 22 Mar 2000 23:38:26 GMT, [EMAIL PROTECTED] (Scott Nelson)
>wrote:
>
>>Randomness is a negative property.
>
>I have no idea what you mean. Negative property?
In general you can prove the positive property, ie the deck is ordered.
Much harder to prove a lack of order unless you know every possible method
to put the deck into order and can show that none of those methods could
produce the current deck condition.
To use a clearer example: It is easy to prove that something can fly if
you see it in flight, it is impossible to prove that something can't just
because you see it not flying. If it is not flying now doesn't mean that
it never can. The burden of proof is usually on the positive position.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Wed, 22 Mar 2000 22:11:47 -0800
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > Even with the NSA's new holographic computer technology?
> > >
> > > see -> http://www1.ekstrabladet.dk/VisArtikel.iasp?PageID=43390
> > >
> > > On Tue, 21 Mar 2000 21:41:55 -0800, Anthony Stephen Szopa
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > >[EMAIL PROTECTED] wrote:
> > > >>
> > > >> Can the NSA break a 2048 bit encrypted email message? If they can,
> > > >> is there anything out there that they can't break?
> > > >
> > > >I don't think they can break OAP-L3
> > > >
> > > >http://www.ciphile.com
> >
> > Let's start to address this point by asking this question:
> >
> > What is your wildest upper estimate as to how fast such a computer
> > might be?
> >
> > Can it perform, maybe, 1E12 operations per second? Perhaps 1E24
> > operations per second? How about 1E100 operations per second?
> > Even 1E1000 operations per second?
> >
> > Even if this holographic computer can perform at 1E1000 operations
> > per second (or faster), it will still be ineffective in cracking
> > messages encrypted with OAP-L3 if the key were simply made long
> > enough. And this key would not be difficult to process by a user
> > of OAP-L3.
> >
> > OAP-L3 is not susceptible to factoring attacks.
>
> Nor is any other stream cypher (the family of cyphers that OAP-L3 fals
> into). OAP-L3 has never been subject to any formal reviewal process, and its
> algorithim has not been subjected to a public examination to determine its
> quality. There are many other stream cyphers of which this is true.
>
> > If you want to
> > crack OAP-L3 encrypted messages you must guess a key, process
> > it to generate OTPs, then attempt to decrypt the message using
> > these OTPs.
>
> > This is quite a computationally intensive process
> > for each and every possible key.
>
> Assuming you are attacking OAP-L3 by brute force, as opposed to a more
> rational attack such as cryptoanalisys. Calling the bitstream it generates
> an "OTP" is a misnomer. A stream cypher may have an exceptionally long
> period, but it can and does repeat, and even if it does not have repeating
> values there will be characteristics of the stream that prevent it from
> generating truly random data( an absolute necessity in an OTP -- calling a
> stream cypher an OTP is like calling a rusted out chevy with no wheels up on
> blocks with a cracked engine block and no seats a car -- they are related
> entities, and may look similar to the untrained eye, but one does the job,
> and the other does not. )
>
> >
> >
> > If the OAP-L3 key length provides a security level of 1E100000
>
> 1E100000 what? bits? possible keys?
>
> > and
> > this holographic computer can perform 1E1000 operations per second
> > then at a minimum it would take 1E99000 seconds to just generate all
> > possible keys (not to mention all the time it would also take to
> > generate the OTPs from each of these keys, etc.)
>
> Anyone worth their salt won't generate all keys, they will attack the
> algorithim. In addition just because there are X many possible keys doesn't
> mean that the algorithim used in key generation will select randomly from
> that space -- attacks based on the fact that most people want a
> password\phrase that is shorter than the Declaration of Independence will
> limit that to a much smaller amount in practice, and that is assuming that
> such a phrase is of good quality.
>
> >
> >
> > If you are a US or Canadian citizen currently residing in the US or
> > Canada and your ISP is physically located in the US or Canada, you can
> > get the OAP-L3 Shareware Version 4.1 via email. Go to
> > http://www.ciphile.com and go to the Pricing and Ordering web page.
> > Click on the blue underlined "email" anchor tag in the third paragraph.
> > Send us this email.
> >
> > Or you can go to the web site and directly download the OAR-L3 random
> > number generation software directly.
"formal reviewal process": The theory and the software are related
yet can be viewed as distinct for analysis. I think the theory is
certainly the place to start. The theory is explained in the
"Theory", "Processes 1", and Processes 2" Help Files. It is quite
simple. And it is a short read: perhaps about 3 legal size pages.
Hopefully we will hear some definitive statement about the theory
from our more learned posters.
The software is available as stated numerous times at
http://www.ciphile.com
Contrary to conventional wisdom, I think the software can be
evaluated without the source code. Get the software and read how
you can do this. The software is simply a collection of very very
simple processes that when chained according to instructions will
produce random digits / random numbers.
I must say I am surprised that some suggest that these simple
processes may work every time with test data yet when you
really need cryptologically useful numbers, the software
will somehow know and then slip in a back door or otherwise
present a hidden security risk. This is like saying that
all the financial and engineering computations done on all the
computers in the world are unreliable because we do not have the
source code. These operations are as simple as addition and
subtraction. If the implementation is defective you will see
it. (This is not much of a simplification. See for yourself.)
""OTP" is a misnomer" Then why doesn't the Patent Office agree
with the purists? Look up their definition.
1E100000 refers to possible keys.
"they will attack the algorithm." Of course they will attack the
algorithm first if the theory proves difficult and just as a matter
of course. Remember that the theory and the algorithm are two
distinct issues.
"the algorithm used in key generation will select randomly from
that space" The algorithm does not select the random numbers.
Every process requires random user input. This input is the key.
The user picks the order of the processes. The user enters usually
10 or 14 different numbers for each process. The user inputs how
many times each process is run with different input. Etc.
A user should only be concerned about how they themselves use the
software. The recommended usage is quite explicit. If someone
wants to live recklessly or with high risk and high anxiety then
it is their problem.
Certainly you should be concerned with who you communicate with in
general when you exchange encrypted communications. But this is
true with any communication whether verbal, written, signed,
emailed, encrypted, etc.
I may be signing off this thread at any time now. Please, get the
software and just read the "Theory" Help file. Hopefully you will
read the Processes 1 and Processes 2 Help files as well.
The rest is up to you. Most all of your questions will be answered
if you read the Help Files. This is my recommendation: read the
Help files and best of all evaluate the software.
AS
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Hashes! (newbie question)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 23 Mar 2000 06:24:21 GMT
On Wed, 22 Mar "Simon Johnson" <[EMAIL PROTECTED]> wrote:
>Could you use a PRNG for creating a hashing algorithm?
It's /possible/
>If the period of the PRNG was greater than 160-bits ( the length of the
>digest i wish to generate ) then it should be just as secure as MD5 or
>SHA-1, shouldn't it?
>
No.
Security is like a chain -
it's only as strong as it's weakest link.
Number of bits is just one link in that chain.
Another link is complexity. In simple terms,
if it's possible to write out a single logical expression
that describes the function, then it can be broken.
Most PRNG's can be written as straight line code with
no forward referenced assignments (no loops,
and no variables used after being set)
and so they can be cracked with algebra.
Complexity isn't generally the weakest link,
but it's important to understand why it's a weak link,
and what the implications of that are
before trying to tackle other potential problems.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "David L. Nicol" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.moderated
Subject: Secret Key (En|De)cryption functions
Date: Wed, 22 Mar 2000 21:07:56 +0000
Vito Prosciutto wrote:
> I want to be able to encrypt [a perl scalar] in such a way that a
> hacker with access to the database
> and the code that does the encryption on machine A is not able to
> decrypt credit card numbers.
Here you go. To pull the plaintext out of this you need access to
the database, the code, AND THE SECRET KEY. Because the plaintext
is used in the encryption of subsequent plaintext, and the random
nature of your plaintext, the me
Here's a quick, secret-key encryption method which might
work for you. The key is kept in an internal file called .SecretKeyVP
which is identical on both machines, and ideally is stored somewhere
so that a casual wget -r of your cgi-bin directory won't suck
it in. Check with the admin of your virtual server to adjust the
permissions so only the cgi-running user can see the file. Or even
so that only the cgi-running user can run the program -- "cat" in
backquotes below -- which would be setuid to another user who is the
only one who can read the secret key. This stuff isn't bulletproof,
just makes it trickier.
Stick the following in a file called "CryptLib.pl" and pull
it into your program with C<require "CryptLib.pl"> for secret
transmission and storage of arbitrary perl scalars.
Uncomment print statements to see the algo in action. I tested it
with this command line invocation:
perl -le 'require "cryptlib"; print decrypt(encrypt("test data"))'
@SecretKey = split //, `cat /etc/secretstuff/.SecretKey`
or die "Secret Key file empty or missing -- Eeek!";
sub encrypt($){
my $Current = 0;
my @Result=();
my $SecretIndex = -1;
foreach my $plainchar (split //,$_[0]){
defined $SecretKey[++$SecretIndex]
or $SecretIndex = 0;
# print "enc $plainchar with $SecretKey[$SecretIndex], $Current\n";
push @Result, chr(
(
ord($plainchar) +
$Current +
ord($SecretKey[$SecretIndex])
) % 256
);
$Current = ord($plainchar);
};
# print (pack "u*", join('',@Result)),"\n";
pack "u*", join('',@Result);
};
sub decrypt($){
my @Result = ();
my $Current = 0;
my $clear;
my $SecretIndex = -1;
foreach $cryptchar (split //,unpack("u*",$_[0])){
defined $SecretKey[++$SecretIndex]
or $SecretIndex = 0;
$clear=chr($Current =
(
ord($cryptchar) -
ord($SecretKey[$SecretIndex]) -
$Current
) % 256
);
push @Result, $clear;
# print "decr $clear from $SecretKey[$SecretIndex], $Current\n";
}
join '', @Result;
};
1;
__END__
The above code is copyright 1979, 2000 David Nicol, and is hereby
released for general use. (i originally wrote it in Fortran on Indiana
State University's CDC Cyber.) Please license your copy by referring
to www.davidnicol.com in your comments. Under no conditions will
salesmen call.
Anyone want to rewrite the above using C<map> instead of C<foreach>?
_________________________________________________________________________
David Nicol 816.235.1187
[EMAIL PROTECTED]
"Just call out ATDM when you see that ICBM and the party will become
SUR"
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Opinions?
Date: Thu, 23 Mar 2000 01:21:02 -0500
On Wed, 22 Mar 2000 17:09:52 GMT, [EMAIL PROTECTED] wrote:
>
>
>>
>> Radioactive decay has been proven to be random, there are no hidden
>> variables that tell particles when to decay.
>
>At least from a standpoint of nowaday's science, it is absolutely
>impossible to positively prove (i.e. verify) that something is pure
>random.
The time it takes an atom to decay has been proven to be random, there
is no way to tell in advance when an atom will decay naturally, if it ever
does. The best we can do is assign a probability to the chances of an
atom decaying after a certain amount of time based on observation. As for
using this information to create a sequence that is proven to be random is
another thing altogether.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Wed, 22 Mar 2000 22:28:24 -0800
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >OAP-L3 is not susceptible to factoring attacks. If you want to
> >crack OAP-L3 encrypted messages you must guess a key, process
> >it to generate OTPs, then attempt to decrypt the message using
> >these OTPs. This is quite a computationally intensive process
> >for each and every possible key.
>
> This paragraph would make sense if there were just two types of attacks
> against cryptosystems: brute force and factoring. However, there are
> others, and your conclusion is unwarranted.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQB1AwUBONkibQUw3ir1nvhZAQEnzQMAslEaChGz3rpCAAI3S+9A2AR1oK59qHkt
> yJjg6j4ZoZp1tN0cfdOr7WfXxeF+sGo0o1DNUe5kZOvi5dWpeZGd9vze/lYg+yhq
> 6C0PEmiRuxtujtHY2kaxGarVfKjGwlHa
> =8R5N
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
Knowing the Theory and Processes, can you suggest some possible
attacks. With knowledge of the theory and processes you may
be able to find some and tell us why they should be pursued. But
there is a possibility that knowledge of the theory and processes,
being so simple, that all other theoretical attacks can be logically
eliminated. Of course if this conclusion is reached then an attack
on the algorithm would immediately follow.
This is probably how such a decision would be made.
Of course I understand you may not be knowledgeable enough to make
this determination. But I think this is how the process would
begin.
Perhaps someone would like to let us know what their conclusions
are regarding possible attacks with knowledge of the theory and
processes?
AS
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Wed, 22 Mar 2000 22:40:18 -0800
Joseph Ashwood wrote:
>
> > 1) We should make a distinction between the random number
> > generation software that can produce practicably unlimited
> unique
> > sequences of random numbers between 0 - 255 and random
> digit
> > sequences, from the random digit generator. The random
> digit
> > generator generates the random digit sequences that can be
> > themselves input, or are used to create random triplet
> sequences for
> > input, for further extensive processing.
> >
> > The final random digit sequences or random number
> sequences are
> > created by further extensive processing of these original
> sequences
> > using as many as ten different methods. The result is a
> practicably
> > unlimited supply of unique random digit / unique random
> number
> > sequences.
> >
>
> 1) We should make a distinction between something that is
> fully explained, and whatever it is that you have
>
> 2) We should make a distinction between something written by
> someone with a good reputation, and something written by the
> rest of us
>
> 3) We should make a distinction between something usable for
> cryptography, and something whose stream is simply
> convoluted.
>
> 4) We should make a distinction between a random number
> generator that has established that it is good, and
> something which you haven't even fully defined.
>
> 5) We should make a distinction between random numbers, and
> random sequences
>
> 6) We should make a distinction between something that
> creates something that is a random string, and something
> that creates a random ordering of a fixed string
>
> > 2) There is a case made for the suitability of the random
> number
> > generation process for cryptological purposes in the
> Theory,
> > Processes 1, and Processes 2 Help files. Let us know if
> you can
> > find any holes in the logic of this case, or the reasons
> why you
> > are still not convinced.
>
> 1) Your help files far from completely describe your
> methods.
>
> 2) Without a complete description it can't be fully analyzed
>
> > 3) OAR-L3T: ORIGINAL ABSOLUTELY RANDOM - LEVEL3 Version
> 4.1
> > random number generation software is exactly the same
> software as
> > OAP-L3: Original Absolute Privacy - Level3 encryption
> software
> > except there is absolutely NO encryption or decryption
> capability.
> >
> > Not only have the encryption and decryption GUI forms,
> menus,
> > buttons, etc. been deleted, but also, the encryption and
> decryption
> > source code has been deleted, then the entire package
> recompiled.
> > So there is no way to enable any encryption or decryption
> methods or
> > capabilities using OAR-L3.
>
> 1) if you give me a (assumed) random number I can easily use
> it for cryptographic purposes
>
> 2) if that's the best you can do, then I'd recommend reading
> the Yarrow paper on http://www.counterpane.com
>
> 3) Just because you use it for crypto doesn't mean that it
> is well suited for strong crypto, you haven't demonstrated
> that your methodology is sound.
>
> > 4) My intention for making OAR-L3 random number
> generation software
> > available is to generate random digits or numbers for
> statistical
> > modeling and computer simulations.
>
> If it is designed for use for statistical modeling and
> simulations, then it is unlikely to be suitable for
> cryptography
>
> > Perhaps someone else may have some other purpose in mind
> such as
> > using it to pick their lucky lotto numbers.
>
> Sorry, unlike some people I'm good enough at math to know
> that it's pointless
>
> > I can assure you that I am the last person who wants to
> make the
> > encryption software police feel they are sorely running
> around with
> > their thumb up their ass.
>
> I assure that that you are one of the people that make them
> giggle.
>
> >
> > If you are still puzzled perhaps someone else in this news
> group can
> > help you out.
>
> We have often said the same about you. I'm sorry if this
> upsets you, but I have responded several times and you still
> don't seem to be doing much in the correct direction.
> Joe
Mr. Huuskonen seems to have a good grasp of the theory and processes
(probably after just one cursory read.)
So do many others who have paid for the latest version of the
software.
And I have not heard any substantive or otherwise negative criticism
from the many many others who have gotten their evaluation copy.
I have sympathy for your difficulties.
I encourage you to keep trying.
AS
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST publishes AES3 papers
Date: 22 Mar 2000 22:14:26 -0800
In article <[EMAIL PROTECTED]>,
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
> "Resolved, that if NIST selects multiple cipher "winners" then the candidate
>with the largest margin of strength should be one of them even if it is not close to
>_optimal_".
You mean, Triple-DES?
(It's hard to imagine how any of the AES candidates
can be considered to have a larger margin of strength than
Triple-DES, at least if one considers assurance of security
today and amount of analysis done to date.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: pgp key collision
Date: Thu, 23 Mar 2000 06:56:57 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Lutz Donnerhacke wrote:
> >... And last I heard, SHA-1
> >fingerprints couldn't be fooled in reasonable time, that's
> >after all what it means to be a cryptographic hash function.
>
> I can do it. The output demonstrated it. No, it's not a fake:
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: 2.6.3in
>
> mQEQAzaekxACzAEIAKCMRhza5p7f9eCzOCbeog9mmct7qJweWG5ICJK8SyPNcg1d
> IDbcWOGKJGgmmhLGalPO3pYHDTmIf6g6j5NZuQ0YcKISEZPQ1IzmKC3N2sYRDbk7
> R7NfKMyqGSGqoLj1hfyacBvZ3voI1lJWjvJ3xpkkcvtTOr00QE6gTX5SJpxnX3Z4
> 4P7D8dKwU0RqlvVde/u0AZaUjw2AoQ89l/0I0Bkg9IrwwjLs42sgOA5frpmkKrCp
> xmYEiQgAVlid39q7dCQP+dUs5YkQRoz/m6pL0SGrEYoeO44kMG2Jz7a1uFoKGsZr
> +OQFE2JvFGQwWFooeV9ivFYEHp3WaJbuyhmZAQEAHisIQXe0U1Jvb3QgQ0EgZGVz
> IEluZGl2aWR1YWwgTmV0d29yayBlLlYuIDxpbi1jYUBpbmRpdmlkdWFsLm5ldD4g
> KFNJR04gRVhQSVJFOjIwMDAtMTItMzEp
> =U7OE
> -----END PGP PUBLIC KEY BLOCK-----
strange.. this key can not be imported into
pgp 6.5.3 but works with 2.6.3
anyway, you need to fool whole fingerprint, not just begining, can you ?
- --
Disastry http://i.am/disastry/
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
Comment: get this Plugin at http://disastry.dhs.org/pgp.htm
iQA/AwUBONmkEzBaTVEuJQxkEQIS/gCg946lwy+XZ8UpQeCwgd+tAjQ6IIEAnAsK
uFeCzt8+x5maDsmvargQ4fhE
=z9qK
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 22 Mar 2000 22:27:06 -0800
It looks like I'd better set the record straight.
The following paper cryptanalyzes iaPCBC mode:
Niels Ferguson, Doug Whiting, John Kelsey, David Wagner,
``Critical Weaknesses of iaPCBC''
Please note that this is joint work (NOT just my work;
nor am I even first author). Credit where credit is due,
please.
The above paper presents several observations on iaPCBC,
but the most devastating one is that flipping a single
bit in the ciphertext will not be detected, guaranteed.
(so long as the bit you flip is not too close to the
end of the ciphertext)
Thus, iaPCBC is indeed subject to (existential) forgery
attacks.
------------------------------
** 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
******************************
