Cryptography-Digest Digest #965, Volume #11 Tue, 6 Jun 00 22:13:00 EDT
Contents:
Re: XTR independent benchmarks (Roger Schlafly)
Re: XTR independent benchmarks (Wei Dai)
Re: Some citations (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some citations (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some dumb questions - Two Time Pad (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: Some dumb questions (Mok-Kong Shen)
Re: PSS and PSSR patent status (was Re: XTR) (Ulf M�ller)
Re: Question about recommended keysizes (768 bit RSA) ([EMAIL PROTECTED])
I have worked on this a lot ... actually it continues in the future .. I talked
about these issues with one telecom policy lobby group and its member today ...
(Markku J. Saarelainen)
Re: PSS and PSSR patent status (was Re: XTR) (=?iso-8859-1?Q?Ulf_M=F6ller?=)
XTR-DH key validation (Wei Dai)
----------------------------------------------------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: XTR independent benchmarks
Date: Tue, 06 Jun 2000 16:35:16 -0700
DJohn37050 wrote:
> NIST has issued a set of recommended curves, that about settles the issue for
> me,
And those curves are as large as 571 bits! (ie, log of field size)
> esp. considering the tremendous amount of structure needed in XTR to ensure
> that a field element is determined by only 2 subfield elements (key size),
> instead of 6.
The elliptic curves sure have a lot more structure than XTR.
XTR is just a subgroup of the multiplicative group of a field.
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: XTR independent benchmarks
Date: Tue, 6 Jun 2000 16:42:12 -0700
In article <[EMAIL PROTECTED]>, djohn37050
@aol.com says...
> WOW, solidity statements on ECC versus XTR.
>
> NIST has issued a set of recommended curves, that about settles the issue for
> me, esp. considering the tremendous amount of structure needed in XTR to ensure
> that a field element is determined by only 2 subfield elements (key size),
> instead of 6.
That structure is already present in GF(p^6) and is not imposed by XTR.
The reason it can represent a field element by only 2 subfield elements
is because it works in a multiplicative subgroup of size p^2-p+1, which
every GF(p^6) has. The question is whether discrete log in GF(p^6) is
really as difficult as in a prime field (when the two fields have about
the same order)? I think there is definitely room for doubt.
Another potential problem with XTR is parameter generation that ensures
p^2-p+1 has a prime factor of appropriate size, which could pick p's
that are too nice for DL. The paper gives two such methods and
explicitly says the first method may pick such p's. It's not entirely
clear to me that the second one doesn't.
--
cryptopp.com - Neutronium Solid (TM) :)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some citations
Date: Wed, 07 Jun 2000 03:17:56 +0200
Paul Koning wrote:
> Mok-Kong Shen wrote:
> >
> > I think that the following citations may be of some interest,
> > The Kerckhoffs principle is neither a correct description
> > of, nor a self-evident prescription for, all secrecy
> > design projects.
>
> So what principle would be substitute? Or would he just
> drop Kerckhoff's principle? If so I would ask "what possible
> good would that serve?"
The author of the article wrote some more about that. IF I understand
correctly, he meant that those organizations that have at their
disposal sufficient crypto expertise and resources could develop
their own security systems and kept these secret, while those who
can't afford to design their own stuffs have to rely on public
algorithms.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:18:06 +0200
Volker Hetzer wrote:
> Mok-Kong Shen wrote:
> >
> > Mark Wooding schrieb:
> [...]
> > Your argument is correct. But it lacks the desired 'concreteness' of
> > solution to my problem. Note that I can only assume the frequencies
> > of the characters in the language (at best that the frequency values
> > assumed are exact) but otherwise I have no additional informations
> > (digrams etc. are assumed to be largely destroyed through e.g. a
> > simple transposition). One has to show a 'concrete' way how to get
> > anything from the xor of the two messages.
>
> You are phrasing that like it's a study exercise...
>
> As to "concreteness", what exactly do you want?
I like instructions that are practical enough for doing the work of
analysis.
> Assume you've got two messages encrypted with the same keystream
> xored together in such a way that the key falls out.
> Then you go on by making (and testing) assumptions about the
> two messages.
> Like language (character distribution), format (header information)
> and so on. You compute the likelyhood of certain characters in the
> xor-stream and check.
> This increases your knowledge about the two messages, making it possible
> to make further assumtions (guessing words and so on).
If you have header informations, then you have 'some' knowledge
about the plaintext. I assume that this leakage of information can
be prevented by suitable means, e.g. thru transposition or some better
techniques.On the other hand, I assume that the opponent knows the
language of the plaintext and he has the frequency distribution of the
single characters but has no digram frequencies etc. My question is
then how to proceed precisely to do that step by step, i.e. I need
a functioning recipe.
> > Note also that, if the
> > OTP is used exactly twice, then (1) the xor of different pairs of
> > messages (each pair has the same OTP segment, but different pairs
> > have different segements) are essentailly unrelated to each other and
>
> > (2) if there is a number of messages intercepted, one has to correctly
> > pair the messages according to the OTP segment used (how is that
> > going to be done?).
> Just like the whole idea of re-using an OTP keystream, it relies on the
> stupidity of the people communicating. You test different variants
> of reuse.
I am afraid I don't quite understand what you mean by testing different
variants of reuse. Assuming that each segment is used twice, one has
to find from a large number of messages the corresponding messages
(in pairs) that use the same segments. It is not apparent how one is
going to do that.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some citations
Date: Wed, 07 Jun 2000 03:17:47 +0200
"Douglas A. Gwyn" wrote:
> Mok-Kong Shen wrote:
> > To paraphrase: (1) It doesn't matter if the ciphertext is
> > several times as long as the plaintext. (2) One can rely
> > on the secrecy (obscurity) of the encryption algorithm
> > as a factor contributing to the security of the system.
> > So far, there seems to be almost unanimous agreement on
> > these (though I didn't expect this).
>
> I don't know on what basis you judge that. Neither one is
> correct, according to my own observations.
If you think that the quotations are questionable, it would be fine
to have them discussed.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:19:39 +0200
Joaquim Southby wrote:
> This must assume that *something* is known about the plaintext. The
> actual plaintext may not be known, but there could be knowledge of
> headers, frequency of letter usage, etc.
>
> If there is absolutely no knowledge of what's in the plaintext message
> (this includes content, language, headers, footers, etc.), there is
> little chance this attack will be successful. The ultimate example would
> be if the OTP were used to encipher perfectly random numbers (an exercise
> in futility, to be sure). Removal of the key stream would reveal two
> sets of random numbers XOR'ed together -- not much to hang your hat on.
>
> That said, the "absolutely no knowledge" is a fairly big risk. How can
> one be assured the adversay has no knowledge of the plaintext? Ask them?
> (Oops!)
I do assume that the analyst knows the language and has the
frequency distribution of single letters. On the other hand, I assume
that through some appropriate techniques (transposition, etc.)
exploitation of digrams, trigrams, etc. as well as headers and the like
are not feasible.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:20:32 +0200
Jim Gillogly wrote:
> Mok-Kong Shen wrote:
> > 2. If an ideal OTP is misused, in that it is used a small
> > number n of times, how is one going to attack, if
> > absolutely no known plaintext is available?
>
> Going back to the original question (informed by a later message that
> assumes the underlying frequencies of the plaintext are known), I did
> a little example. I took the first n=10 sentences of Pride and Prejudice
> that are at least 15 characters long, and pulled out the 15th character
> of each, then XORed those characters with a randomly selected key. The
> ciphertext is: 0f 5a 1f 16 1f 1f 14 5a 1b 5a
>
> Now look at all possible values of the key. We know the underlying
> frequencies of the plaintext (English with spaces and other punctuation),
> so we can eliminate many of them. For example, decrypting that slice
> with 0x00 to 0x09 gives:
>
> 00: 0f Z 1f 16 1f 1f 14 Z 1b Z
> 01: 0e [ 1e 17 1e 1e 15 [ 1a [
> 02: 0d X 1d 14 1d 1d 16 X 19 X
> 03: 0c Y 1c 15 1c 1c 17 Y 18 Y
> 04: 0b ^ 1b 12 1b 1b 10 ^ 1f ^
> 05: 0a _ 1a 13 1a 1a 11 _ 1e _
> 06: 09 \ 19 10 19 19 12 \ 1d \
> 07: 08 ] 18 11 18 18 13 ] 1c ]
> 08: 07 R 17 1e 17 17 1c R 13 R
> 09: 06 S 16 1f 16 16 1d S 12 S
>
> In general we can ignore lines that include any unprintable character.
> Starting with 0x20 we get some of these:
>
> 20:/z?6??4z;z
> 21:.{>7>>5{:{
> 22:-x=4==6x9x
> 23:,y<5<<7y8y
> 24:+~;2;;0~?~
>
> and so on. These aren't likely for English -- they'll be mostly
> lower case and spaces, with few low-frequency characters. The
> most likely section appears to be in the 0x70's:
>
> 70: 7f *ofood*k*
> 71:~+ngnne+j+
> 72:}(mdmmf(i(
> 73:|)lellg)h)
> 74:{.kbkk`.o.
> 75:z/jcjja/n/
> 76:y,i`iib,m,
> 77:x-hahhc-l-
> 78:w"gnggl"c"
> 79:v#foffm#b#
> 7a:u eleen a
> 7b:t!dmddo!`!
> 7c:s&cjcch&g&
> 7d:r'bkbbi'f'
> 7e:q$ahaaj$e$
> 7f:p%`i``k%d%
>
> Of these, 0x7a is the obvious winner; and it still would be
> with fewer than 10 samples. With n large enough, the obvious
> winner would be correct in enough cases to allow the attacker
> to unwind a simple transposition layered under this.
Thanks for the valuable results of your investigation. With increasing
values of n, the position of the opponent will understandably be
increasingly better. So we seem to need to consider some better
techniques for combination with OTP. I admit I don't have a very
good idea at the moment. But perhaps doing in addition such stuffs
as polyalphabetic substitutions or random rotations of 32 bit words
would sufficiently pushed the level of complexity above the
threshold that the opponent can manage to overcome.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:19:48 +0200
Joaquim Southby wrote:
> One crib might be if the plaintext uses a standard header. Let's say the
> word "Attention" is the first word in every message. To pair one message
> with another using the same OTP segment, you could try XOR'ing your first
> intercepted message with all others. If you get zeroes where you expect
> the word "Attention" to appear, that means that the messages must have
> been enciphered with the same OTP segment. (This requires a lot of
> cooperation on the part of the sender, to be sure.)
I have put the answer to the above in the response to your other follow-up.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:19:55 +0200
Mike Rosing wrote:
> Mok-Kong Shen wrote:
> > Your argument is correct. But it lacks the desired 'concreteness' of
> > solution to my problem. Note that I can only assume the frequencies
> > of the characters in the language (at best that the frequency values
> > assumed are exact) but otherwise I have no additional informations
> > (digrams etc. are assumed to be largely destroyed through e.g. a
> > simple transposition). One has to show a 'concrete' way how to get
> > anything from the xor of the two messages. Note also that, if the
> > OTP is used exactly twice, then (1) the xor of different pairs of
> > messages (each pair has the same OTP segment, but different pairs
> > have different segements) are essentailly unrelated to each other and
> > (2) if there is a number of messages intercepted, one has to correctly
> > pair the messages according to the OTP segment used (how is that
> > going to be done?).
>
> By autocorrelation. You take all possible combinations of xor and
> offset
> and look for similar sequences. If the OTP is used more than 2 times,
> you have a very good chance of finding the same pad data, which means
> you
> can decode all n messages.
>
> Might take a while for long files, but for short messages and a modern
> computer, not more than a few seconds.
Perhaps we should indeed limit to consider the case where the
OTP is used only twice. I believe that's quite hard to crack, if
appropriate measures are taken to prevent exploitation of
headers in the messages etc.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions - Two Time Pad
Date: Wed, 07 Jun 2000 03:20:01 +0200
E-mail wrote:
[snip]
> Is this not the basis of your inquiry?
I guess that using OTP n=2 times could be made fairly safe under the
assumptions I made. For higher n, the security understandably will
be lower. We should preferrably discuss the case n=2 before
considering the more general cases.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:20:22 +0200
Jim Gillogly wrote:
> Mok-Kong Shen wrote:
> > 1. If a bit sequence has a certain known small bias in
> > frequency but is uncorrelated, how can one exploit
> > that fact to analyse messages encrypted with xor?
>
> One can get more or less confidence that a possible plaintext
> is associated with this particular ciphertext message, meaning
> that some semantic information is leaked (unlike the ideal OTP
> case) -- less information for smaller bias and shorter messages,
> but some information nevertheless.
>
> A few years ago an experiment was done in The Cryptogram (the
> American Cryptogram Association's magazine): plaintexts were
> encrypted with keys that were more and more random, and the
> members were challenged to try to recover plaintext. It didn't
> have to get too messy before I was unable to recover full
> plaintext, but I don't recall the final scores, if they were
> reported.
A bias is certainly something that is undesirable and to be avoided,
if at all possible. As you pointed out, it is difficult to exploit if it
is
small enough. I guess (I am not sure and may be wrong) that a bias
on the character level may be more critical than a comparable bias
on the bit level (i.e. we don't generate random character sequences
but random bit sequences in the first place, which is practical
nowadays with computers).
> > 2. If an ideal OTP is misused, in that it is used a small
> > number n of times, how is one going to attack, if
> > absolutely no known plaintext is available?
>
> Using assumed or guessed plaintext and crib-dragging. As n
> increases, it becomes progressively easier to pick out strings
> by eyeball. You might check further in the VENONA book you recently
> recommended for a proof of principle. I don't know whether the extra
> code step in VENONA makes it a more or less difficult first stage:
> sometimes encoding plaintext makes it apparently more redundant.
> Regardless, it was an impressive -- even Herculean -- feat, and the
> Arlington Hall cryppies have my deepest respect.
The code breaking section of that book is unfortunately very imprecise.
The book is in my opinion more for learning the whole history, not
for learning the cryptanalysis techniques of Venona at all.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Wed, 07 Jun 2000 03:20:12 +0200
Jim Gillogly wrote:
> Mok-Kong Shen wrote:
> > Your argument is correct. But it lacks the desired 'concreteness' of
> > solution to my problem. Note that I can only assume the frequencies
> > of the characters in the language (at best that the frequency values
> > assumed are exact) but otherwise I have no additional informations
> > (digrams etc. are assumed to be largely destroyed through e.g. a
> > simple transposition).
>
> This is not always a safe assumption -- at least not with a simple
> transposition. On a layered system of that sort one can often
> optimize the transposition and substitution simultaneously. With
> larger N (number of overlapped messages) it gets progressively
> easier. With a respectably large N you can get a good idea of the
> key at each point <without> unwinding the transposition just by
> picking the values of k[i] that minimize the number of low-frequency
> characters (or, alternatively, give you a best least-squares fit
> on the standard frequency of your target plaintext, or even (horrors)
> do the <right> statistical test on the distribution). Using these
> assumed keys sorted by goodness of fit, you can put together a
> string of potential (matched) plaintexts and <then> unwind the
> transposition using multiple anagramming, if it's a constant
> transposition.
>
> With N=2 I assume even a simple transposition would make it quite
> challenging. I'd need to see a demonstration that it affected
> national security or my wallet before trying it. I think I'd
> start by studying common n-grams of the target plaintext XORed
> with itself and using that to guide the transposition attack.
Thanks for some detailed explanations. I agree with you. To prevent
exploitation of n-grams and headers etc., I thought that simple
transposition could be sufficient. If that is not sufficient, we could
think about using some better techniques. Perhaps I should say
also that it is not my intention to actually propose to use OTP more
than once but rather to understand why (by error) using it twice could
be fatal, if other precautions have been correctly taken.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Ulf M�ller)
Subject: Re: PSS and PSSR patent status (was Re: XTR)
Date: Wed, 07 Jun 2000 01:14:03 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
>The patent pending on PSS is by the University of California; in a letter
>to the IEEE archived at http://grouper.ieee.org/groups/1363/letters/UC.txt
That page doesn�t exist.
>Incidentally, my SCAN project (Standard Cryptographic Algorithm Naming), at
>
> http://www.users.zetnet.co.uk/hopwood/crypto/scan/
Very interesting. Thanks for the useful information!
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: 6 Jun 2000 20:30:22 -0400
In article <8hjg4f$vj2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David A. Wagner) writes:
>In article <8hiv9l$vcp$[EMAIL PROTECTED]>,
>Bob Silverman <[EMAIL PROTECTED]> wrote:
>> In article <8hhcok$v4s$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (David A. Wagner) wrote:
>> > In article <[EMAIL PROTECTED]>,
>> > Roger Schlafly <[EMAIL PROTECTED]> wrote:
>> > > It is not obvious to me why it a time estimate should be more
>> > > accurate than a space estimate.
>> >
>> > One reason why it might be so is that many theoretical works consider
>> > only the total complexity, and even then, in asymptotic form only.
>>
>> We have real-world benchmarks!!! These are not "theoretical estimates".
>
>Yes, now. But wouldn't you say that people have been studying
>"theoretical estimates" for advanced algorithms longer (or more
...
>The point is, whichever has been studied more thoroughly might
>well be considered better-understood and thus might lead to a
>more reliable (from a very conservative point of view) estimate
>of the complexity of factoring.
I regret to report that this isn't clear to me. The algorithm
in question is gnfs, and H. Lenstra and C. Pomerance (perhaps
among others) knew the asymptotic runtime quite some time ago.
Adleman supplied one of the last crucial steps needed for the
proof in his 1991 paper introducing quadratic characters. Aren't
all of the post 1992 developments, achieved by the people studing
the implementation of the method, asymtotically insignificant in
the world of "estimates"?
If I could recall the original question, which of two methods
for estimating key sizes ought to be relied upon, is the present
proposal that decisions between the key sizes 768-bits, 1024-bits
and 2048-bits should be made without reference to the improved
method for computing squareroots in number fields, to Montgomery's
block Lancozs, or to the recent improvements in polynomial selection?
I'm not in favor of using curve fitting on the results, since in
almost every instance there's been a nontrivial (asymptotically
invisible) improvement, most frequently resulting in dropping a new
factor of two from the runtime. This is one of the features in the
cryptosavvy estimates: a Moore's law for (asymtotically invisible)
runtime improvements, which has held consistently since the first
gnfs factorizations. The other issue is the O(1)'s in the runtime,
which are also treated carefully in the cryptosavvy recommendations.
The claim here being that real-world experience is essential in
accounting for these invisible constants, that (should) strongly
affect practical suggestions about which key lengths ought to be
regarded as having what level of security.
B. Dodson, Dept Math, Lehigh Univ
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: I have worked on this a lot ... actually it continues in the future .. I
talked about these issues with one telecom policy lobby group and its member today ...
Date: Wed, 07 Jun 2000 01:10:14 GMT
I have worked on this a lot ... actually it continues in the future ..
I talked about these issues with one telecom policy lobby group and its
member today at SuperComm2000 (www.supercomm2000.com) ... I can hire a
Russian mathematician from Moscow with 300 algorithms any day ... just
to show you an example ... I hope my "Encryption Policy Position
Statement" shall be implemented to its fullest extent ... !
=====
WASHINGTON -- If the European Union votes next week to relax encryption
regulations, the United States says it will take similar steps.
Commerce Department Undersecretary William Reinsch said Monday that any
change, designed to make sure American high-tech companies aren't
disadvantaged, will have to wait until the Europeans reach a decision.
http://www.wired.com/news/politics/0,1283,36788,00.html
=====
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[EMAIL PROTECTED]>
Subject: Re: PSS and PSSR patent status (was Re: XTR)
Date: Wed, 07 Jun 2000 01:31:51 GMT
David Hopwood <[EMAIL PROTECTED]> wrote:
>The patent pending on PSS is by the University of California; in a letter
>to the IEEE archived at http://grouper.ieee.org/groups/1363/letters/UC.txt
That page doesn�t exist.
>Incidentally, my SCAN project (Standard Cryptographic Algorithm Naming), at
>
> http://www.users.zetnet.co.uk/hopwood/crypto/scan/
Very interesting. Thanks for the useful information!
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: XTR-DH key validation
Date: Tue, 6 Jun 2000 18:43:50 -0700
My earlier comparison of XTR-DH against LUCDIF:
> + somewhat lower bandwidth (512 vs 342 bits)
> + faster parameter generation
> +- may be somewhat faster or slower key-pair generation and key agreement
> depending on optimization choices
> +- neither can take advantage of precomputation
> - slower key validation
I thought of an idea to speed up XTR-DH key validation, which would
eliminate its greatest disadvantage against LUCDIF. In LUCDIF key
validation is easy because we use p such that (p+1)/2 is prime. So
apply the same idea to XTR-DH, i.e., use p such that (p^2-p+1)/3 is
prime. Then to validate public key c, we just have to check that F(c,X)
= X^3-c*X^2+c^p*X-1 is irreducible over GF(p^2). According to the XTR
paper there is a fast (but unpublished) way to do this check. Assuming
this is true, all we need is a way to generate prime p such that (p^2-
p+1)/3 is prime. We can do this by just picking random p's and testing,
or use a sieve as follows.
Pick a random p such that p==5(mod 6) and let q=(p^2-p+1)/3. Compute
two tables of remainders of p and q divided by small primes. For each
iteration of the main loop, increment q by 4p+10 and each entry in the
q-table by 4x+10 where x is the corresponding entry in the p-table,
then increment p and each entry in the p-table by 6. When neither
remainder table contains a zero entry do primality tests for p and q.
Iterate the main loop until both p and q are probably prime.
As an added advantage, this parameter generation method allows XTR to
work efficiently at lower securities levels (say comparable to DH 512),
where the methods in the XTR paper would generate subgroups that are
much too small in relation to the field size.
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
** 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
******************************
