Cryptography-Digest Digest #708, Volume #11 Fri, 5 May 00 01:13:01 EDT
Contents:
Re: RC6 as a Feistel Cipher ("Scott Fluhrer")
Re: U-571 movie (OT) (Steve Rush)
Re: RC6 (tm) as a Feistel Cipher ("Scott Fluhrer")
Re: RC6 (tm) as a Feistel Cipher (Tom St Denis)
Re: Silly way of generating randm numbers? (Scott Nelson)
bigfloat slowly changes (Mike Rosing)
Re: GPS encryption turned off (Paul Rubin)
Re: GPS encryption turned off (Paul Rubin)
Re: Any good attorneys? (Joaquim Southby)
Re: Silly way of generating randm numbers? (Mike Oliver)
Re: U-571 movie (OT) (Joaquim Southby)
Re: RC6 as a Feistel Cipher ([EMAIL PROTECTED])
Re: Any good attorneys? ("Trevor L. Jackson, III")
Re: Any good attorneys? (David Hopwood)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC6 as a Feistel Cipher
Date: Thu, 4 May 2000 19:03:49 -0700
John Myre <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I wrote:
> >
> > "David A. Wagner" wrote:
> > >
> <snip>
> > >
> > > Suppose a cipher may be written as a composition of "rounds",
> > > where each round encrypts the input (L,R) to the output (R,L+f(R))
> > > for some key-dependent function f and some group operation +
> > > (both of which may possibly depend on the round number).
> > >
> > > Then the cipher is a Feistel cipher.
> <snip>
> > (2) Can f or + be round-dependant?
>
> Duh. It would help if I could read.
>
> Anyway, I have another question. Clearly + doesn't actually
> have to be a group operation, it just needs to have an inverse,
> to create a cipher. That is, f(R) doesn't even have to belong
> to the same set as L and R; we just need to be able to compute
> (L+f(R))-f(R) and get L; L+R or f(R)+L don't need to be defined.
>
> So what is the limitation, if any, on + for "Feistalness"?
Well, the really nifty thing about a Feistel network is that, outside of key
scheduling, encryption is the same as decryption. So, if you want to keep
that property, then if you use '+' in round i, you just use '-' in round
N-i+1.
If you don't care (that is, you don't mind separate encrypt and decrypt
routines/hardware/whatever), then it doesn't really matter.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (Steve Rush)
Subject: Re: U-571 movie (OT)
Date: 05 May 2000 02:40:51 GMT
>Hello, I believe that one of failings of the original Enigma code books was
>the codes were "too" random. For example if the wheel settings for the day
>were 1-3-5, the next day the wheel settings would never have the same wheel
>in the same place e.g. the settings would not be 1-5-4 because wheel 1 was
>in the same place.
Several counterexamples have been posted. Perhaps you were thinking of the
"Nothing encrypts as itself." rule that did apply to Enigma. A given plaintext
letter would never result in the same letter in the cyphertext, because the
circuit representing a keystroke went into the rotor stack at one contact, and
came out at another contact. This reduced the number of possible plaintext ->
cyphertext mappings. Add a little known plaintext (called a "crib" at
Bletchley Park") and the cryptanalysis problem becomes tractable without
electronic computers, if you have some people like Alan Turing to supply the
inspiration, and a big enough budget to hire the perspiration. There were
crossword-puzzle contests in Britain in those days whose winners got prizes
that they didn't expect, in the form of government jobs.
==========================================================================
==============
If it's spam, it's a scam. Don't do business with Net abusers.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: Thu, 4 May 2000 19:28:28 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Mok-Kong Shen wrote:
> >
> > Tom St Denis wrote:
> >
> > > At
> > >
> > > http://24.42.86.123/rc6a.c you can see my idea for a pure feistel RC6.
> > >
> >
> > Would I be asking for too much, if I request you to post a short
> > abstract of your work to the group? It would facilitate discussions.
> > (A purely personal reason which certainly doesn't count is that I
> > don't like very much to switch between the newsreader and the
> > web browser.) Thanks.
>
> Basically My modification works like this (this is just a round)...
>
> input = (a, b, c, d)
> t = F(c); a = ROTL(a ^ d, t) + S[4*r+4];
> t = F(d); b = ROTL(b ^ c, t) + S[4*r+5];
> t = F(a); c = ROTL(c ^ b, t) + S[4*r+6];
> t = F(b); d = ROTL(d ^ a, t) + S[4*r+7];
>
> Where F() is essentially four 8x5 sboxes xor'd together. It's a pure
> feistel structure of sorts, where each 'input' portion effects the
> rotation of another word, or effects the plaintext using 'xor'.
>
> It has very quick avalanche (only needs 2 rounds) since a change in any
> plaintext will most likely change the rotation of two words (at the
> most) and this change will propate into the other round very quickly.
>
> The sboxes are designed to have linear traits bounded to +- 28, and the
> max value for any xor pair is 24. The sboxes also satisfy SAC (see the
> new sboxgen.c I posted). The sboxes are designed this way to make their
> cryptanalysis a bit tougher (i.e predicting the rotations becomes much
> harder).
>
> I did a similar modification to RC5 to increase the avalanche big time.
>
> ---
>
> Any thoughts?
An obvious problem I see is that the *only* diffusion between (A,D) and
(B,C) is the shifts. If I can find a pair (A,B,C,D) and (A',B,C,D') that
has the property (truncated differential) such that: every time line 2 and
line 3 are executed, the t is the same between the two encryptions, then I
known that, after encryption, the two encryptions will output the same B and
C. By the birthday paradox, I should be able to find such a pair using
about 2**(5*R) chosen plaintexts, where R is the number of rounds. Having
found such a pair, I should be able to deduce nontrivial information about
the expanded keys used in the starting/ending round.
So, if you want this to be secure even if the attacker can pick 2**64 chosen
plaintexts, you would need R>=13. If you allow the attacker 2**128 known
distinct plaintexts (they don't have to be chosen :-), then R>=19 (not 26,
because the attacker has to work with different (B,C) pairs, and so the
number of collisions is not squared).
Obvious extension of this is to look for places where this truncated
differential occurs for R-1 rounds, and then guess the subkey used in the
Rth round. This might be able to allow you to attack another round or two.
--
poncho
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC6 (tm) as a Feistel Cipher
Date: Fri, 05 May 2000 02:57:33 GMT
Scott Fluhrer wrote:
> > Any thoughts?
> An obvious problem I see is that the *only* diffusion between (A,D) and
> (B,C) is the shifts. If I can find a pair (A,B,C,D) and (A',B,C,D') that
> has the property (truncated differential) such that: every time line 2 and
> line 3 are executed, the t is the same between the two encryptions, then I
> known that, after encryption, the two encryptions will output the same B and
> C. By the birthday paradox, I should be able to find such a pair using
> about 2**(5*R) chosen plaintexts, where R is the number of rounds. Having
> found such a pair, I should be able to deduce nontrivial information about
> the expanded keys used in the starting/ending round.
This is assuming of course that the rotation doesn't change in any other
step. I will agree that you can fix the rotations in the first round
trivially. However as you enter into the second round getting fixed 't'
values for any pair will be more difficult.
Obviously there is some work todo because the F function only uses 5+32
of the 64 bits supplied. One other idea is to compress the two
registers downto 5 bits (i.e eight 8x5 sboxes) and also use the two in
the other part... so you get
t = F(C, D); A = ((A xor G(D, C)) <<< t) + S[4r+0];
t = F(D, C); B = ((B xor G(C, D)) <<< t) + S[4r+1];
...
Which would make it considerably slower but also modify the entire word
based on the two inputs not just one.
> So, if you want this to be secure even if the attacker can pick 2**64 chosen
> plaintexts, you would need R>=13. If you allow the attacker 2**128 known
> distinct plaintexts (they don't have to be chosen :-), then R>=19 (not 26,
> because the attacker has to work with different (B,C) pairs, and so the
> number of collisions is not squared).
>
> Obvious extension of this is to look for places where this truncated
> differential occurs for R-1 rounds, and then guess the subkey used in the
> Rth round. This might be able to allow you to attack another round or two.
Yea, true... ouch
Tom
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.crypt,sci.math.random-numbers
Subject: Re: Silly way of generating randm numbers?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 05 May 2000 03:19:40 GMT
On Wed, 03 May 2000, Julio César <[EMAIL PROTECTED]> wrote:
[snip]
>I dont know if this could help, but pi is in no way random.
>
On the contrary, PI is random in many ways.
It's just not random in _all_ ways.
Specifically, individual digits of PI are believed to be
normal and unbiased to an arbitrary precision.
PI does however fail to be unpredictable or uncompressible,
so it falls short of the "general" definitions, both
mathematic and cryptographic.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: bigfloat slowly changes
Date: Fri, 05 May 2000 03:47:49 GMT
I've added a few routines to the bigfloat stuff
(http://www.terracom.net/~eresrch/float)
It now computes chebyshev polynomials and bessel functions. The
combination will allow
me to create exp and trig functions. I've also fixed a few minor bugs
in the bigfloat.c
routine as well as added this stuff, but I'm sure there are more. If
there is anyone
bored to tears you're welcome to help find them :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: GPS encryption turned off
Date: 5 May 2000 03:52:01 GMT
In article <[EMAIL PROTECTED]>, Nicol So <see.signature> wrote:
>> ... Anyway, sooner or later
>> a receiver will be captured or lost and *not* reported missing/gone.
>> The current rekeying system (keys are encapsulated in secure hardware
>> modules which have to be physically replaced in the receiver) avoids
>> that problem and I thought that was part of the intention.
>
>To perform rekeying using security modules, you need to have all
>authorized devices accounted for anyway.
Yes, that's the point. The rekeying facility has to actually have the
authorized device IN ITS HANDS in order to rekey it, and maybe can do
some type of cryptographic authentication with the internal module.
With OTAR, if an attacker gets hold of a unit for long enough to
extract its internal keys, but somehow keeps the unit on the
whitelist, then the attacker gets all the key updates over the air.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: sci.geo.satellite-nav
Subject: Re: GPS encryption turned off
Date: 5 May 2000 04:08:56 GMT
[sci.geo.satellite-nav added to newsgroups. Yes, we already know that
the P signal is still encrypted.]
Doug Stell <[EMAIL PROTECTED]> wrote:
>>>Over the air rekey: in case a GI leaves a military receiver in a bar].
>>Interesting. Are you saying they're going to rekey all the receivers
>>*except* the one left in the bar? How?!
>
>Yes, OTAR. The compromised receiver will simply revert to being an
>inaccurate one in a short time. OTAR is done all the time in military crypto.
OTAR still seems worrisome. Say the attacker "borrows" a live receiver
(e.g. by bribing or seducing the GI in the bar) for long enough to
extract the algorithm and internal keys, and then gives the unit back
to the GI so it stays on the whitelist. (If necessary, the unit given
back to the GI is a new one that's been newly programmed with the old
unit's keys, since the old unit has been physically trashed by the key
extraction process). Now the attacker gets all the key updates which
s/he can propagate into other receivers. The entire security seems
to rest on the physical tamper resistance of the handheld receiver.
That seems like a serious vulnerability to me.
>Knowing the algorithm would be of no help, as any cryptographer would
>assume.
Once the algorithm is known, it's just a matter of getting keys from
a live unit.
>Also, the algorithm will be highly protected by physical means,
>designed to prevent reverse engineering. Any attempt to access it
>would destroy it before you get to it. To keep the algorithm away
>from the GPS manufacturer, the operational code is squirted in by a
>single facilitty AFTER the GPS unit is built, physically secure and
>tested.
I can't bring myself to believe the tamper resistant circuitry will
stay secure, especially over a long period of technology advances.
Remember the Clipper chip? It was also supposed to be secure, but
from what I heard, it was reverse engineered in relatively short order.
>Personally and without any substantiating information, I believe that
>this new approach is being put into place due to a compromise of the
>keys for the current system. For satelites, it was common to store a
>decade of Red keys in the bird, under the belief that they would be
>physically secure in a geo orbit. There was a newpaper article about
>another nation launching a satelite for a US party and having to blow
>up the rocket. When the bird was recovered, the GPS was missing.
>Blowing it up may have been a cover for stealing the GPS and its keys.
Yes, I remember that incident too (Chinese rocket), though I didn't
realize that it was a PPS-capable GPS receiver that had gotten nabbed.
I still wonder a thing like that was doing aboard a civilian
communications satellite. Also, *that's* a situation where OTAR makes
more sense, since there's 2-way communication with the satellite,
so it can authenticate itself to the ground station, etc.
I also wouldn't bet on nobody (i.e. space-capable foreign govt) being
able to snag a satellite out of geo orbit in the next decade.
>> Surely this has already been done (I mean by foreign
>>intelligence agencies, not sci.crypt nerds) for the existing algorithm.
>
>I am not sure if it has been fielded yet. By the way, the new scheme
>is called SAASM.
What does SAASM stand for? Thanks.
Btw, do you work on GPS? You've got some good info.
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Date: 5 May 2000 04:13:25 GMT
In article <[EMAIL PROTECTED]> Mok-Kong Shen,
[EMAIL PROTECTED] writes:
>But, as far as I could make out of the discussions up till the moment,
>the patent is NOT in effect in Canada. If this is indeed true, there is
>no reason to comply with the menacing letter and every reason to
>contradict or ignore. If I were the manager of a supermarket in
>Germany and some fundamentalist wrote me that it is a crime in
>Saudi to sell alcoholic drinks, do you think I am going to remove
>all the delicious bottles from the shelves?
>
Bad analogy. It's legal to sell alcohol in Germany. However, if you
were the manager of a German firm that is selling alcoholic drinks in
Saudi Arabia, you would be liable under their laws. It's where you do
*business* that seems to be the sticking point.
If Tom is distributing his product in some country in which the patent is
in effect, he must observe and answer to the patent laws of that country.
------------------------------
From: Mike Oliver <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Silly way of generating randm numbers?
Date: Thu, 04 May 2000 21:22:47 -0700
Richard Heathfield wrote:
>
> Mike Oliver wrote:
> But I can think of at
> > least one "mathematical test for randomness" that it doesn't
> > pass. Specifically, the linear correlation between the digits
> > of a random number, and the digits of pi, should approach zero
> > as the number of digits considered goes to infinity.
>
> [snips]
> If result is false, pi can't be random, because its digits' linear
> correlation with those of some_known_random_number doesn't approach
> zero. Now, how do we establish some_known_random_number? Well, since pi
> has passed loads of tests for randomness, we can use that.
>
> result = test_for_randomness(&pi, &some_known_random_number);
>
> Hey, it returns false. So some_known_random_number isn't random after
> all.
>
> Flaw?
Consider the question in a little more generality. I argue that a
"test for randomness" has the following form: Take a property P
that is true with probability 1 for a randomly-chosen real (between
0 and 1, say). Then a real r passes the test just in case r
has property P.
Now a real r might be said to be "random" if r passes *every*
test for randomness, in the above sense. But if we place no
limits on the properties to be considered, then as you observe,
no number is random; given r, consider the property P(s) which
is true just in case s != r. Clearly P has probability 1, but
r does not have P.
But if we can limit ourselves to some *countable* collection
of P's, then there *are* random numbers (because the intersection
of countably many conull sets is conull).
The obvious framework in which to choose such a collection of
properties is effective descriptive set theory. So let's start
from the bottom: Suppose we said you're random if you're
in every conull Pi^0_1 (lightface) set. Well, that's not
really saying much; the complement of a conull Pi^0_1 set
is a null open set, and the only open set which is null is
the empty set. Sigma^0_1 is a little better, but not much;
the complement of a conull Sigma^0_1 set is a null Pi^0_1
(i.e. effectively closed) set. But such a set must be nowhere
dense (if it were somewhere dense and closed, it would have
nonzero measure). That is, if you're in every *comeager*
Sigma^0_1 set, then you're also in every *conull* one.
That means that if we limit ourselves to Sigma^0_1 properties
whe can't distinguish between Cohen reals and random reals.
But Cohen reals have very definite "nonrandom" properties
(e.g. the density of 7's in the first n digits is arbitrarily
close to 1 arbitrarily often as n --> oo).
Pi^0_2 is really no different from Sigma^0_1 -- if r is
in every conull Sigma^0_1 set, then let A be a conull Pi^0_2
set. Then A is the intersection of countably many (necessarily
conull) Sigma^0_1 sets, so r is in each of these, so r is in A.
So we really have to start with Sigma^0_2. By the same argument
as the previous paragraph, being in every conull Sigma^0_2 set
is the same as being in every conull Pi^0_3 set. Pi^0_3 should
be enough to guarantee that, say, the number is normal.
I conjecture that this kind of randomness -- being in every
conull Sigma^0_2 set of reals -- is equivalent to Knuth's
definition R6 in "Seminumerical Algorithms". Does anyone
know if this is true? Does the class of "random" numbers
continue to get smaller as you go up the arithmetical hierarchy?
------------------------------
From: Joaquim Southby <[EMAIL PROTECTED]>
Subject: Re: U-571 movie (OT)
Date: 5 May 2000 04:24:46 GMT
In article <[EMAIL PROTECTED]> Steve Rush,
[EMAIL PROTECTED] writes:
>>Hello, I believe that one of failings of the original Enigma code books was
>>the codes were "too" random. For example if the wheel settings for the day
>>were 1-3-5, the next day the wheel settings would never have the same wheel
>>in the same place e.g. the settings would not be 1-5-4 because wheel 1 was
>>in the same place.
>
>Several counterexamples have been posted. Perhaps you were thinking of the
>"Nothing encrypts as itself." rule that did apply to Enigma.
>
He's partly correct and thinking of the right thing. From David Kahn's
"Seizing the Enigma":
"The air force never used the same rotor in the same position two days in
a row, except perhaps from one keying period to the next."
The Luftwaffe enforced this rule; the Kriegsmarine did not.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC6 as a Feistel Cipher
Date: Fri, 05 May 2000 04:22:50 GMT
In article <[EMAIL PROTECTED]>,
Francois Grieu <[EMAIL PROTECTED]> wrote:
> (..) try PROVING that RC6 is a Feistel Cipher (..)
>
> The RC6 round function goes like
>
> t = (B*(2*B+1)) <<< 5
> u = (D*(2*D+1)) <<< 5
> A = ((A ^ t) <<< u) + S[2*i]
> C = ((C ^ u) <<< t) + S[2*i+1]
> (A; B; C; D) = (B; C; D; A)
...
>
> Question: is there a simple explicit transformation of RC6 into
> a Feistel Cipher ?
>
> Francois Grieu
>
Hey sci.crypt,
Let me give it a try.
Let the F(B,D) function be
t = (B*(2*B+1)) <<< 5
u = (D*(2*D+1)) <<< 5
Instead of XOR, we use an unusual combination for the left and right
halves. Feistel ciphers do not -have- to use XOR, any other invertible
transform should do. This transform appears to be invertible.
A = ((A ^ t) <<< u)
C = ((C ^ u) <<< t)
AC = AC <<< 32 // due to the reorder of AC DB
Let this transform be denoted by ^^
The key is added -before- the round. The first round key is defined to
be the zero key, perhaps it could be the whitening key. Note the order
is changed due to the rotation of AC to BD instead of AC to BD.
B+= S[2*i+1]
D+= S[2*i]
So,then in Feistel form
L=AC R= BD
L1=R R1 = F(R+S)^^L // zero key used here
L2=R1 R2 = F(R1+S)^^L1 // first round key
LN=RN-1 RN= F(RN-1+S)^^LN-1
A little psuedo code
in = ABCD;
right = BD; // 64-bit right[0] = D
left = AC; // left[0] = C
For i = 0 to rounds
{
tmp = right + key[i]; // 64 bit keykey[0] = 0, reorder keys
t = (tmp[1]*(2*tmp[1]+1)) <<< 5;
u = (tmp[0]*(2*tmp[0]+1)) <<< 5;
// flip so AC goes to DB
newRight[1] = ((left[0] ^u) <<< t)
newRight[0] = ((left[1] ^t) <<< u)
left = right;
right = newRight;
}
// reorder to A,B,C,D
out = left[1] | right[1] | left[0] | right[0];
Looks like a good start most likely there are a few bugs. Anybody care
to finish it?
I wonder if any new attacks could be developed on a Feistel version of
RC6, hmm?
--Matthew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 05 May 2000 00:45:22 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Any good attorneys?
Joaquim Southby wrote:
> If Tom is distributing his product in some country in which the patent is
> in effect, he must observe and answer to the patent laws of that country.
While this statement is correct it really begs the question. If Tom's
products were distributed for a fee we could "follow the money" to determine
the patent jurisdictions in which his software is distributed. Since it's
free, and the mechanism of distributions is passive (internet) as opposed to
active (e.g., junk mail CD's like AOL's) the definition of "distributing" is
subject to considerable dispute.
However, users of Tom's software each have a patent jurisdiction, and so there
can be no dispute over the propriety of use for an individual user. Thus it
would be sensible for Tom to provide documentation as to which jurisdictions
demand that people not use his software.
------------------------------
Date: Fri, 05 May 2000 05:35:44 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Any good attorneys?
=====BEGIN PGP SIGNED MESSAGE=====
Bryan Olson wrote:
> Tom St Denis wrote:
>
> > I still have some reading todo (I know basic EG right now) but I am
> > pretty sure you can get by with smaller ciphertext by using
> > sub-groups...
Using a subgroup (of GF(p), say) improves efficiency, but it doesn't
decrease the size of the ciphertext. The value g^k (and for the
multiplicative scheme, M*y^k), are of the same length as p,
regardless of the size of the subgroup.
> > I would appreciate any info possible wrt to this. As I want to get
> > CB back out there.
For non-interactive Diffie-Hellman in general, the output length is
(length of p) + (length of symmetric algorithm ciphertext), where the
latter is usually negligably larger than the plaintext (perhaps with
an IV and padding, if a block cipher is used).
DHAES increases that by (length of MAC result), but that's necessary
to achieve the non-malleability and security against chosen ciphertext
attacks.
To minimise the ciphertext length, try DHAES over a cyclic subgroup of
an elliptic curve group, using point compression (see the P1363 standard)
to represent g^k.
> Yes, you can work in a sub-group of large prime order, just
> as DSA does. For example, we might use a sub-group of order
> q where q is 256 bits, and a prime modulus p = q*d+1 where d
> is 1792 bits, and p is 2048 bits. (Constructing q so that
> d/2 is prime should avoid another potential pitfall.)
Yes, this is sound advice, and consistent with:
Paul C. van Oorschot, Michael J. Wiener,
"On Diffie-Hellman Key Agreement with Short Exponents,"
Advances in Cryptology - EuroCrypt '96.
> I have not read the paper David Hopwood referred to, but it
> sounds promising.
It's well worth reading (also as an example of security proofs using
the "concrete security" approach, which I'm a big fan of).
> Though the Diffie-Hellman patent has expired, I don't know
> the patent status of small-subgroup methods.
AFAIK there is no patent covering them in general (other specific
discrete-log-based schemes using subgroups may be patented, but not
Diffie-Hellman or DHAES).
> (And I post my own views, not my employer's.)
I have the luxury of being able to post my employer's views, since
I'm self-employed. They still do not constitute legal advice, of course.
- --
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
iQEVAwUBORJPWjkCAxeYt5gVAQFN5Af9F71JiaKgcPo/0m6YG4upWnafIu7QB/2a
/F+q7zvMXsLM4yxTJJJvLb1hX5pkkHhkqHZRd+3/zpNmxc78diGeLEiX16r1DLha
kMsBxSy7eY1QBNatab4f4rD8fdzmD46uMgpvdsdgcYiaQfjgAXtqUPIRkUGMtEPd
efjoLmf1jMYejzQIat0+kVWQo6IKzMkzk307WT6CZCZ/bkruBfRnklJdEdmkxWnp
TW9au1KArruxdtU0fgovH1ZsYPOrBUqx5mRNtUlmA+4ZlKqu5aE+sQFv/Kt+dJHV
BTTsEkM9i7uL1COSK3Cp2xs7tesfj5OYPo8hY8fZc0IgYbohKpZQAw==
=ELgv
=====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
******************************
