Cryptography-Digest Digest #939, Volume #10 Thu, 20 Jan 00 16:13:02 EST
Contents:
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
More on export controls: (Eric Lee Green)
Re: Wagner et Al. (Guy Macon)
Re: Forward secrecy for public key encryption, and identity-based crypto (ray gaudia)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: Java's RSA implimentation (Greg)
Re: RSA survey ("Thomas J. Boschloo")
Re: Combination of stream and block encryption techniques (John Savard)
Re: Cracking an ADFGVX cipher (UBCHI2)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Thu, 20 Jan 2000 20:00:20 GMT
> There are composite numbers that will work as P/Q for RSA.
> They are VERY, VERY rare-- it is much much more likely
> that a randomly chosen number is prime than a usable
> composite number.
At first, I thought you were saying that the composite would
be stronger than a prime. Is that correct?
But the real question is can you find a composite number that you
think is prime, that appears to work and yet can weaken the key?
If so, it is a crap shoot.
IFP differs from ECC in that the strength of IFP is determined
randomly and with a quick check because the strength lies in the
key itself. With ECC, the strength lies in the curve, not the
key, so the strength of such a cryptosystem can be studied for
years by many people without compromising the keys themselves.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: More on export controls:
Date: Thu, 20 Jan 2000 13:16:09 -0700
The BXA has updated their FAQ at http://www.bxa.doc.gov. It appears that
retail products with any key length are exportable under a type ENC license
exception, if they meet particular requirements (the most important of which
being that the encryption algorithm not be easily modifiable). For software
with 64-bit symmetric key or less, it appears that license exemption TSU can
be applied for, which releases the software from reporting and Internet
screening requirements. For software with greater than 64-bit symmetric key,
it appears that reporting requirements are as such:
foreign distributors -- must report sales to them, but not end user sales
of those
foreign distributors.
direct to foreign individuals -- no reporting needed
direct to foreign institutions -- must report each of these sales.
Our accounting system doesn't discriminate between a foreign individual and a
foreign institution, as far as I know, but I suspect the BXA would not mind
getting more info than they requested. (If they do, well... we'll cross that
bridge when we get to it).
Question: Has anybody else managed to decipher this enough to tell me whether
I'm right in my reading of the situation?
Please, I don't care for ponderings about the evils of our government or
whatever, I just have a job to do and am trying to do it. Note that I have
pointed followups to talk.politics.crypto which is where politics is supposed
to go.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 20 Jan 2000 15:18:16 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> Can an NT installation be set up such that some files are not accessible even to the
>> Administrator? For an system I'm building, I'm seriously considering locking out
>the
>> Administrator account.
>
>IIRC, no. When a user requests access to a secured object, the first
>security check the system does is to find whether the user has the
>ability to take ownership of the object. If they do, the user is
>immediately granted access without any other checks being done.
Not exactly. The first security check the system does is to find
out whether the user has rights to read, write, execute, take
ownership, etc. (Admins never lose rights to take ownership).
You have to actually take ownership to change the other rights.
This is important because you can't give ownership. As a user,
If an Administrator changes a file that you didn't give him
rights to, you can tell because he now owns it, not you. In
addition, there are lots of rights that even the Administrator
and the OS don't have.
All of this is futile if your attacker can gain physical access,
boot Linux from floppies, and edit the NT system files...
------------------------------
From: [EMAIL PROTECTED] (ray gaudia)
Subject: Re: Forward secrecy for public key encryption, and identity-based crypto
Date: Thu, 20 Jan 2000 20:22:20 GMT
If we were to assume:
the info being transmitted from sender to receiver is unique and can
be assigned a multi-digit identification tag; and,
the receiver's email address is known to the sender;
and a date and time of either attempted transmission or moment of
encryption are known to the sender,
is there an encryption method/procedure that can now, today, or soon,
do the following?:
1. deliver via the internet each time, via HTML or even via an email
attachment (and if the sender/receiver desires, be held on their PC or
MAC or Mainframe to be used again, each time they transmit or receive
encrypted files)
a. an encryption/decryption software system (among the
many that I see presented here over the years) to the sender and to
the receiver that will permit the sender to easily encrypt (drag and
drop the component information elements listed above) to create the
unique, uncrackable "hash"?
I'd like to find an easy way for the less than
sophisticated sender and receiver to each encrypt and decrypt rather
quickly (under 3 minutes to encrypt and decrypt a file that's about .5
MB after compression).
2. If the sender and the receiver each know a shared secret, the
unique identification number of the transaction...because they each
know the elements that make up that unique identification number, then
is this merely a symmetric cryptographic transaction?
3. If the sender employs the unique fact of a date and time when the
encryption occurs, is there a safe way to notify the receiver of this
secret known only to the sender? (other than by voice or
fax?)...possibly using SSL, if the receiver can read an SSL'd email
transfer?
If the sender and the receiver can both know in advance of a
date and another fact, those facts, coupled with one or two additional
facts, could serve as the encryption, decryption key.
As an example,
Sender and receiver each know: the date the transfer request was
initiated; they know the quantity of widgets (for lack of another idea
here) that are the subject of the transfer; they know type of widget;
they know the receiver's email address; they know the name of the
widget manufacturer; and they know a unique transfer-initiating
document number. In a nutshell, the sender and receiver, prior to
the transfer, know about 5 or more separate shared secrets. The
entities that established those shared secrets only know those
secrets...they do not know the date and time that the encryption takes
place.
Thus I think the major question is what cheapo-or-free, strong
encryption software can be universally (or nearly universally) be
disseminated... (not tied to Microsoft or to Netscape, but independent
of those guys, to allow this transfer to occur without "tax". Your
suggestions will be most appreciated.
The next question is how to transfer between the sender and the
receiver the one secret they each need to share so the receiver can
easily add that to the decryption key which the receiver will already
know. Your suggestions will be most appreciated.
The structure of the encrypt/decrypt key could be at the option of the
sender, literally randomly organized... date first, year first, widget
number first, number of widgets first, etc. It seems a simple matter
of sending that sequencing information in the clear as only the sender
and the receiver know that information (save and except the
transaction initiator).
If the key sequencing information can be sent securely, via SSL, along
with the date and time, it looks "manageable" and "doable" by the
ignorant-to-the-world-of-encryption sender and receiver, within an
economically tolerable period of time.
Would this work for stock brokerage confirmations? Would it work for
customer purchases or raw materials sales transactions?
After years of being a neophyte watching the interactions here, I
conclude that the identity-based scheme logic invites a usurious tax
as the trusted third party and the escrow holder and the verifier and
the patent holder all stand eagerly ready to extract their "pound of
flesh." [I certainly don't begrudge a patent holder on the
encrypt/decrypt system and welcome any opportunity to negotiate access
to a real-life, working system that will permit me to accomplish this
goal.]
NB: This is not from the mind of a cryptographer. It's from a
grateful watcher who has tried to understand how to solve this type of
problem for quite a while.
GAUDIA
On Thu, 20 Jan 2000 08:59:57 +0000, David Hopwood
<[EMAIL PROTECTED]> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>John Savard wrote:
>>
>> On Sat, 15 Jan 2000 07:47:49 +0000, David Hopwood
>> <[EMAIL PROTECTED]> wrote, in part:
>>
>> >Normally, I wouldn't trust an identity-based protocol, because
>> >the identity-based model has several inherent security problems:
>> > - the "trusted" authority has enough information to calculate
>> > any user's private key, and therefore is a weak point of the
>> > whole system (to a greater extent than root CAs in a CA-based
>> > system).
>> > - it's impossible for users to verify that their keys aren't
>> > being "escrowed".
>> > - private keys have to be sent from the authority to each user,
>> > which is likely to be another weak point.
>>
>> >However, none of these objections apply to a forward-secure
>> >scheme constructed using this method, because each user is their
>> >own trusted authority.
>>
>> I am puzzled about how such a scheme is going to work. If the
>> condition that must be fulfilled for an identity-based scheme is that
>> to send messages to user X, all you need to know is user X's identity,
>> and don't have to download a public key,
>
>Yes (technically this is an "ideal" identity-based scheme, according
>to the terminology in Handbook of Applied Cryptography Remark 13.27,
>which is what we need for this construction).
>
>> then if I can compute the key
>> for sending messages to user X from that identity myself, and if user
>> X can compute the key for reading those messages himself from his
>> identity,
>
>No, X is *given* his secret key (supposedly via a secure channel or in
>person) by the trusted authority, who is the only one who can calculate
>it from X's identity.
>
>(It's the ideal set-up for covert key escrow, which is one reason why
>I would never recommend using a identity-based scheme directly.)
>
>In the forward-secrecy construction, we delete the "authority"'s
>private information at the end of key pair generation, so that no-one
>can recalculate private keys after that point. The authority cannot
>cheat the user by failing to delete the information, because the
>authority is the user. Also, the problem of how to securely transmit
>the private key from the authority to the user doesn't arise.
>
>> doesn't it follow that *everybody* who knows user X's
>> identity can compute both keys, and read all the messages?
>
>It would follow, but your premises are wrong.
>
>> On the other hand, two users certainly can engage in ordinary
>> public-key communication without the help of a trusted authority, and
>> the identity can play some trivial additional role in complicating the
>> protocol without changing its security.
>
>I agree entirely. I don't think that identity-based schemes are secure
>or particularly useful, except that they happen to be a neat way of
>constructing a scheme that provides non-interactive forward secrecy,
>which would be extremely useful.
>
>If it isn't clear, it's worth stressing that the scheme resulting from
>the construction is not identity-based. It would use conventional
>means such as certificates, key servers, verification of hashes
>over an authentic channel, etc., to ensure the authenticity of public
>keys.
>
>> I hope you can supply a simple explanation of how what you are trying
>> to achieve differs from either of the two scenarios above, and can
>> genuinely be thought of as being, in some sense, an identity-based
>> scheme without a trusted authority (which would indeed be immensely
>> useful if it were possible).
>
>It isn't possible. There has to be something which distinguishes the
>owner of an identity from anyone else who just knows the identity.
>That "something" must be access to secret information (technically
>if it was a real-world object that can be reliably recognised but is
>difficult to forge, that might not apply, but real-world objects can't
>be sent over communication channels).
>
>The problem is therefore to associate an identity with an algorithm
>that performs one side of a protocol (such as encryption or signature
>verification), such that the other side of the protocol can only
>be performed by someone possessing the secret.
>[Here an "algorithm" includes any parameters, such as public keys,
>that it uses.]
>
>Suppose that an attacker may be computationally more powerful than
>any party involved in the protocol (this is a basic assumption of
>modern strong cryptography). If we start off with an identity
>that has no a priori association with a secret (like an email
>address or a name, for example), then everyone, including potential
>attackers and potential trusted authorities, is in the same position
>with regard to their ability to specify an association between
>identities and the corresponding algorithms.
>
>To resolve this situation, there are only three possibilities (for
>two-party protocols):
>
> - maintain the association yourself (in which case you need to
> send some secret data to the other user over a secure channel;
> this is just symmetric cryptography)
> - trust the second party to maintain the association (in which
> case they need to send you some secret data; this is also
> symmetric cryptography)
> - trust a separate third party.
>
>[Of course, it would in principle be possible to start off with some
>secret data for each user, and then assign "identities" dependent on
>that data - for example you could adopt the convention that email
>addresses always include a hash of an associated public key, or you
>could generate a private key for people at birth and make the public
>key part of their name (which would have to be changed in order to
>revoke the key :-). But that wouldn't solve the "problem" (if it is
>in fact a problem) that identity-based crypto set out to address,
>which is to allow the identity to be something that is memorable,
>and that would have to be known anyway in order to interact with the
>given user.]
>
>- --
>David Hopwood <[EMAIL PROTECTED]>
>PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
>
>"Attempts to control the use of encryption technology are wrong in principle,
>unworkable in practice, and damaging to the long-term economic value of the
>information networks." -- UK Labour Party pre-election policy document
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBOIbOfjkCAxeYt5gVAQGjFwf/U8aYlKGq28k6YgW0yiAqUg74DEI7hCuD
>n9WZ0haAvkznP2kShAaVGeFj5UB18EQhD9I+4lE0EL2en7mkQYFA2TxmtkhxHHMs
>4IWAOvJzK2g7C98dNbNeGo1R+9Gs/p38q1wNydxUaYCR4dRT01ynE7wN3M1uT8oM
>Lj1ubt6dlOi4drFMO2GCMomxx6cb80TGx4vD+bBe+4To3LqoW7OA21XWwqTK2oVi
>FJB0T3W4lUFowPB/CDkROFjvr5anljpE6HfX5HS8JtaUVLwDNTavNlS1iyZgZUAQ
>KC6QL1EvEwd1h8+2VxjCFLhKdbeKWxgLa9zvHPP4ZZDm0RyuvGuTJA==
>=/hJ/
>-----END PGP SIGNATURE-----
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Thu, 20 Jan 2000 20:18:09 GMT
> There are composite numbers that will work as P/Q for RSA.
> They are VERY, VERY rare-- it is much much more likely
> that a randomly chosen number is prime than a usable
> composite number.
It seems to me that RSA key strength is dependent on selecting
"the right key" where as ECC key strength is dependent on
selecting "the right curve".
The strength of RSA is determined at run time. The strength
of ECC is determined before deployment of the curve.
IMHO, that is the only reason I don't trust RSA/IFP cryptosystems.
This does not mean that I enjoy better security strength. But it
does mean that from what I know, I can sleep better at night.
And that is all I have ment to say all along, really.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Date: Thu, 20 Jan 2000 20:22:00 GMT
I remember installing Borland's Java DK and it had a bunch
of libraries to provide RSA key generation and other crypto
stuff. I only noticed it was there, not what it did or anything.
I think the libraries were written by Borland or Sun.
> >Is anyone aware of any effort to analyse the RSA implementation in
Java;
> >specifically focusing on key generation.
>
> ??? Java is a language, much like C in many essentials. It is up to
you
> to code what you want it to do.
>
> >Does Java use a table of primes? If so, how big is the table?
>
> No, Java does not. But you can enter a table of primes if you wish.
And
> you can encode a prime testing routine in Java just as you can in C.
>
> >Otherwise how good is it's prime number generation routines ie. what
is
> >the probability of a generated number not being prime.
>
> I do not know that Java has a "prime number generating routine". but
you
> can code one up in Java.
> Jus tread the code in any RSA implimentation.
>
> >Thanks.
>
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: RSA survey
Date: Thu, 20 Jan 2000 20:43:18 +0100
This is a multi-part message in MIME format.
==============3C02EA6904B5E776147B7A64
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom St Denis wrote:
>
> Just a quick survey... What size of RSA key would you feel safe with
> for your crypto needs?
My RSA key is 800 bits and I feel that is more safe than my (windoze)
laptop will every be. If writing my own crypto app, I would however use
a keysize that couldn't be cracked if we put the whole solar systems
energy towards cracking it.
Then I would use a fixed keysize and just one algorithm to keep things
easy and to make it easy for people to say if the product is secure or
not. If breakthroughs occured, making the fixed keysize unsafe for
ethernity, I would just write a new product which a better algorithm and
new keysize. [backwards incompatible with the previous version, I like
things to be 'perfect'].
Like I mean, people can still generate 512 bit RSA keys with PGP, so
other people say "You shouldn't create 512 bit keys, they are unsafe",
so people think, "I get the ckt build and generate a 16k key" (even
though 3100 bits RSA equals 128 bits IDEA).
I feel you have more knowledge on calculating this than simple me, but I
have included a post from Scott Nelson which sets the ultimate ridiculus
keysize at 362 bits (I would not use more than our solar systems energy
however, since there is also the speed of light limit, which makes
sending messages between different solar systems for parallel processing
inefficient).
--
Boycot Intel Pentium III <http://www.bigbrotherinside.com/>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
==============3C02EA6904B5E776147B7A64
Content-Type: text/plain; charset=us-ascii;
name="128pkeys.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="128pkeys.txt"
Path:
news2.support.nl!news-x.support.nl!newsfeed.icl.net!news.algonet.se!algonet!newsfeed.online.be!tank.news.pipex.net!pipex!uunet!ams.uu.net!nyc.uu.net!pao.uu.net!news.inreach.com!not-for-mail
From: [EMAIL PROTECTED] (Scott Nelson)
Newsgroups: comp.security.pgp.discuss,sci.crypt,alt.security.pgp
Subject: Re: Is 128 bits safe in the (far) future?
Reply-To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Newsreader: Forte Agent 1.5/32.452
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 43
Date: Thu, 07 Oct 1999 22:25:54 GMT
NNTP-Posting-Host: 209.209.19.160
X-Trace: news.inreach.com 939334871 209.209.19.160 (Thu, 07 Oct 1999 15:21:11 PDT)
NNTP-Posting-Date: Thu, 07 Oct 1999 15:21:11 PDT
Organization: InReach Internet
Xref: news2.support.nl comp.security.pgp.discuss:1493 sci.crypt:6042
alt.security.pgp:2804
On Wed, 06 Oct 1999 23:18:39 -0400, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
[edited]
>Thomas J. Boschloo wrote:
>
>> "Trevor Jackson, III" wrote:
>> It has however made me extremely curious as to what your
>> worst case bit length would be?
>>
>
>Taking the reductio-ad-absurdum numbers I mentioned originally I think you
have 1e33^3
>processors per cubic meter, 1e16^3 meters per cubic light year, and 1e10^3
cubic light
>years per observable universe. Total processor count is thus 1e178. Given
a cycle time
>of 1e-43 seconds, 3e7 seconds per year, and the life of the universe at
1e31 years, you
>have 3e81 testing cycles. Total number of tests is 3e259.
>
>That's about 865 bits. Quite a lot by today's crypto standards. Not a lot
given the rate
>of growth in machine capacities.
>
You can get a much smaller number if you assume that
testing a key requires some energy. This is also
convenient since we don't have to address the time
issue at all.
Mass of the observable universe, < 1e52 kilograms
1Kg, < 1e17 Joules.
Energy needed for calculation, > 1e-40 Joules.
upper-bound on number of key tests performable in
the observable universe; 1e109, or 362 bits.
If you're willing to add other restrictions like
"you can't convert mass to energy without loss,"
or "you have to save some of the universe to live in,"
then you can use even fewer bits.
There are ciphers with more than 362 bit keys,
but long before 256 bits is reached, it becomes easier
to find the key by looking in every place it might
be hidden (including your adversaries mind.)
Scott Nelson <[EMAIL PROTECTED]>
==============3C02EA6904B5E776147B7A64==
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Thu, 20 Jan 2000 13:48:21 GMT
[EMAIL PROTECTED] (wtshaw) wrote, in part:
>Trying to find the establishment in such a field that is so dynamic on
>*ours* is generally apt to have negative inpact on new ideas rather than
>to be helpful. Please do not try to find the status quo, as some would
>have that fixed in a egocentric view of reality rather than feeding new
>enthusiasms to expand the field.
I don't need to make effort to find the "status quo", it makes itself
obvious.
New ideas benefit everyone when they are widely used; and most users
of cryptography, or anything else, do try to find the "recognized
experts" when looking for advice they can trust.
Thus, when new ideas of value become accepted in the right places, the
result is beneficial.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (UBCHI2)
Subject: Re: Cracking an ADFGVX cipher
Date: 20 Jan 2000 20:56:24 GMT
ADFGVX coordinates implies a 6x6 checkerboard.
With computer brute force tactics, you could create every variation of
alphabetic checkerboards and then all transposition grids for the 6x6
checkerboard force attempts. This would not be hard if you had a plaintext
crib either.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Thu, 20 Jan 2000 12:58:41 -0800
"Paul Crowley" <[EMAIL PROTECTED]> wrote ...
[...]
: I'll try and measure the bias in RC4-54 when I get time.
That would be interesting, I think. (But imo it would be more appropriate
to call this something like ARC4-52, since it is an implementation of ARC4
-- or at least the stream generator of ARC4 -- with altered state-vector
length M=52 *and* altered combiner. It's worth emphasizing that the modular
addition combiner does not produce to ARC4's XOR combiner when M=256.)
: > A side question is what is the state space size for Solitaire. It seems
: > to me that, just as my card-deck implementation of ARC4 uses the jokers
: > as pointers, so does Solitaire, although in a more complicated way.
:
: Solitaire's state space is slightly larger than that of your cipher:
: 54! compared to 52! * 52 * 52. That's because with your cipher jokers
: can't end up on the bottom, and the order of two jokers next to each
: other can't matter.
For ARC4 using 54 cards in the way I described, it's certainly 52!, because
the jokers are used strictly as pointers. (ARC4's state-vector of length M
has M! states, and the card version is *constructed* to use the jokers in
1-1 correspondence with the pointers in ARC4's algorithm. Only the sequence
of the 52 non-jokers constitute the state-vector.)
: > (Note that arriving at a joker in the final step of Solitaire is a
"null"
: > result, consistent with them being pointers and not part of the state
: > vector itself.)
:
: They are part of the state vector. They just get skipped in the
: keystream generation stage.
I have to agree that for Solitaire they are part of the state-vector, and
hence the 54! -- my reasoning is that it's because the jokers are *not*
skipped in all the counting routines, as they must be if they're pointers
(e.g. as in ARC4-52).
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
** 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
******************************
