Cryptography-Digest Digest #934, Volume #10 Thu, 20 Jan 00 04:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Forward secrecy for public key encryption (new proposal) (David Hopwood)
Re: Triple-DES and NSA??? (David Hopwood)
Re: Intel 810 chipset Random Number Generator (Terry Ritter)
NIST, AES at RSA conference (Hammer)
Hagelin Cryptanalysis on Web Site (John Savard)
Re: ECC vs RSA - A.J.Menezes responds to Schneier (David A Molnar)
Re: Forward secrecy for public key encryption: MYH (David Hopwood)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 20 Jan 2000 05:16:43 GMT
Reply-To: [EMAIL PROTECTED]
Paul Koning ([EMAIL PROTECTED]) wrote
]seifried wrote:
]> ...it really boils down to "do you trust an
]> american company to generate your random data?".
]
]It's not just american companies that have done sneaky
]things in this area... Crypto AG was Swiss, if memory serves.
]
]> ...
]> If you want a real hardware RNG you can verify there are simple ones
]> based of radio crystals/etc that plug into a serial or parallel port
]
]Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
]those sound plausible, but crystals won't serve at all for this
]application.
Yes, they will. Crystals have thermal noise.
------------------------------
Date: Thu, 20 Jan 2000 05:44:11 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Forward secrecy for public key encryption (new proposal)
=====BEGIN PGP SIGNED MESSAGE=====
A few additional notes and corrections:
I wrote:
[...]
> Let R be a hash of the public key - see later for the precise
> definition. (R will be used as a random seed for the generation
> of public values; a hash of the public key is a convenient way
> of doing this that does not require extra data to be stored.)
Note also that this definition of R prevents someone from creating
a public key which is functionally identical to a given existing
public key (i.e. so that the corresponding private key will still
decrypt messages created using it), but which is insecure because
the value used to determine the length of ephemeral exponents is
too small.
[The ability to do this would be a bad thing despite the assumption
that public keys are normally authenticated, because it would mean
that a security failure of the PKI leading to substitution of a
public key would be less likely to be noticed. With this definition
of R, OTOH, the sender of a message using the faked key would
calculate a different public value inconsistent with the real
private key, causing decryption to fail (i.e. to output BAD).]
The security property required of the hash H for this purpose is
2nd preimage resistance. H should also have pseudo-random output
(i.e. approximate a fixed output-length PRF), and if it is used by
the MAC or F function, they may require other properties.
[...]
> 4. Let l_q be the length of q in bits (i.e. floor(log_2(q))).
The length of q in bits is floor(log_2(q))+1. However, for
a reason explained below, we change this parameter to
floor(log_2(q))+b where b is a fixed security parameter, and
rename it to l_k. The public key will therefore be (m, y, h, l_k).
[...]
> Let F be a pseudo random function that maps a bit string to the
> set of integers [2, n-2].
This should have been [2, m-2].
> Encryption [full version]:
[...]
> 2. Choose a random k in [1, 2^(l_q+1) - 1].
Change this to:
2. Choose a random k in [1, 2^l_k - 1].
> [This differs from [DHAES], where k (which is called 'u'),
> is chosen from [1, |G|]. In this case |G| would be the size
> of the subgroup, q, which would then need to be included in
> the public key. I'm not sure that would be a good idea (see
> the "Open questions" section later). Of course this
> invalidates the DHAES security proofs, but they would be
> invalidated anyway by the other changes.
> It would also be possible to use [1, 2^(l_q+b) - 1] for
> some b > 1; as b increases, any bias in the selection of
> U = y^k from the elements of the subgroup becomes
> negligable.]
We put the desired length of k in the public key rather than
having the sender of a message choose b, because it is generally
the creator of a key pair who should determine security
parameters.
[...]
> As far as I know, an implementation of this scheme would not
> infringe on any patents provided the algorithms for H, F, SYM and
> MAC do not.
This statement stands, despite Maurer's patent [*]. I believe the
system I've described is sufficiently different from the claims
of that patent that it does not infringe (specifically, every
claim describes an identity-based cryptosystem, which MYH is not).
However, I am not a patent lawyer.
[*] U.S. patent #5150411,
"Cryptographic system allowing encrypted communication
between users with a secure mutual cipher key determined
without user interaction,"
http://www.patents.ibm.com/details?pn=US05150411__
- --
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
iQEVAwUBOIagazkCAxeYt5gVAQEVEgf+NymbAaoC1Nilt0u2PJjs3w/uoGwFcKp+
K3Oyv0/hL0ySANPPlb7tP2vgdDbkKr6GUTvcKtUTJE/pKGTe4Y5lewUGK9JFrFL8
PXKVe3H5KH4CfhUbnK6PjJNpYNuFAm6ffNvtvPJEcB6g+3zvk8DMlKmev9u1w6t/
dWSeXSN7QT14NSXA8xh+E0rO3zQxuGN/gQ+by9Wg0dAz20slganPqO29h+3gxbex
0KcTKmgRHJq4ErUAT3TAtAiB0Neo/bFtpzwPXZpiREoO5miZgHqZRHUxc1ve9Zdg
4iHDnrmgUbJMTnYnOAGulGOYYI2nluscY/0FL3brROYsvbAg4kNKnQ==
=bV5V
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 20 Jan 2000 05:44:36 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
=====BEGIN PGP SIGNED MESSAGE=====
Tommy Lacroix wrote:
>
> FYI, max key sizes:
> RC6 2048 bits
The maximum key size for RC6 is actually 2040 bits (255 bytes).
> TwoFish 256 bits
> Rinjdael 256 bits
> Mars 1248 bits
The maximum key size for the "tweaked" version of MARS (i.e.
the second round AES candidate) is 448 bits.
> BlowFish 448 bits
- --
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
iQEVAwUBOIZqGTkCAxeYt5gVAQFMsAgAr82sFfrWs2iWUHX8jIJlBdzPvpFe9UYb
d9EDR1cjfe+ziucRROpfzUTRNpcxKZku/CNPK/C2VdxA2hlCBs53/A02nSTN7pjl
tpoOKE52dQ9Rwh1CZvtFlxeaOWiRf6vY05/mJoaYyOylrUr/BlHOLyzNMWm6obem
fkg/88vrvUcuNjT/WbdoCL1w8kMMYBArLQrHyHG5fE2dJckdN5jWr/r4VwtQmywu
/FLwOUKS59k/Uu71P4UJZiRugSYlFUlBTzYaWBC4Qs+nyu/3fJ8EpVo+hYnARIrR
sRWk/y1qJa3sKlJq2LMxpc0w2wDnwK76+koeV3MjvcOVJ1vTHkaMVA==
=/+5M
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Intel 810 chipset Random Number Generator
Date: Thu, 20 Jan 2000 06:03:04 GMT
On 20 Jan 2000 05:16:43 GMT, in <8665nr$6ro$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (Michael Kagalenko) wrote:
>Paul Koning ([EMAIL PROTECTED]) wrote
>]seifried wrote:
>]> ...it really boils down to "do you trust an
>]> american company to generate your random data?".
>]
>]It's not just american companies that have done sneaky
>]things in this area... Crypto AG was Swiss, if memory serves.
>]
>]> ...
>]> If you want a real hardware RNG you can verify there are simple ones
>]> based of radio crystals/etc that plug into a serial or parallel port
>]
>]Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
>]those sound plausible, but crystals won't serve at all for this
>]application.
>
> Yes, they will. Crystals have thermal noise.
OK, so just how much thermal noise would one measure from a crystal,
how would we measure it, and where can we find a published reference
to back that up?
At one time, crystal filters were used in fine communications
receivers; such receivers are intimately involved with noise, and are
compared in part by actual noise measurement. We can thus reasonably
conclude that in communications receivers any noise which was added by
a crystal filter was far below the modest signal levels involved.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Hammer <[EMAIL PROTECTED]>
Subject: NIST, AES at RSA conference
Date: Thu, 20 Jan 2000 07:41:14 GMT
I attended a track at the RSA Conference today in which NIST spoke on
the AES standard, the process, where it's at, etc.
One of the interesting things I took from the talk was, in my opinion,
they are nearly BEGGING for cryptanalysis of the AES finalists. You'd
think that with NSA "advising", they'd have plenty of access to that
skill, but there could be political caveats to that. I asked them if
they further considered that Twofish is actually multiple ciphers... he
(Ed Roback from NIST) basically shrugged that off as insignificant
(maybe rightly so?).
In the end though, I got to thinking about the general shortage of
cryptanalysis experts (implied or real). Then, if you figure some of
the best cryptanalytic minds (arguably) are the submitters of the
finalists... then the shortage of unbiased third party cryptanaylists
is made more acute... no?
One other thing I got to thinking about... if we are so short of
cryptoanalysts (which seems to be a major underlying theme of the elite
here at the conference)... and, considering the bar for entry is so
very high (Ph.d. required, plus)... what's gonna happen when Shamir,
Rabin, Schnier (insert your favorite crypto experts name here) retire.
Who's gonna run with the torch?? If everyone but those people are
locked out (figuratively or actually) now... is the shortage of
cryptoanalytic talent just going to dry up?
In a talk Kocher did earlier in the day, he mentioned the same shortage
in no uncertain terms, although he was referring to the broader
security business, not just crypto. Apparently, "guru level" folks are
few and far between.
Is the shortage of this talent really as acute as it seems?
Thanks for any thoughts on this.
hammer
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Hagelin Cryptanalysis on Web Site
Date: Thu, 20 Jan 2000 07:53:38 GMT
Yes, after the section on the Hagelin lug and pin machines, I've added
a page on how they might be cracked, at
http://www.ecn.ab.ca/~jsavard/ro020201.htm
The techniques are pretty simple and straightforwards, and require no
advanced math (although I do talk about the Chinese Remainder Theorem
on the page). They're only applicable against the original C-38, and
thus are, I think, rather far from the territory that was of some
concern to the NSA several years ago.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 20 Jan 2000 08:23:39 GMT
DJohn37050 <[EMAIL PROTECTED]> wrote:
> There are many advantages of ECC over RSA. See my PKS '99 paper.
> Montgomery gave a talk at RSA 2000 on doing the matrix reduction on a connected
> machine. Montgomery is one of the best in this area.
Do you know if he has made slides available or plans to publish anything
anytime soon?
Thanks,
-David Molnar
------------------------------
Date: Thu, 20 Jan 2000 08:55:31 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Forward secrecy for public key encryption: MYH
=====BEGIN PGP SIGNED MESSAGE=====
David Wagner wrote:
>
> Allow me to sketch the bare bones of a possible attack direction, and
> I hope you will tell me whether it works or not.
>
> If I understand correctly, we have
> y_t = F(R,t)^{2s}
Yes.
> = alpha^{x_t} mod m
No.
x_t = u.log_alpha(y_t) mod phi(m)
or (if u is relatively prime to phi(m), which it will be with
overwhelming probability):
y_t = alpha^(x_t.u^-1 mod phi(m)) mod m
where u is a secret value that is deleted at the end of key pair
generation.
Besides being used in the definition of private keys, u is also
used in one other place, to calculate h:
h = 2.s.u.log_alpha(y) mod phi(m)
but it can't be inferred from h, for the same reason that it can't
be inferred from any known key pair (x_t = u.log_alpha(y_t), y_t);
i.e. the assumption that the discrete log problem in the subgroup
is hard.
I perhaps didn't structure my post very clearly; this was a
modification explained half-way through, made specifically to
prevent the attack you describe.
For clarity, I will write out the final version in full at the end
of this post, rather than just describing the changes.
> where F() behaves pseudorandomly and F,R,t,s,alpha,m are known.
alpha and s aren't known, in the final version.
> Suppose we recover the private key at time t, so that x_t becomes known.
> If we set a = F(r,t)^s mod m and b = alpha^{x_t/2} mod m, we will obtain
> the relation
> (*) a^2 = b^2 mod m.
> When x_t is even -- half of the time -- we can compute a and b from the
> known quantities and thus form the value gcd(a-b,m).
>
> Now *if* a and b behave as though there were chosen randomly from the
> set of values satisfying (*) -- and I have no idea whether this will
> happen or not -- then gcd(a-b,m) would reveal a non-trivial factor of
> m with high probability.
Yes, this is the same attack as described in [MY96] section 2. However,
with x_t = u.log_alpha(y_t), we can't recover log_alpha(y_t) in order
to start the attack.
> Of course, if we could factor m using these tricks, we could break the
> forward secrecy properties and recover x_{t'} for t' < t, which is
> supposed to be forbidden.
Yes, but it's not completely obvious (because we don't know g, alpha,
or the alpha_i):
1. Factoring m gives p_i - 1 for each i.
2. Factoring p_i - 1 for each i using ECM gives q_i and z_i
(since the q_i will not be large enough to resist ECM).
3. Take some arbitrary group element, and raise to the power
2.s.q/q_i (or h.q/q_i); this should give an element of
order q_i.
Repeating this for each i gives a set of bases that can be
used, in a similar way to the original key pair generation (he
said, handwaving wildly), to find the discrete log of any
subgroup element to a given base, even though the original
alpha_i are not known.
[This answers one of my "open questions": q *must* be deleted,
because otherwise step 3 of the above attack can be applied even
without knowing the factorisation of m. I.e. any practical way
of finding q (the order of the subgroup) makes the scheme
insecure, I think.
Also, the q_i must be large enough that there is negligable
probability that the discrete log of a random subgroup element
(e.g. one of the y_t) to the base alpha will be a multiple of
any of the q_i (because otherwise, that element would generate a
smaller subgroup, in which it might be possible to calculate
discrete logs).
The proportion of such "weak" elements (and hence the probability
of getting one when choosing at random) is approximately
sum[1/q_i: i = 1..r]. I think it's probably sufficient for the
q_i to be in the range 40 to 60 bits.]
[...]
> What do you think? Am I off my rocker?
No, good try, but I'd already designed out this attack.
========
Here is the final description of the MYH cryptosystem. The only
changes are in presentation, and to incorporate some minor changes
described in one of my other posts.
Definitions:
Let H be a public hash function.
Let F be a pseudo random function that maps a bit string to the
set of integers [2, m-2]. (This could for example be based on
MGF1 from [P1363].)
Let SYM be a symmetric encryption algorithm, with key length eLen.
Let MAC be a message authentication code, with key length mLen.
Notes:
- H, F, SYM and MAC must be agreed or standardised in advance.
- For simplicity, if F and/or MAC are based on a hash function,
H should be used.
- SYM will only be used to encrypt a single message under a
given key, so it can be either a stream cipher or a block
cipher.
- It would in principle be possible to combine SYM and MAC,
using a symmetric encryption scheme that also provides message
authentication.
- The issue of encodings for integers, inputs to H and F, and
ciphertext is glossed over below - these need to be unambiguous.
- See [DHAES] for clarification of the notation, and a rationale
for various features.
Key pair generation [full version]:
1. Choose distinct random primes p_1..p_r, of roughly equal size
and where the factorisations of p_i - 1 are known, such that
the values (p_i - 1)/2 are odd and pairwise relatively prime,
and q_i is a prime dividing (p_i - 1)/2 for each i.
Let m = product[p_i: i = 1..r]
q = product[q_i: i = 1..r]
z_i = (p_i - 1)/q_i
s = sum[z_i: i = 1..r]
The q_i (which are necessarily all distinct) should be primes of
a size such that Pollard rho is practical in a subgroup of size
q_i for each i, but not in a subgroup of size q. A reasonable
choice for this size would be 40 to 60 bits.
The z_i must not be smooth, and should preferably each be twice
a prime number.
2. Select elements alpha_i that generate subgroups of sizes q_i, as
follows:
a) Choose an element g of Z*_m that is primitive in each of the
prime fields Z_{p_i}, i.e., such that for i = 1..r, p_i - 1
is the smallest exponent for which g^(p_i - 1) = 1 (mod p_i).
(To test whether g is primitive in Z_{p_i}, check that
g^((p_i - 1)/a) mod p_i != 1 for each prime factor a of
p_i - 1.)
b) Compute alpha_i = g^z_i for i = 1..r.
alpha = product[alpha_i: i = 1..r].
[Note that:
- g has maximal order phi(m) in Z*_m,
- alpha_i has order q_i,
- alpha has order lcm[q_i: i = 1..r] = product[q_i: i = 1..r] = q,
- alpha = g^sum[z_i: i = 1..r] = g^s.]
Let R be a hash of the public key - see later for the precise
definition. (R will be used as a random seed for the generation
of public values; a hash of the public key is a convenient way
of doing this that does not require extra data to be stored,
and has some security advantages.)
Choose u at random from [1, phi(m) - 1].
3. For t = 0..T (where T is the number of time periods),
a) Let beta = F(R, t)^2,
y_t = beta^s.
b) Calculate the discrete logarithm w = log_alpha(y_t).
Note that since y_t = beta^s, alpha = g^s, and alpha_i = g^z_i,
log_alpha(y_t) = log_g(beta) (mod q)
= log_alpha_i(beta^z_i) (mod q_i)
[beta^z_i is guaranteed to be in the subgroup of order q_i
generated by alpha_i.]
Therefore we can calculate w as follows:
i) For each i = 1..r, use Pollard rho (see Algorithm 3.60 of
[HAC], or [Pollard]) to compute the discrete log w_i of
beta^z_i mod p_i to the base alpha_i.
ii) Solve the system of congruences
w = w_1 (mod q_1 - 1)
: : :
w = w_r (mod q_r - 1)
by the Chinese remainder technique (e.g. Algorithm 14.71
of [HAC]). Note that w will be in the range [0, q-1].
c) Let x_t = u.w mod phi(m).
4. Let y = y_0,
h = 2.s.x_0 mod phi(m),
l_k = floor(log_2(q)) + b.
where b is a security parameter (a reasonable value for b would
probably be about 40).
Retain (m, h, y, l_k) as the public key, (x_1..x_T) as the
private key, and delete all other values (p_i, q_i, q, z_i,
s, g, alpha_i, alpha, x_0, u, and any intermediate results).
Encryption [full version]:
1. Obtain the recipient's authentic public key (m, y, h, l_k), and
the current time period t (or a time period in the near future,
to take into account delays in delivering a message).
Let M be the plaintext message.
2. Choose a random k in [1, 2^l_k - 1].
[This differs from [DHAES], where k (which is called 'u'),
is chosen from [1, |G|]. In this case |G| would be the size
of the subgroup, q, but it is essential to keep q secret.
Of course this invalidates the DHAES security proofs, but
they would be invalidated anyway by other changes.
However, if the security parameter b is large enough, any
bias in the selection of U = y^k from the elements of the
subgroup will be negligable.]
3. Calculate R = H(m, y, h, l_k),
X = (F(R, t)^h)^k,
U = y^k,
hash = H(U, X),
macKey = first mLen bits of hash,
encKey = next eLen bits of hash after macKey,
encM = SYM.enc(encKey, M),
tag = MAC.gen(macKey, encM),
The ciphertext is (t || U || tag || encM).
[Note: The pseudocode for encryption in figure 2 of [DHAES]
is incorrect; it applies the MAC to M, whereas the rest of
the paper, including the security proofs, applies it to encM
as shown here.]
Decryption [full version]:
Note that an output of BAD means that the ciphertext was not valid.
1. Parse the ciphertext as (t || U || tag || encM)
(if it cannot be parsed this way, or if t = 0, output BAD).
2. Calculate X = U^x_t,
hash = H(U, X),
macKey = first mLen bits of hash,
encKey = next eLen bits of hash after macKey.
If MAC.ver(macKey, encM, tag) fails, delete any intermediate
results, and output BAD.
Otherwise, the plaintext is SYM.dec(encKey, encM).
References:
[DHAES] Michel Abdalla, Mihir Bellare, Phillip Rogaway,
"DHAES: An Encryption Scheme Based on the Diffie-Hellman Problem,"
Contribution to IEEE P1363a.
http://grouper.ieee.org/groups/1363/contributions/dhaes.pdf
(temporary URL), or
Theory of Cryptography Library.
http://philby.ucsd.edu/cryptolib/1999/99-07.html
[P1363] (Draft) Standard for Public-Key Cryptography,
http://stdsbbs.ieee.org/groups/1363/index.html
[HAC] A. Menezes, P.C. van Oorschot, S.A. Vanstone,
Handbook of Applied Cryptography, CRC Press, 1997.
http://www.cacr.math.uwaterloo.ca/hac/about/chap<n>.pdf
where <n> is the chapter number.
[Pollard] J.M. Pollard,
"Monte Carlo methods for index computation (mod p),"
Mathematics of Computation, 32 (1978), 918-924.
[MY96] Ueli M. Maurer, Yacov Yacobi,
"A Non-interactive Public-Key Distribution System,"
Designs, Codes and Cryptography, 1996.
http://www.inf.ethz.ch/personal/maurer/publications.html
ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/dcc.ps
- --
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
iQEVAwUBOIbNITkCAxeYt5gVAQHkWAf9H6brRVKD0676dtOS2YCXUAhMuUFxB1Wa
BNIKvik/d4igHHixb2sO79MP23ndC0lUH+83dJLRWOROSb7OJVhqHnjWsTO/8TFT
rx2so4Bb9LLMCI1XwDWLCgl8neEO1iRzFzcEA4Ra5HKYxMx+HUCdj5rKl16JlD3y
LYXm5dqmt96HgWuADhHfcxvE8mOsV7hRH2Z9ZrTM4cFk68ZLe/n/lhMpkAaGQzJS
kMfYvdsHwZup75GLTjzGFUvYnMn6CAWZu19uSzMnDBiIk+0QUqH0Dc7jpILZhRlU
NTtcutJJvYM0LTDOIvUHEqW2yv8s99TTGymaqoTAXbWSZUxwRpSRlg==
=rEec
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
