Cryptography-Digest Digest #396, Volume #14 Sun, 20 May 01 13:13:00 EDT
Contents:
Re: What about SDD? (David Wagner)
Re: What about SDD? ("Harris Georgiou")
Re: Avoiding RSA padding altogether? (D. J. Bernstein)
Re: Avoiding RSA padding altogether? ("Tom St Denis")
Re: What about SDD? (Mok-Kong Shen)
Re: Avoiding RSA padding altogether? ("Tom St Denis")
Re: What about SDD? (Mok-Kong Shen)
Re: TC15a SAC Analysis ("Scott Fluhrer")
Re: TC15a SAC Analysis ("Tom St Denis")
Re: TC15a cryptanalysis ("Scott Fluhrer")
Re: OFF-topic by now - UK crime statistics (was Re: Best, ("Trevor L. Jackson,
III")
Re: People with x86 cpus (please reply) (Martin Schultz)
Re: TC15a cryptanalysis ("Tom St Denis")
Re: People with x86 cpus (please reply) ("Tom St Denis")
A difficult cryptogram (daniel gerard mcgrath)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: What about SDD?
Date: 20 May 2001 14:12:16 GMT
Harris Georgiou wrote:
>� David Wagner <[EMAIL PROTECTED]> wrote:
>> A simple
>> version goes like this: At time t, use the t-th output of a keystream
>> generator to pick an unpredictable frequency f_t, and transmit the t-th
>> chunk of data on f_t.
>
>It's not necessary to have frequency-skipping model.
Sure, this was just an example. You can use the same idea in many
ways: e.g., spread-spectrum rather than frequency-hopping, or hopping
or spreading in the time domain rather than the frequency domain.
>My guess is that a secure comms layers can be constructed much
>like the SSL, in order to achieve (according to R.Rivest) confidentiality
>though message authentication between multiplexed, chaffed and noisy
>channels.
But what's the benefit of this over standard SSL? I can't see any
(except in the case where crypto is hard to deploy and you want to
increase the cost of eavesdropping without modifying legacy applications,
which motivates the example I gave of doing this transparently without
support from, or even knowledge of, the receiver.)
>Encryption can keep away and intruder from keyrings
>and files, but the intruder always knows the exact location of them.
But why is it bad, if the intruder can know the location of them?
What is the security property you are trying to achieve? If you're
just trying to prevent the attacker from reading your traffic, it
seems that today's cryptosystems provide an adequate level of security
against this threat in most scenarios. Am I missing something?
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Sun, 20 May 2001 17:33:13 +0300
� David Wagner <[EMAIL PROTECTED]> ������ ��� ������ ���������:
9e8jc0$5jh$[EMAIL PROTECTED]
> Harris Georgiou wrote:
> >
> >My guess is that a secure comms layers can be constructed much
> >like the SSL, in order to achieve (according to R.Rivest) confidentiality
> >though message authentication between multiplexed, chaffed and noisy
> >channels.
>
> But what's the benefit of this over standard SSL? I can't see any
> (except in the case where crypto is hard to deploy and you want to
> increase the cost of eavesdropping without modifying legacy applications,
> which motivates the example I gave of doing this transparently without
> support from, or even knowledge of, the receiver.)
As R.Rivest notes, message authentication between the two parts does permit
each of them being able to distinguish bogus chatter from real traffic.
Multiplexing some channels this way can be sufficient for any satellite comm
without ANY kind of encryption, even without the two ends knowing or taking
any kind of security measures. This can be used in combination with SSL, and
in constrast to SSL it does not depend on the strength of any key or
encryption scheme, although under certain conditions it can provide the same
level of confidentiality (I guess).
> >Encryption can keep away and intruder from keyrings
> >and files, but the intruder always knows the exact location of them.
>
> But why is it bad, if the intruder can know the location of them?
> What is the security property you are trying to achieve? If you're
> just trying to prevent the attacker from reading your traffic, it
> seems that today's cryptosystems provide an adequate level of security
> against this threat in most scenarios. Am I missing something?
One famous weakness of the early Unix systems was the /etc/passwd file,
where anyone could get the accounts and their (hashed) passwords. Imagine
now, given that storage capacity is far less important than security, this
file being some gigabytes in size: who would try to discover some 100's of
useful lines of data in all this junk? Besides, why make it easy for an
attacker and show what the ciphertext is? Traffic analysis cannot be denied
(at least not without overloading the network with huge amounts of junk
packets), but I think secure storage can greatly be improved using some kind
of (ciphertext) data spreading.
Of course, I here state my thoughts and questions, and I 'm just trying to
evaluate the value if such techniques.
Cheers :-)
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Avoiding RSA padding altogether?
Date: 20 May 2001 14:51:53 GMT
Rabin introduced this system---a signature of m is a random r and a
square root of H(r,m)---in his famous 1979 tech report on signatures.
I often wonder if anybody else has actually read this report; Rabin
doesn't get nearly enough credit for all the great ideas in there.
See http://cr.yp.to/papers.html#sigs for a security analysis.
---Dan
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Avoiding RSA padding altogether?
Date: Sun, 20 May 2001 15:22:45 GMT
"D. J. Bernstein" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Rabin introduced this system---a signature of m is a random r and a
> square root of H(r,m)---in his famous 1979 tech report on signatures.
> I often wonder if anybody else has actually read this report; Rabin
> doesn't get nearly enough credit for all the great ideas in there.
>
> See http://cr.yp.to/papers.html#sigs for a security analysis.
Wouldn't a Rabin signature just be based on the fact that you can take roots
modulo a composite?
It would be weak if you could trick the user into giving two distinct roots
(i.e x and y such that x^2 = y^2 mod N) but other than that I can't see a
way to break it using trivial DoS factoring.
I imagine you would want to pad the signature so the number doesn't have
roots in Z. I.e if you signed M=65536 I could fake being you by saying Aha!
256 is a root. But if you pad that with zeroes you get some huge 1000 bit
number which is not a perfect square in Z.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Sun, 20 May 2001 17:45:01 +0200
Harris Georgiou wrote:
>
> I've done some research and I found it: broad-spectrum comms are really
> referred to as UWB (Ultra Wide Band) communications. The general idea is
> that, while normal comms use some band range to do some form of modulation
> (AM, FM, etc) in order to propagate a signal, in UWB the whole available
> spectrum is used to carry teh signal without any kind of modulation. The
> (digital) signal is broadcasted as ultra-narrow pulses much like the Morse
> code (bit sequences), which in fact generates an ultra-wide frequency
> spectrum. To avoid interference with current systems the power used is very
> low so that the actual signal appears as white noise on normal
> communications. The problem is that only one such system can be used at the
> same area and it's power spectrum should be low enough to avoid problems
> with normal modulation schemes. This technique has actually been on the
> drawing board of many communications companies but due to the possibility of
> interference with other radio comm systems only recently it has been
> approoved for further testing and only for applications covering areas 100m
> at most (internal building comms, wireless LANs, etc). Currently, the
> proposed cellular system that uses this technology is known as W-CDMA.
> "Scientific American" has published an article regarding 3rd generation
> cellphone networks and has many details about these issues.
It is my humble opinion that one probably need not employ
such sophisticated techniques, which for people with poor
knowledge in EE like me is difficult to designed is very
simple (in fact trivial) and clear-cut.
>
> The bit-level model you are proposing is interesting, although I do not
> fully understand how the message is restored/extracted correctly on the
> other side of the line. However, it is much similar to what I've thought,
> only mine works on byte-level and has a PRNG run-length offsets table as a
> (private) key. The important thing here is what R. Rivest addresses in his
> small article in "Chaffing and Winnowing"
> (http://theory.lcs.mit.edu/~rivest/chaffing.txt), that is how to easily
> achieve confidentiality without using encryption. Given the exponentially
> growing capacity in storage and communications over time, I think gives a
> whole new area of interest in secure storage and exchange of sensitive data.
> Using certification and authentication techniques, or huge PRNG-based
> distributions, it is possible to ensure confidentiality by means of
> information distribution (SDD) rather than hiding (stego) or sealing
> (crypto). I don't think it is a coincidence that NSA and other similar
> organizations around the world keep research studies regarding information
> statistics to cryptanalysis still classified back even to WW-II (see FAQ).
>
> I would really value some comments from the experts on this.
The PRNG has a secret seed shared by the communication
partners. Hence both partners use the same pseudo-random
numbers (for encryption and decryption).
BTW, if you are interested in chaffing and winnowing,
I happen to have a short note on my web page on that
topic containing some perhaps heretic views of mine.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Avoiding RSA padding altogether?
Date: Sun, 20 May 2001 15:46:44 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:9jRN6.144458$[EMAIL PROTECTED]...
>
> "D. J. Bernstein" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Rabin introduced this system---a signature of m is a random r and a
> > square root of H(r,m)---in his famous 1979 tech report on signatures.
> > I often wonder if anybody else has actually read this report; Rabin
> > doesn't get nearly enough credit for all the great ideas in there.
> >
> > See http://cr.yp.to/papers.html#sigs for a security analysis.
>
> Wouldn't a Rabin signature just be based on the fact that you can take
roots
> modulo a composite?
>
> It would be weak if you could trick the user into giving two distinct
roots
> (i.e x and y such that x^2 = y^2 mod N) but other than that I can't see a
> way to break it using trivial DoS factoring.
>
> I imagine you would want to pad the signature so the number doesn't have
> roots in Z. I.e if you signed M=65536 I could fake being you by saying
Aha!
> 256 is a root. But if you pad that with zeroes you get some huge 1000 bit
> number which is not a perfect square in Z.
I was reading Knuths 2nd vol today (and why not? geez I need a hobby) and I
found that all numbers that end with o1 where o is an odd digit are not
perfect squares. So to simplify the Rabin signature into something that is
provably as hard as factoring simply do this.
N is the blum integer. M is the message you wish to sign (must be less than
N/100)
1. Multiply M by 100 and add 11. I.e M = 100M + 11
2. Find the a single square root of M, make sure your algorithm is
deterministic such that it always reveals the same root given the same M
3. Give the user the root of M called L. They can verify that in fact L^2
mod N = M, since M is not a perfect square they must find a root modulo N
(and not simply in Z).
The user can verify that in fact the two littler digits are 11 by doing L
mod 11 (or (L -11 / 100) should have no remainder and then check L.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What about SDD?
Date: Sun, 20 May 2001 17:56:45 +0200
Mok-Kong Shen wrote:
>
[snip]
> It is my humble opinion that one probably need not employ
> such sophisticated techniques, which for people with poor
> knowledge in EE like me is difficult to designed is very
> simple (in fact trivial) and clear-cut.
Sorry, some words got lost in the above paragraph. Read
instead:
It is my humble opinion that one probably need not employ
such sophisticated techniques, which for people with poor
knowledge in EE like me is difficult to apply in design
in right ways. The scheme I designed and mentioned previously
is very simple (in fact trivial) and clear-cut.
M. K. Shen
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: TC15a SAC Analysis
Date: Sun, 20 May 2001 09:14:27 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:C2NN6.143056$[EMAIL PROTECTED]...
> Scott was onto the right track despite his numbers being wrong.
>
> In two independent trials I got some SAC biases in common namely
>
> 4 => 3, -3780, 0.496395
> 58 => 0, -5026, 0.495207
> 89 => 0, -6846, 0.493471
> 89 => 3, -8232, 0.492149
Did you run this test over a single key, or averaged them over lots of keys?
>
> Note that between the two trials these didn't have the same prob, they
were
> just listed as the highest. Bit 58 is really bit 26 of B, bit 89 is
really
> bit 25 of D.
Do you mean bit 89 is really bit 25 of C?
--
poncho
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15a SAC Analysis
Date: Sun, 20 May 2001 16:30:17 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9e8r84$j43$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:C2NN6.143056$[EMAIL PROTECTED]...
> > Scott was onto the right track despite his numbers being wrong.
> >
> > In two independent trials I got some SAC biases in common namely
> >
> > 4 => 3, -3780, 0.496395
> > 58 => 0, -5026, 0.495207
> > 89 => 0, -6846, 0.493471
> > 89 => 3, -8232, 0.492149
> Did you run this test over a single key, or averaged them over lots of
keys?
My test works like this.
1. Pick a random array of subkeys.
2. Pick a random text
3. For all 128 single bit differences get the encryption
4. Add or subtract from the table depending on if bit j of the output
differs
5. Go back to #1 2^20 times.
>
> >
> > Note that between the two trials these didn't have the same prob, they
> were
> > just listed as the highest. Bit 58 is really bit 26 of B, bit 89 is
> really
> > bit 25 of D.
> Do you mean bit 89 is really bit 25 of C?
Er yeah it was early in the morning... sorry.
At anyrate the new TC15a (source on website) doesnt appear to have fixed SAC
biases like it did before.
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: TC15a cryptanalysis
Date: Sun, 20 May 2001 09:20:41 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:iLMN6.142986$[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9e7gqb$pqb$[EMAIL PROTECTED]...
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:YlDN6.139133$[EMAIL PROTECTED]...
> > >
> > > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > > news:9e6v68$tqj$[EMAIL PROTECTED]...
> > > >
> > > > Actually, during my tests, I averaged over 100 different sets of
> random
> > > > subkeys. In addition, because of the structure of TC15A, I'd expect
> the
> > > > same sort of biases to exist essentially independent of the keys --
> all
> > > you
> > > > do with the subkeys is xor them into the block periodically, and if
we
> > use
> > > > random starting blocks, xoring in unknown random subkeys should have
> > > little
> > > > effect, at least to a first approximation. Of course, if you've
> > observed
> > > > that different keys do behave differently, then ignore that
argument.
> > >
> > > I agree my point is that I think the window is too small to get a good
> > idea
> > > of a useful bias. If you could show mathematically why the bias works
> > that
> > > would be more useful.
> >
> > Actually, a bias like I observed can be exploited even if we don't have
> the
> > foggiest notion *why* it works. However, I originally suspected (and
> looked
> > for) a SAC weakness because the cipher doesn't try to difuse very hard,
> and
> > what difusion is there is rather chaotic. The only things that will
> defuse
> > anything between columns are:
> >
> > - The rotates by 1, 9 and 17
> > - The multiplies by 3 and 9
> > - The carries internal to the addition.
> >
> > All this difusion is directed upwards, and if you (for example) you have
a
> > differential in column 13, then it'll take a number of the above steps
to
> > difuse to column 12. In addition, all the difusion happens on a bitwise
> > basis, and that makes those paths unreliable -- if there is a path of
> (say)
> > 5 steps from column 13 to column 12, then with probability 1-2^{-5}, one
> of
> > the bits it relies on may just happen to have a zero differential, and
so
> > that path will not influence the output bit. If that happens a
nontrivial
> > amount of the time to all the paths from the input to the output, then
the
> > output bit will be biased towards a zero differential.
>
> This is not entirely true. Remember that there is a sbox going across the
> words. So bits 1,41,81,96 are going into the first sbox etc. So in the
> next round when C is rotated 17 the bits mixed will go below bit 17.
I'm sorry, I should have made it plainer: I am thinking of the block as a
4x32 matrix, where the bits within (say) column 3 are made of of bits 3 of
A, B, C and D. Since the sbox does not difuse outside of the column, it
wasn't listed. In addition, what happens if (in your example) the sbox
happens to leave the bit in C with zero differential. In that case, when C
is rotated 17 bits, no avalanched bits will be mixed in below bit 17, and
(in my terminology) "that path will not influence the output bit"
>
> > Another idea for an attack: look at differentials that start with a
> > differential at bit 14 of C and bit 31 of D. Then, with probability
0.25,
> > the output differential of the first round will consist of bit 31 of D
> > (assuming I've done the math right -- I haven't bothered testing this).
> > This effectively wacks off another round of the cipher, at the cost of
/4
> > output bias (and hence, 16x more chosen plaintexts going in)
>
> I still want to know if your SAC bias is correct. I haven't been able to
> confirm that it exists.
>
> Tom
>
>
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: OFF-topic by now - UK crime statistics (was Re: Best,
Date: Sun, 20 May 2001 16:37:14 GMT
[EMAIL PROTECTED] wrote:
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> writes:
> >>
> >> The most general rule: ``Anyone having broken and entered is
> >> presumptively a threat to life and limb, and may be met with lethal
> >> force.''
> >
> > No.
>
> Yes.
>
> > Such an intruder may be met with the muzzle, but not with a bullet. The
> > two are not even remotely similar.
>
> You are advancing an opinion (see above).
You believe that the disparity between a muzzle and a bullet is a matter of
opinion?
> The law in some jurisdictions
> agrees with you, and in others agrees with me.
No.
The behavior I advocate is legal in all jurisdictions permitting self defense
(The UK is a good counter example). The behavior you advocate may be legal,
but it depends upon the prosecutor, judge, jury, law, and facts in a
particular case.
> Since I presume you know
> this, I guess you must be advancing your own moral viewpoint.
Actually, not. Merely the fruits of diligent study under the current
scholars and authorities of the subject.
And, for the record do not remotely resemble the rules of any existing legal
system.
> In turn I
> have advanced mine, referencing the scriptural precedent.
Anything you can prove (using scripture), I can disprove (using scripture).
Thus it does not serve as a sensible precedent. ;-)
------------------------------
From: Martin Schultz <[EMAIL PROTECTED]>
Subject: Re: People with x86 cpus (please reply)
Date: Sun, 20 May 2001 18:55:14 +0200
On Sat, 19 May 2001 13:00:09 GMT, "Tom St Denis"
<[EMAIL PROTECTED]> wrote:
>
>"Martin Schultz" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Fri, 18 May 2001 11:21:07 GMT, "Tom St Denis"
>> <[EMAIL PROTECTED]> wrote:
>>
>> >I need people with the following cpus to run a program (or alternatively
>> >build the source which is on my website) to test the speed of my cipher.
>> >
>> >- Pentium, PPro, PII, PIII
>> >- Amd K6, K6-II, K7 (original not T-bird)
>> >- Cyrix MII
>> K6-II Cycles: 218
>
>Hmm another dude said with a K6II they got 222... could you please run this
>once more just to be sure.
I have tried running it 10 times. The results variates between 216-219
Its a K6-II 300mhz running windows 2000 SP2
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15a cryptanalysis
Date: Sun, 20 May 2001 16:56:20 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9e8rjr$ih7$[EMAIL PROTECTED]...
> I'm sorry, I should have made it plainer: I am thinking of the block as a
> 4x32 matrix, where the bits within (say) column 3 are made of of bits 3 of
> A, B, C and D. Since the sbox does not difuse outside of the column, it
> wasn't listed. In addition, what happens if (in your example) the sbox
> happens to leave the bit in C with zero differential. In that case, when
C
> is rotated 17 bits, no avalanched bits will be mixed in below bit 17, and
> (in my terminology) "that path will not influence the output bit"
Um this doesn't make sense... the best way to analyze this cipher is by a
4x32 as you said. But each column is made up of *1* bit of A,B,C,D
respectively. I agree that if the output differences is only in one bit
then the diffusion can be sub-optimal. However even a diffeference in a
single bit can be costly. Let's say in the first sbox only the lsb of A
differs. In the next Beta layer (if you have read the draft paper on my
website the functions are named) A will rotate 1, B will rotate 9, etc..
then we get TEMP = 3A + 9B. Now the diff is really in bit 2 of A so the new
diff is in two bits of A (bit 2 and bit 3). This is added to C and D. Now
we have three active sboxes (2nd bit of A and two bits of C/D each possibly
more if there are carries but let's ignore that for now).
Let's ignore Gamma in this round and jump straight to Beta again. We have
two bits that differ in C which are the 2nd and 3rd bits. The rotate by 9
will place them in the 10th and 11th bits of C. Similarly we rotate D by 23
(updated source) so we have differences in bit 24 and 25 of D. Then we mult
by 3 to get differences in bit 10, 12 and mult by 9 to get differences in
bits 24, 25, 26, 27. The first TEMP in this 2nd Beta application has 6 bits
differing.
etc, etc. That's how the function achieves avalanche.
Not to mention that no single bit difference leads to a single bit
difference in the same bit position so typically we have single bit
differences moving to other registers (A/B/C/D are the registers) or to
multiple registers.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: People with x86 cpus (please reply)
Date: Sun, 20 May 2001 16:56:52 GMT
"Martin Schultz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 19 May 2001 13:00:09 GMT, "Tom St Denis"
> <[EMAIL PROTECTED]> wrote:
>
> >
> >"Martin Schultz" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> On Fri, 18 May 2001 11:21:07 GMT, "Tom St Denis"
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> >I need people with the following cpus to run a program (or
alternatively
> >> >build the source which is on my website) to test the speed of my
cipher.
> >> >
> >> >- Pentium, PPro, PII, PIII
> >> >- Amd K6, K6-II, K7 (original not T-bird)
> >> >- Cyrix MII
> >> K6-II Cycles: 218
> >
> >Hmm another dude said with a K6II they got 222... could you please run
this
> >once more just to be sure.
>
> I have tried running it 10 times. The results variates between 216-219
> Its a K6-II 300mhz running windows 2000 SP2
Ok thanks,
Tom
------------------------------
From: [EMAIL PROTECTED] (daniel gerard mcgrath)
Crossposted-To: rec.puzzles
Subject: A difficult cryptogram
Date: Sun, 20 May 2001 17:03:49 GMT
Can anyone try to decipher this message? Does anything look familiar?
The solution is a well-known poem.
74401 47111 40125 11701 12908 26061 63347 17069 42565 00164
45116 40912 11711 13154 58565 10900 01626 01541 62685 06890
33433 20521 09014 60650 01909 16567 11144 72235 32053 94143
13177 05019 45111 23131 90069 46635 11050 62632 05741 14471
10153 90506 03153 60146 74071 67456 61005 67111 43145 11123
13161 13140 44143 14006 69042 61001 64445 15603 21511 13330
26114 86131 61461 34324 03729 47600 13566 76941 00201 12532
15111 33325 60026 50502 45046 70320 55663 51430 61306 15050
23130 19805 05610 02391 69065 67404 26102 54670 45430 08540
10863 04014 36700 29425 65109 17240 40256 42087 15111 43120
64085 66910 61001 42074 01433 37820 50509 35395 11121 12572
44126 86101 54401 47111 37074 01430 16509 45245 11146 63005
54662 44268 66315 12016 60142 90543 14075 65151 11442 91740
14365 05027 11626 89159 02566 50661 71113 90740 24040 25604
31206 90529 51114 00685 70436 14037 10942 00806 71113 67890
62652 88221 00467 24051 35609 06511 36546 94256 51661 01540
53988 74005 14332 05069 26686 15456 61002 75601 30459 00093
20600 74162 66661 32511 01005 13251 17403 21862 63202 12664
66351 10083 40716 14066 10263 36066 44536 34234 48010 05615
62140 61550 38630 00473 76515 13519 58900 26690 50603 54743
14301 13057 11010 06005 16144 26340 74584 41436 90256 92204
56010 05256 86133 90426 10020 26615 45901 25010 05050 43612
57111 37194 00045 65109 41003 61143 51094 10020 11435 10945
82050 11430 10058 13714 02400 40676 72400 45762 25400 55402
03620 50203 63409 56515 24511 14524 15295 11141 54306 17245
11145 24152 95111 46504 36510 94100 36101 65092 50142 50850
92501 42508 50920 43601 41139 36120 80669 02507 01129 08267
11146 62810 59164 33020 50316 69466 11404 02569 37614 54434
02505 10516 90001 42647 45715 40545 11144 41867 45790 54511
13154 58567 24171 11240 91644 14369 02569 28614 69434 02902
56666 13251 11914 36529 52486 50502 69050 60315 36014 72405
05027 11140 13000 74432 07433 01031 11206 25540 40256 64072
95111 41620 50132 05005 02550 86301 05276 00126 63407 16131
54057 06622 62686 30198 25050 20100 58506 90784 01301 00135
45702 11094 51511 12313 19006 94472 06031 53601 40504 56863
51100 07457 02256 85065 56266 85610 01643 30095 82935 38133
61120 11523 13359 07450 05022 63406 65451 11448 56626 00844
50064 01342 56116 63511 01425 66505 02674 09000 09150 24265
29524 86611 31002 16677 05240 11335 10014 00202 25644 07351
25432 71205 56102 42663 47890 54114 01301 02634 55006 52634
14814 42746 90256 94544 32074 26105 63410 61914 26661 54667
66439 31335 31126 41485 66264 32714 35441 44263 45108 56432
71200 61143 64826 34113 53643 63407 16139 09171 18506 55620
87157 66315 12004 09401 00571 11211 20625 52813 35313 21650
65069 42635 06014 71114 45109 47111 44741 47727 05631 13113
11361 15125 11713 01133 90126 71101 00571 11444 73513 35065
01332 36125 26342 56002 43271 20882 60151 12562 50100 01640
50104 00112 05020 08340 71614 35457 02026 43694 51101 53615
40658 61140 11136 01560 25610 83151 20040 94429 56652 84136
44825 68506 53175 10480 10055 66769 10133 10290 37364 48536
10342 70502 31601 56025 61166 11401 34016 61318 30376 35065
28986 56427 08630 15528 13356 92601 00501 54433 90528 13361
12011 45407 05008 06456 72355 10943 11002 51090 26301 07225
62600 22566 77351 40245 00874 31009 17441 40406 90620 31029
07231 33945 43400 20216 28426 10016 44511 14472 23532 05390
25651 54164 00611 66351 10065 66350 10054 20933 01026 34163
01014 30143 05140 58133 71085 60100 52136 13010 01022 57790
25606 13190 06931 14354 41311 44582 05054 05313 38661 32511
72313 39012 04600 16060 16613 39042 60100 50165 09451 11480
08428 61466 63151 45111 25546 71057 07113 39042 60459 03111
20625 26291 47066 00617 66262 56113 54606 54590 52943 10290
25057 96061 63347 17069 05204 36010 05722 04360 05240 55506
1029
==================================================
daniel g. mcgrath
a subscriber to _word ways: the journal of recreational linguistics_
http://www.wordways.com/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
