Cryptography-Digest Digest #77, Volume #12 Wed, 21 Jun 00 13:13:01 EDT
Contents:
Re: how to compare the securtity between ECC and RSA (Mark Wooding)
Re: Linear Feedback Shift Register *with* lock-up? (John Savard)
Re: how to compare the securtity between ECC and RSA ([EMAIL PROTECTED])
Re: how to compare the securtity between ECC and RSA (DJohn37050)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Lon Willett)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Cipher design a fading field? ("Trevor L. Jackson, III")
Re: Comments/analysis requested ([EMAIL PROTECTED])
Blum-Williams integer???? ("OTTO")
Try it. (None)
Question re: size of random number ([EMAIL PROTECTED])
Re: Comments/analysis requested (Runu Knips)
Re: Comments/analysis requested: stream cipher derived from hash function (SHA-1)
(Tim Tyler)
Standards for Internet Banking ([EMAIL PROTECTED])
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: AWFUL PUN (was: Why the golden ratio?) ("Pete Bartlett")
Re: Question re: size of random number (Mark Wooding)
PRFs and RC4 (David Hopwood)
Re: Variability of chaining modes of block ciphers (David Hopwood)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: how to compare the securtity between ECC and RSA
Date: 21 Jun 2000 10:57:14 GMT
kingtim <[EMAIL PROTECTED]> wrote:
> I know that ECC is more secure than RSA.
You know more than I do, then.
If, by this, you mean that, against publicly known attacks, a
cryptosystem based on the generalized discrete log problem in an
appropriately chosen elliptic curve over a finite field with a given key
length is stronger than a system based on the RSA problem /with the same
key length/, then I'd agree with you. If that's not what you mean then
I suggest you explain yourself more clearly.
> But I do not know how to do the comparsion.
It's not an easy comparison to make. See
http://www.cryptosavvy.com/cryptosizes.pdf
for one comparison of key sizes required for equivalent security, and
ftp://ftp.rsasecurity.com/pub/pdfs/bulletn13.pdf
for a different opinion. I've not made up my mind which of these I
trust more; neither can, I suspect, be taken as entirely impartial.
Read both and make your mind up.
Of course, key size for equivalent security isn't the only basis for
comparison. You could consider security for equivalent performance,
memory usage, implementation effort, patent licensing costs or any of a
wide variety of other factors.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: comp.theory,sci.math
Subject: Re: Linear Feedback Shift Register *with* lock-up?
Date: Wed, 21 Jun 2000 11:18:40 GMT
On 20 Jun 2000 18:19:09 GMT, [EMAIL PROTECTED] (Ponder)
wrote, in part:
>What I'm really looking for, though, is an LFSR that counts
>through 2^N values and then *does* get stuck in the last state.
An LFSR can't do that. But if you use nonlinear feedback, it is quite
possible.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: how to compare the securtity between ECC and RSA
Date: Wed, 21 Jun 2000 11:56:52 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
kingtim wrote:
> I know that ECC is more secure than RSA. But I do not know how to do the
> comparsion.
> king tim
comparison from http://www.users.globalnet.co.uk/~firstcut/pgpfaq.html :
Block RSA EC
Cipher Key Key
Keylength Length Length
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 512
and from http://www.Certicom.com/ecc/wecc4.htm :
Time to RSA/DSA ECC RSA/ECC
break in key size key size key size
MIPS years ratio
10 4 512 106 5 : 1
10 8 768 132 6 : 1
1011 1,024 160 7 : 1
1020 2,048 210 10 : 1
1078 21,000 600 35 : 1
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp.htm <-- PGP half-Plugin for Netscape
http://disastry.dhs.org/pegwit <-- Pegwit - simple ECC alternative for PGP
remove .NOSPAM.NET for email reply
=====BEGIN PGP SIGNATURE=====
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBOVCRPjBaTVEuJQxkEQJVrACg6426n50VL4iuitnZuMSTDgayOP0An1Zw
vqxwiVjlo0xPBob+KWk+tsFe
=rQk4
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: how to compare the securtity between ECC and RSA
Date: 21 Jun 2000 12:13:23 GMT
Also check out http://www.nist.gov/encryption for NIST's recommended elliptic
curves for the various AES key sizes. This is a STRONG endorsement by a
government organization that (at least for the curves specified) ECC is strong.
And of course, check out the white papers at http://www.certicom.com.
Don Johnson
------------------------------
From: Lon Willett <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Date: Wed, 21 Jun 2000 12:24:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In sci.crypt.random-numbers Lon Willett <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
>
[snip]
> : Interesting idea. Another thought is just to base it on the DLP,
> : without worrying about using asymmetric crypto per se. e.g. let P
be a
> : large prime, and G a primitive element mod P. Then, take the
sequence:
>
> : X[i+1] = G ^ X[i] mod P.
>
> : This generates a nice sequence of values in the range 1 .. P-1, and
is
> : not (easily) reversible. [...]
>
[snip]
> I feel suspiciously as though I'm unknowingly stepping on ground that
> has already been gone over with a fine toothcomb. I'd love to learn
> more about any existing work relating to building non-backtrackable
> RNGs using anything like this.
Me too. It seems like someone must have done some analysis of
sequences like the above.
> The remaining issue which it seems desirable to address is the
possibility
> of short cycles.
[snip rest]
Would something like:
X[i+1] = G ^ (i + X[i]) mod P
help any? Would it hurt? It seems like the lack of correlation
between the chaotic recursion, and the simple G^i multipliers might
help prevent short cycles. But I really don't understand the
structure here. I wish someone could point me at some applicable
results concerning this.
Cheers.
/Lon Willett <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 21 Jun 2000 12:37:47 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> To exploit the variability, the chaining mode is determined by the key
> or a separate 'key'.
Why is this better than using a good cipher with a slightly longer key
in a standard chaining mode?
-- [mdw]
------------------------------
Date: Wed, 21 Jun 2000 09:18:16 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cipher design a fading field?
"John A. Malley" wrote:
> John Savard wrote:
>
> > >"John A. Malley" wrote:
> > >> That immediately raises this question : Can we even encipher and (de)cipher
> > >> plaintext strings of a Turing-unrecognized language?
> >
>
> >
> > Thus, the question he (may have) *meant* to ask is: can one convey
> > useful information of a general sort (not counting, say, some types of
> > telemetry), which is complete in itself, not merely a cipher key for
> > transmitting a later message - in a language that can't be recognized
> > by a Turing machine.
> >
> > If that could be done, one's communications would be resistant to a
> > certain category of cryptanalysis.
>
> Mr. Savard, what an excellent question!
>
> I never reached that question because I'm still puzzled by the act of
> encipher/decipher a string from a Turing-unrecognized language.
>
> Here's where I get stuck:
>
> A language is Turing-recognizable if and only if it is generated by some
> grammar.
> Therefore a language that cannot be generated by a grammar is not
> Turing-recognizable - it's Turing-unrecognizable.
>
> Every Turing-computable function from strings to strings, or from
> numbers to numbers, is grammatically computable, or generated by some
> grammar. A cipher system (enciphering, deciphering) is a
> Turing-computable function from strings to strings, or from numbers to
> numbers. Therefore enciphering and deciphering are also grammatically
> computable.
>
> Assume a string from a Turing-unrecognizable language is enciphered.
> Decipher the ciphertext back into plaintext. This is the same as using
> a grammar (the deciphering) to generate the plaintext string. But, the
> plaintext string is from a language that is Turing-unrecognizable. There
> is no grammar that can generate plaintext strings of a
> Turing-unrecognizable language. We get a contradiction.
>
> So the assumption is wrong - we cannot encipher a string from a
> Turing-unrecognizable language and decipher it afterwards.
>
> Is this conclusion solid?
>
> Can we even encipher and decipher plaintext strings of a
> Turing-unrecognized language?
Hint: consider the length of a TU string. Can you decipher any message of that
length? Not if deciphering a message is an atomic act.
But deciphering a message is generally not an atomic act. Stream ciphers work on
characters and block ciphers work on, well, blocks. Due to their length these
elements are always TR.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments/analysis requested
Date: Wed, 21 Jun 2000 13:55:31 GMT
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
>
> If you want to discuss an algorithm, first translate it into
> a readable form, such as C, Pascal, or mathematical pseudocode,
> not in pseudoassembly where one has to first start tracking
> which register contains which value.
>
Runu,
Thanks for the reply. Since I don't usually write in C, I was hoping
that others could follow what I had translated from assembly. I guess
I'll have to break out the C manuals.<g>
Thanks, Wayne
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "OTTO" <[EMAIL PROTECTED]>
Subject: Blum-Williams integer????
Date: Wed, 21 Jun 2000 22:31:38 +0800
Dear ALL,
I have reads some paper about the cyptigraphy.....
I do not understand "Blum-Williams integer" ~~~
Somebody can help me~~~
Thanks,
OTTO
------------------------------
Subject: Try it.
From: None <[EMAIL PROTECTED]>
Date: Wed, 21 Jun 2000 08:25:29 -0700
This is a good encryption system. I even signed the NDA to
purchase it.
http://www.aasp.net/~speechfb
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Question re: size of random number
Date: Wed, 21 Jun 2000 15:22:14 GMT
Hi,
I'm puzzling through an implementation of a Diffie-Hellman
key exchange.
I've created my own large integer class, and things
were going well. Now, however, I'm a bit stuck.
I am not certain if I've understood the first fews
steps in DH correctly. Reading from Schneier[0], I must:
1) choose a random large integer x, and send
X = g^x mod n
For the values of g and n, I presume I might use
skip assigned numbers? Also, for the value of
x (not X, but x), I create a rather large random number.
I have 1024 digits for reasons related to efficient
memory use. But surely the size of x will affect the
strength of the key. Is there some minimal value I
might use? I'd like to have a better understanding
of the tensions in changing the digit length of x.
Any comments or insights would be useful. I am
trying to avoiding examining the source code of
others so that I have a good understanding of how
things work.
Thanks much.
[0] Bruce Schneier, Applied Cryptography, 2d ed., at p. 514
--
Bob
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 21 Jun 2000 17:33:01 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Comments/analysis requested
[EMAIL PROTECTED] wrote:
> Since I don't usually write in C, I was hoping
> that others could follow what I had translated from
> assembly. I guess I'll have to break out the C
> manuals.<g>
You don't need C. Any highlevel language or any pseudocode
notation would suffice. Just use some general notation such
as
for i in [1..16] do (
x := ~k[i] ^ p[i] ... (k[i] & 0xf) ... (p[i] & k[i]) ...
....)
That is FAR more readable than any assembly or pseudoassembly
listing, because in that I have always to keep track of all
these registers.
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Comments/analysis requested: stream cipher derived from hash function
(SHA-1)
Reply-To: [EMAIL PROTECTED]
Date: Wed, 21 Jun 2000 15:39:29 GMT
In sci.crypt.random-numbers Lon Willett <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> The remaining issue which it seems desirable to address is the
:> possibility of short cycles.
: [snip rest]
: Would something like:
: X[i+1] = G ^ (i + X[i]) mod P
: help any? [...]
I believe so.
[FWIW, I've been considering combining with a finite counter (instead of
an unbounded index, i)].
IMO, there /should/ be an approach something like this:
For a cycle of length L to arise, (for some L), X[i + L] must equal
X[i] (for all i > s), for some s.
If X[i + 1] = G ^ (i + X[i]) mod P, and X[i + L] = X[i],
we have X[i + L + 1] = G ^ (i + L + X[i]) mod P.
Since IIRC, G is a generator, the exponentiation produces a bijection
for values smaller than P this can only equal X[i + 1] [recall this equals
G ^ (i + X[i]) mod P] if L is zero - or P or greater - so we have
eliminated the possibility of cycles smaller than P - I believe.
This "proof" might have worked slightly better had I been considering
"X[i+1] = G ^ ((i + X[i]) mod P) mod P" - but hopefully the basic idea is
sound.
The only qualm I can see is that we can never throw the attacker off
tracking "i" without either some genuine entropy input, or introducing
the possibility of cycles at that point.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED]
Subject: Standards for Internet Banking
Date: Wed, 21 Jun 2000 16:04:59 GMT
Where can I find descriptions of standards for Internet Banking?
Does it even exist?
Regards,
Mads Rasmussen
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encryption on missing hard-drives
Date: Wed, 21 Jun 2000 16:39:40 GMT
Mack <[EMAIL PROTECTED]> wrote:
> b) some spy now has the
> codes to the PAL for nuclear
> weapons. or whatever was on
> the disks. since the information
> was only secret I doubt it was
> that important
The missing disks were field manuals for NEST (Nuclear Emergancy
Response Team). That is, they include schematics of most of the
world's nuclear weapons and instructions for safetly opening the case,
along with similar information.
The reason it's only secret is partly because it needs to be accesible
to NEST members, but also because the theory behind a nuclear device
is much more readily available than during say The Manhattan
Project. Given the wide proliferation of them, it's unclear how many
improvements you could squeeze off the American ones. I mean, they
probably have a much higher yield, and better guidance, but I wouldn't
want a bomb made in India falling in my backyard either!
Instructions for safe dissasembly are also less ominous than they
sound, since you would need a bomb to open to make use of them. That
implies either stealing a weapon, which is generally kept in
facilities slightly more secure, or intercepting one during delivery,
which is highly unlikely given the US delivers them by missile and
bomb exclusively.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: "Pete Bartlett" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: AWFUL PUN (was: Why the golden ratio?)
Date: Wed, 21 Jun 2000 17:45:40 +0100
"John Savard" <[EMAIL PROTECTED]> wrote in message
> On Mon, 19 Jun 2000 08:05:42 -0400, "G. A. Edgar"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Well, perhaps if you had meant G. H. Hardy we sould have got it.
>
> Actually, that's what I originally thought, but I had seen the other
> initials in an article on Ramanujan, and so I thought that perhaps G.
> H. Hardy was a mystery writer or something...or, perhaps I am all wet,
> and Ramanujan was discovered, and "A Mathematician's Apology" was
> written, by two different mathematicians (perhaps father and son).
> Somehow, I doubt that.
>
> John Savard (teneerf <-)
> http://www.ecn.ab.ca/~jsavard/
G.H.Hardy was my great-great-supervisor (i.e. one of my supervisor's
supervisor's supervisor.) I suppose that makes Ramanujan my
great-uncle-supervisor!
Pete
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Question re: size of random number
Date: 21 Jun 2000 16:46:01 GMT
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I've created my own large integer class, and things
> were going well. Now, however, I'm a bit stuck.
>
> I am not certain if I've understood the first fews
> steps in DH correctly. Reading from Schneier[0], I must:
>
> 1) choose a random large integer x, and send
>
> X = g^x mod n
>
> For the values of g and n, I presume I might use
> skip assigned numbers?
If you mean the numbers specified in the SKIP specification, then yes,
those will do.
There's something strange, though. The SKIP spec (available at
http://www.skip-vpn.org/spec/numbers.html for those following at home),
carefully explains where the prime numbers come from, but completely
neglects to describe the origin of the generators (which are all chosen
to be 2).
In fact, the generator for the 512-bit prime p_{512} actually generates
a subgroup of order (p_{512} - 1)/2 -- i.e., 2 is not primitive mod
p_{512} -- although it *is* primitive mod p_{2048}. Very strange.
If I were you, I'd use the element 4 as your generator, rather than 2,
since it's guaranteed to generate a subgroup of size (p - 1)/2 mod any
prime p where (p - 1)/2 is also prime. I don't recommend using
composite-order subgroups.
[Proof: Let p, q be prime, with p = 2 q + 1. To see that 4 has order q,
note that 4^q = 2^{2 q} = 1 (mod p) by Fermat's Little Theorem, so the
order of 4 must divide q, but q is prime.]
Then q \alpha = q \beta = 0 (mod p - 1).
Since q is a factor of p - 1, we can't just divide, but we can just take
the common factor out and say that \alpha = \beta = 0 (mod (p - 1)/q),
i.e., \alpha = k_a (p - 1)/q, \beta = k_b (p - 1)/q
> Also, for the value of x (not X, but x), I create a rather large
> random number. I have 1024 digits for reasons related to efficient
> memory use. But surely the size of x will affect the strength of the
> key. Is there some minimal value I might use? I'd like to have a
> better understanding of the tensions in changing the digit length of
> x.
In my scenario, I think you want to choose x uniformly from
(0, (p - 1)/2). When you get a answer Y from the other side, you should
verify that Y != 1, and that Y^{(p - 1)/2} = 1 (mod p) (i.e., that Y is
a member of the generated subgroup). This test is sufficient because
there is only one order-q subgroup of Z_p^*.
[Proof: Let p be prime. Let q be any factor of p - 1, and let g be a
generator of Z_p^* (i.e., g has order p - 1), and let a = g^\alpha and
b = g^\beta be elements of order q, mod p. Then \alpha = k_a (p - 1)/q,
for some k_a; and \beta = k_b (p - 1)/q. We must have k_a and k_b each
relatively prime to q. Then I can find k = k_b k_a^{-1} (mod q). Now
a^k = g^{k \alpha} = g^{k_b k_a^{-1} k_a (p - 1)/q} = g^{k_b (p - 1)/q}
= b (mod p). Hence a and b are in the same subgroup.]
Public key cryptography is a fiddly business and getting it right is
hard. (I've probably got some things wrong here, and some helpful
expert will correct me.)
-- [mdw]
------------------------------
Date: Wed, 21 Jun 2000 04:11:52 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: PRFs and RC4
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> "David A. Wagner" wrote:
>
> > No, RC4 is a pseudo-random generator G : key |--> output, not a
> > pseudo-random function F : (key,input) |--> output. As stated in my
> > comments above, a pseudo-random generator is insufficient; you need a
> > full pseudo-random function.
>
> Couldn't one (certainly pedantically) argue that G can be employed
> where F is used, since one can always use 'key||input' of F as 'key' of
> G?
That would be secure only if G were resistant to related-key attacks.
PRNGs are generally not designed to be usable as hash functions [*], so
it's not a particularly good idea to assume such resistance. Also, note
that there are some related-key attacks on RC4 in particular, for
example see:
J. Kelsey, B. Schneier, D. Wagner,
"Key-Schedule Cryptanalysis of 3-WAY, IDEA, G-DES, RC4, SAFER, and
Triple-DES",
Advances in Cryptology - Crypto '96 Proceedings, pp. 237-251.
Springer-Verlag, August 1996.
http://www.counterpane.com/key_schedule.html
I don't know whether RC4's key schedule weaknesses would be exploitable
when using it in the way suggested above, but it doesn't seem prudent to
assume that they wouldn't be.
[*] with some interesting exceptions such as Panama.
- --
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVAyMzkCAxeYt5gVAQE87ggAsfQtgOKYayQOYW1e1mDfbOx4PHU9JAle
1LSOdUGhDKqmQ74o1wQdNt8iZaRuKVrg3hgbW3JbMXqljVbAmgdyrHJCV1PNDtMm
4iRiLxChQRH7PqD71OMu2GlIPjR8QPEHPbuIIJJH7vA1+RAog6zkv4rM0Gd+emUK
XbbOfw631z6AUPrFnJ6xe0OUP035lTbvDPbo8Q+X8eHAwDNFvAtaIiHywsBeeIop
XWYcX0svJKDErAHLm2LCaE9/MB/03nvXDJ16dQjCUoeLnxkcgzDaEmBMRg4WAP9n
+4MwFWQ67iw7vAnqoHkiEZImzTegSelQzUlCLvw4Glf12BbHi4l61Q==
=7A5o
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 21 Jun 2000 04:55:50 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Variability of chaining modes of block ciphers
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
>
> The most popular block chaining mode seems to be CBC.
> There is also PBC which chains with plaintext blocks.
> One can also accumulate the previous blocks for doing the
> chaining and use plaintext as well as ciphertext for
> chaining. (I used this in one of my own designs.) By
> combinatorics this gives 8 variants. Obviously one can
> also use modular addition instead of xor and do some
> random rotations if one likes. I think that the variability
> of chaining modes could be advantageousy exploited such
> that the actual chanining mode used in a message has to be
> guessed by the opponent, thus re[n]dering his task much more
> difficult.
Definitely not a good idea. If even one of the possible modes
is weak, then some data may be exposed; in effect, the system is
only as secure as the weakest mode. Block cipher modes should be
chosen carefully for suitability in a particular application,
certainly not at random.
(Not to mention that it may be easy under some attack models to
determine which mode has been used - for example by observing the
effect of making changes to the ciphertext - regardless of whether
it is determined by a secret key.)
- --
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
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVA8aTkCAxeYt5gVAQFT8Qf/Z2YiFUgs8hKD/RxP94y9JTVh8E4aBSwC
5Vpe6a0/lMfpWWcQ9MU8k8Tw/koQACiXS/88Om8FxbAhDpqRVSocU0JdZKQaSlIw
XSpwM7MBkM96dXQGrVOWhJIyhehUu8Bk2AJmZf4gRCScmw3maKUGj0ILPOUy9qxb
M5C/pdYo2/PfQUeNqFa0Ej1bgv3xcqutU35pQu4VQ+GN6dMCDBjr+FnLX2Cb6viw
3BQF7eNNOSboDpaQlMRSXeHdbIDdPSmiXN4QnB8WdTXl1nmfDofIeeHi63BAfAJu
cXD4CCvNxNDBkbXAW3UK0YxtitZ+5s0xXKShuoOugysk+OoP4nUkRw==
=7R4a
=====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
******************************
