Cryptography-Digest Digest #404, Volume #14 Mon, 21 May 01 19:13:01 EDT
Contents:
Re: Comparing two encrypted numbers (Lon Willett)
Re: How do you measure the power of a chipher? (Ichinin)
Re: Apology to Cloakware (open letter) (Mike Rosing)
Re: Apology to Cloakware (open letter) ("Douglas A. Gwyn")
Re: Help with a message ("Douglas A. Gwyn")
Re: wide-trail ("Douglas A. Gwyn")
Re: Help with a message (gp)
Re: CIA Kryptos last 97 characters ("Douglas A. Gwyn")
Re: How do you measure the power of a chipher? ("Douglas A. Gwyn")
Re: OAP-L3: "The absurd weakness." (James Felling)
Re: TC15 improvement bigtime ("Tom St Denis")
Re: wide-trail ("Tom St Denis")
Re: How do you measure the power of a chipher? ("Tom St Denis")
TC15a paper ("Tom St Denis")
Re: Single-cycle sbox question ("Henrick Hellstr�m")
Re: TC15a paper ("Tom St Denis")
Re: CIA Kryptos last 97 characters (Gary Warzin)
Re: OAP-L3: "The absurd weakness." (Taneli Huuskonen)
Definition of "secure hash function" (was PRNG question) (David Hopwood)
----------------------------------------------------------------------------
From: Lon Willett <[EMAIL PROTECTED]>
Subject: Re: Comparing two encrypted numbers
Date: 21 May 2001 18:28:55 +0100
"Martin Schweitzer" <[EMAIL PROTECTED]> writes:
> Is anyone aware of a technique that allows two encrypted numbers to be
> compared without decryping them? I am told that there was a paper presented
> at RSA 2000 which mentions this, but I cannot find any reference to that
> paper.
The paper is "A Cost-Effective Pay-Per-Multiplication Comparison
Method for Millionaires" by Marc Fischlin. Try the links:
http://www.mi.informatik.uni-frankfurt.de/research/papers.html
http://www.mi.informatik.uni-frankfurt.de/people/marc/marc.html
/Lon Willett
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How do you measure the power of a chipher?
Date: Thu, 17 May 2001 07:53:59 +0200
Adam wrote:
>
> When you hear about RSA crypto it is said to be in 56 bits or 128 bits.
> What do that mean? Is it the length of the public or private key or the
> two big primenumbers you multiply, or?
>
> /Adam
Hi.
1) Rsa have WAY bigger keys than that, you're confusing RSA with
a symmetrical cipher. A typical (EXPONENTIAL-) cipher key is sized
2^1024 or larger. The secret exponent in such a cipher may be 128
bits though.
2) It's the level of complexity of the key, the bigger the amount of
bits, the harder it is to crack. Add one bit and twice the effort is
required to break the cipher by bruteforce (=trying evey possible
combination)
Regards,
Ichinin
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Apology to Cloakware (open letter)
Date: Mon, 21 May 2001 12:52:42 -0500
Matt Timmermans wrote:
> This suggests an on-topic question:
>
> Has anyone heard of a reasonably successful algorithmic method for
> identifying people by writing style?
Yes, a few years ago (10+ maybe, I'm old :-) some english profs put out
an analyzer to prove plagerism in lots of different works. It worked really
well, and they got into a lot of trouble for it (I think they proved some
works by leading deans was plagerized from other people or something like that).
It may be heuristic and not algorithmic, but it definitly works. Not sure
what key words to look for, it may have been before the net was popular.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Apology to Cloakware (open letter)
Date: Mon, 21 May 2001 17:18:26 GMT
Matt Timmermans wrote:
> Has anyone heard of a reasonably successful algorithmic method for
> identifying people by writing style?
Yeah, it's actually a fairly old idea. I think it has been
used in some forensics cases. Related software was developed
at Bell Labs by Lorinda Cherry et al. and some of it was
released in the Writer's WorkBench product. ("style" and
"diction" made it into some research UNIX releases and, I
think, some versions of 4BSD.) There were Bell Labs CSTRs
on these, but they don't seem to be available via the
on-line CSTR Web page.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Help with a message
Date: Mon, 21 May 2001 17:58:07 GMT
Robert Reynard wrote:
> Could the reason for the 'poor' IC values be due to a frequent key change?
> Why is the ciphertext arranged in lines of varying number of characters?
> Could each line have been enciphered using a different key?
You can rule out the latter by looking at repeated patterns.
This is the kind of IC one would expect if each character
in a word is enciphered using a different alphabet (same set
for all words).
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: wide-trail
Date: Mon, 21 May 2001 17:21:11 GMT
Tom St Denis wrote:
> I got a 404...
Save your nickels and save your dimes,
maybe you'll soon have enough to buy you ...
a brand new 409!
------------------------------
From: [EMAIL PROTECTED] (gp)
Subject: Re: Help with a message
Date: 21 May 2001 11:20:12 -0700
If the Z is a space, the text seems to break into nice words.
If you take out the Zs then looking at the 'words'
JPJ UMPOBADV repeats in 45 and 660 characters.
There also appear 'words' MAPPMCF and MAPPMCFGXEY.
Other words are :-
IX appears 6 times.
TPF appears once TPFM appears 4 times.
JPJ appears 3 times.
EJP appears twice EJPJ once.
NNQK appears 3 times.
PR appears 3 times.
UJJ once UJK twice.
etc
Most of these occurances are multiples of 3.
If the Z is a space how does a Vigenere table appear? What happens to
the deciphered letter in the Z column/row?
Is JPJ UMPOBABV 'the -------' ???
GP
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: CIA Kryptos last 97 characters
Date: Mon, 21 May 2001 18:15:49 GMT
Gary Warzin wrote:
> 3) the leading characters of the first three lines of the portion of the table
> under part 4 work out to be WXZ (which is exactly what you would expect if the
> last line was then the abcd.. coordinates.
Why is that supposed to be significant? You have followed a procedure
that cannot fail to have that result regardless of whether you're on
the right track.
I frankly don't think you are on the right track.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How do you measure the power of a chipher?
Date: Mon, 21 May 2001 18:47:16 GMT
Adam wrote:
> When you hear about RSA crypto it is said to be in 56 bits or 128 bits.
> What do that mean? Is it the length of the public or private key or the
> two big primenumbers you multiply, or?
Actually you probably don't hear either very much,
as current recommendations for RSA key size are
considerably larger than that. To the extent that
one can meaningfully measure RSA key size, this would
be the number of bits in the modulus.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Mon, 21 May 2001 14:32:13 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > Anthony Stephen Szopa wrote:
> >
> > > James Felling wrote:
> > > >
> > > > Anthony Stephen Szopa wrote:
> > > >
> > > > > James Fe
> ><SNIP>
> >weakness. ( Do you know why? Study the Enigma for a
> > clue)
>
> "Note that this particular scramble process should only be performed
> once on any MixFile(X) because for any number of times it is
> performed an equivalent outcome can be attained by performing the
> process just once with another appropriate ten-digit sequence. The
> odds against will not change. "
>
> This is quoted right from the Help Files description for the Scramble
> Process. Over the past couple of years there have been many many
> people from all around the world who have downloaded the OAR-L3
> software with these identical Help Files as well as many who have
> the full version of OAP-L3 who only need to run the software and
> read the incorporated help files to see for themselves that this
> quote is in there.
I pointed it out to you about two years ago. I seem to recall that that
WAS NOT a part of the file until comentary on this group brought you to
add it. ( my own plus those of others)
>
>
> You did not bring this to anyone's attention. And I had no need to
> take your advice on this point or change the Help Files because of it.
>
> Nowhere in the help files do I say or even imply that the processes
> provided with OAP-L3 are exhaustive or that no other processes exist
> that can be used for similar purposes. I could have sworn I said as
> much in the help files but I could not find it. Maybe I missed it
> when I looked for it or maybe I said as much in a news group post
> some time ago. Either way, your coming up with another process is
> not surprising in the least.
True, if someone does extra work and provides a compatible plugin it can
be made even more secure. Fine. However, I am attempting to critique the
product as is. If the added features are brought in, then I will evaluate
the system based upon them. Until that time I will look at the system and
assume that that is how its maker intended it to be used.
>
>
> The processes chosen for OAP-L3 were chosen for their simplicity and
> ease of use. Generating and inputting a 14 digit sequence of numbers
> is far easier than inputting a sequence of 105 numbers, and running a
> process that uses only a 14 number input sequence is far easier to
> implement and runs faster. The object of the software and the
> processes in it is to attaining a desired OTP file security level
> which makes cracking the encrypted messages generated using the OTP
> files from OAP-L3 practicably unbreakable by scrambling the entire
> 3,628,800 possible permutations of the digits 0 - 9 unpredictably.
> This can be achieved using these 14 number sequences in the
> particular processes concerned and other number sequences for other
> processes in OAP-L3.
I agree that the order 14 permutation is a usable size, but why 14, why
not 7 or 5 or 15? There must have been some design choices there.
>
>
> I am sure that your example of randomly ordering 105 permutation
> groups is of some minor interest to some. Why settle for 105
> permutation groups, or even 210, or 420, etc.? Isn't randomly
> ordering only a 105 permutation group merely an inefficient way of
> randomly ordering the 3,628,800 permutation group? Why not just go
> for it and randomly order the 3,628,800 permutation group right from
> the get go. Then you would have 3,628,800! possibilities.
The order 105 group is the generic family that mix a mix file falls into.
It will fill that space fairly slowly, and unevenly. This means that
certian permutative structures will be more common thatn others. This can
lead to a weakness. you also claim that repeating processes will always
add security. the fact that it is part of an order 105 group meens that
there is a cap upon how much randomness this permutation can contribute in
sequential aplication. No, I am not claiming that it is insulficient
merely that you have a tendency to throw numbers out without an
apreciation of the phenomena associated there with.
>
>
> Hope you get it. Do you get it?
>
> Here is a clue: if you randomly shuffled the 3,628,800 permutation
> file from the get go then you wouldn't need any of the processes in
> OAP-L3.
Yes.
> Furthermore if you randomly shuffled the 3,628,800 permutation
> file from the get go then you wouldn't even need any random number
> generator or encryption software at all.
true.
> You could just use your
> random process to generate random numbers that then could be used to
> encrypt messages directly.
>
> Are you simply arguing that if you do not use true random numbers in
> encryption then you do not have random encryption, or that to use
> random input to generate a stream cypher where you use more output
> data than random input data provides less than random encryption, or
> both?
No. what I am saying is that the methods used have slow difusion, require
alot of work and have weaknesses such as fixed points, poor mixing, and
other such flaws.
>
>
> So far, you seem to have sure gone out of your way to argue the most
> fundamental encryption dogma. So far, you have not offered us
> anything new except how to subtly obfuscate a well known principle.
Really? So how would YOU fix that nasty fixed point issue?
What about the other points I raise?
>
>
> Mind you, I said, "So far." I am not through reading or evaluating
> your reply post.
>
> Furthermore, the output from the random digit generator is not used
> to encrypt messages. You must surely know this. And only about 70%
> of the random digit output is randomly used to generate random
> numbers from 0 - 255. And you should know that these random number
> files are processed further before the final OTP file generation
> process is used that takes more random user input. Your comparing
> OAP-L3 to Enigma is the greatest enigma of you fundamental position.
Of course I knew that. Your discarding does add strength. However, you
still have a flaw very similart to enigma. in that the discarding is most
strongly influenced by 1 of your 3 streams, and that the 0-9 set issue is
still present just not 100% reliable. It allows prediction of the high
bit in general better that random guessing. This is bad.( certianly not
100% compromising, given apropriate work has been done, but certianly
suboptimal).
>
>
> I will get back to you again on your reply post with more specifics
> in a day or two.
>
> Thanks for the challenge.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15 improvement bigtime
Date: Mon, 21 May 2001 19:42:06 GMT
"Vincent Quesnoit" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> What I meant was that in the case of a multiplication by three, the adder
can be
> simplified compared to what a standard adder does when the same bits are
not
> repeated, ie in B xor C+CD, the repetition of C suggest that some
> simplifications can be done in the overall boolean expresion that computes
a
> bit, and even more so when you move towards more significant bits. This
may lead
> to expressions that do not need to wait for the carry to propagate over 29
bits.
>
> In the multiplion by 9, you would get an expression like F xor I +GJ which
does
> not show the same kind of simplification.
Oh I think I see what you are saying....
In my analysis though I consider a 32-bit add to be trivial and don't
discuss the finer points of optimization (because quite frankly I don't know
any)
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: wide-trail
Date: Mon, 21 May 2001 19:42:52 GMT
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > I got a 404...
>
> Save your nickels and save your dimes,
> maybe you'll soon have enough to buy you ...
> a brand new 409!
Hmm well neat thought. The link still don't work.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: How do you measure the power of a chipher?
Date: Mon, 21 May 2001 19:44:10 GMT
"Adam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> When you hear about RSA crypto it is said to be in 56 bits or 128 bits.
> What do that mean? Is it the length of the public or private key or the
> two big primenumbers you multiply, or?
Um a 56-bit RSA key is not secure at all. In fact I think the 56 comes from
the DES keysize.
People just fling around bit lengths as if they mean something... hahahaha
Well I know my web browser is secure because it uses 128-bit crypto... none
of that 40-bit stuff!
Tom
[ yes I am joking around ]
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: TC15a paper
Date: Mon, 21 May 2001 21:21:12 GMT
Again I have editted the paper a bit (didn't change the algo). I can't seem
to find any breaks on the cipher which sucks (means I am not working hard
enough). My best attack is a two round truncated differential. It can't
attack more rounds .. so as it stands 2/8 of the rounds are broken...
I think my differential analysis is still pretty basic and lacks real
guts... I will concentrate there...
http://tomstdenis.home.dhs.org/tc15a.pdf
http://tomstdenis.home.dhs.org/tc15a.ps.gz
Please comment on the paper if you read it ...
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Single-cycle sbox question
Date: Mon, 21 May 2001 23:37:11 +0200
"David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
news:9ebc7l$cnp$[EMAIL PROTECTED]...
> By the way, with 8-bit values, the chances of collision are exceedingly
> low. There are 256! 8-bit permutations, and 255! single-cycle
> permutations, and sqrt(255!) is very large.
If you generate random (not pseudo random) single cycle permutations, that
would be equivalent to wasting 8 out of 1684 bits of random key data.
If you use the algorithm in the Naor-Reingold paper to generate random 8-bit
involutions you would waste approximately 716 bits of random key data.
You are right that this need not matter if the input function only is pseudo
random. (In such case one should note that the security proof requires that
the input function has to take twice the amount of queries compared to what
one wants the resulting permutation to take. That's another question.)
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: TC15a paper
Date: Mon, 21 May 2001 21:56:34 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:cFfO6.156640$[EMAIL PROTECTED]...
> Again I have editted the paper a bit (didn't change the algo). I can't
seem
> to find any breaks on the cipher which sucks (means I am not working hard
> enough). My best attack is a two round truncated differential. It can't
> attack more rounds .. so as it stands 2/8 of the rounds are broken...
>
> I think my differential analysis is still pretty basic and lacks real
> guts... I will concentrate there...
>
> http://tomstdenis.home.dhs.org/tc15a.pdf
> http://tomstdenis.home.dhs.org/tc15a.ps.gz
>
Sorry correct urls are
> http://tomstdenis.home.dhs.org/tc15.pdf
> http://tomstdenis.home.dhs.org/tc15.ps.gz
Tom
------------------------------
Subject: Re: CIA Kryptos last 97 characters
From: [EMAIL PROTECTED] (Gary Warzin)
Date: Mon, 21 May 2001 22:10:53 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>> 3) the leading characters of the first three lines of the portion of the
table
>> under part 4 work out to be WXZ (which is exactly what you would expect if
the
>> last line was then the abcd.. coordinates.
>
>Why is that supposed to be significant? You have followed a procedure
>that cannot fail to have that result regardless of whether you're on
>the right track.
>
>I frankly don't think you are on the right track.
Sorry, I don't understand your statement. The only way the WXZ (well, at
least the W & Z) fall at the beginning of the lines is if the KR and YP fall at
the end of lines. That placement was done by Sanborn, not me. Follow my
reasoning:
1) I noticed the only section 4 had consistent line lengths - this could be
random.
2) I noticed that two of the lines ended in KR and YP, significant letter
combinations given this particular sculpture - but again this could be random.
3) I wondered if those characters could have anything to do with an underlying
message showing through (re: palimpsest). No assumption made at this point
that it was a table - I had no idea what it might (or might not) be.
To investigate this further I looked for a pattern and found that the shift of
the YP relative to the KR fit the pattern of an underlying Vigenere table -
this added some evidence that this might be intentional.
Now, here's the part about the WXZ. Assume the table underlying the ends of
those lines looks like this - caps are the letters we know for sure, lower case
are what would have to be there (hidden by the new text) if this really was an
underlying table):
KR
kry
krYP
krypt
Calculating back to the beginning of those lines you get WXZK. If the bottom
line is used for coordinates (as in the known table) then we have the K is
not relevant and we have a table ending at precisely the bottom page. This
seems rather unlikely to have happened by chance. That is, if the KR and YP
had been some other random characters, say CE and DF that would still be
consistent with the relative shift of an underlying table, the end result would
be a table that was broken in the middle by the end of the page. While that
still would not have totally rulled out an underlying table, it does seem much
more convencing when the table ends at the bottom of the page.
I appreciate your skepticism. I hope this at least helps clears up why I think
the WXZ is significant and does lend support to the theory - the main point of
which is that the real message is only 93 characters; i.e., the 97 minus the KR
and YP.
===========================================
Gary Warzin [EMAIL PROTECTED]
Audiophile Systems, Ltd. www.aslgroup.com
Phone: 317-849-7103 Fax: 317-841-4107
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: 22 May 2001 01:24:31 +0300
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[newsgroups trimmed]
In <[EMAIL PROTECTED]> Anthony Stephen Szopa
<[EMAIL PROTECTED]> writes:
[...]
>But I do remember you claiming that you found a weakness in OAP-L3.
>Where did that one go?
We couldn't agree on whether what I'd found deserved to be called a
potential weakness or not. I got bored before you did.
What I said then still holds. I don't want to repeat it all, there are
news archives for the curious.
And no, I still haven't got a practical attack.
[...]
>(I must have missed that post. Why don't you just tell us the
>weakness you perceive and see if I can't just disprove what you
>say with logical argument.
>You could save yourself a lot of time and effort that way.)
Here's a copy of the original posting. Looks like the poster doesn't
leave much room for argument, logical or otherwise (provided he's still
around):
--- BEGIN ATTACHED POSTING ---
> From: 0xdeadbeef ([EMAIL PROTECTED])
> Subject: OAP-L3 v. 5.0 broken (was Re: Crypto Export Restrictions)
> Newsgroups: talk.politics.crypto, sci.crypt
> Date: 2000/11/07
>
>In article <[EMAIL PROTECTED]>,
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>>
>> The onus is on you: That is if you have the intelligence and energy
>> and interest.
>>
>> If not: forget about it.
>>
>
>OK. I take the challenge. I can break OAP-3 version 5.0 if it works as
>your website says.
>
>You do this: you take about 1 MB text file of English and add words
>"Sincerely Yours, XXXXXXXXXXXXXXX" in 100 different places in it.
>"XXXXXXXXXXXXXXX" is your secret code name with 15 letters and numbers.
>You encrypt it with your program, but you use only 50 rows in your
>tables. Then you put encrypted file on your Web site and post the URL.
>After 30 days or earlier I post the secret name to this newsgroup.
>Deal?
>
>Sincerely Yours,
>0xdeadbeef
>--
>Schroedinger's Bull:
>
>0xdeadbeef = [EMAIL PROTECTED]
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--- END ATTACHED POSTING ---
>I do recognize that you seem to have abandoned your posts attacking
>OAP-L3. How come?
As I said, I got bored.
>Hope you are well.
Thanks, I'm okay. The same to you.
>AS
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOwmVVF+t0CYLfLaVEQLF/gCg6a22uSMSturxUaWmrDVFGFbjDyMAoJzo
SAGVEe4L1WMHBwXImb1MOoZd
=WFXr
=====END PGP SIGNATURE=====
--
I don't | All messages will be PGP signed, | Fight for your right to
speak for | encrypted mail preferred. Keys: | use sealed envelopes.
the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
Date: Mon, 21 May 2001 23:28:35 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Definition of "secure hash function" (was PRNG question)
=====BEGIN PGP SIGNED MESSAGE=====
David Wagner wrote:
> Roger Schlafly wrote:
> >OTOH, it is possible to have a secure hash function (in the sense that=
> >it is one-way and collision-resistant) but where one bit of every outp=
ut
> >byte is zero. But that would give a very poor stream cipher.
> =
> Yes, but usually when people say "secure hash function", they implicitl=
y
> assume far more than just one-wayness and collision-resistance. So I t=
ake
> "secure hash function" to mean that it behaves like a random oracle, wi=
th
> no structure whatsoever.
Which is of course not true of MD5, SHA-{1,256,384,512}, RIPEMD-{128,160}=
,
HAVAL, Tiger, Whirlpool, etc., because they have the Merkle-Damg=E5rd str=
ucture.
This is not just an academic point: if these hashes really behaved like a=
function chosen at random, then Hash(key || message) would be a secure MA=
C.
- -- =
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 0=
1
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has b=
een
seized under the Regulation of Investigatory Powers Act; see www.fipr.org=
/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOwhDGjkCAxeYt5gVAQGoTQgAhdKk1qo40QLAGRI1bkjWXK9KaC6PdICP
YyAflZh1Y6HHi1uZRtH7GQkX/9qREjWrw6a3Wh/740FT6Bh+atSLkOw6re3Gdt1o
XsDPSxOEIXrrUrPaVNHm5BKV+DEYQWQcJtKYBzdnyBXwu0OQ018jtdz3fa+3m9Yy
8A4t9LTBjXiSDsPaa4rewfdbZzuVrNqrR9PAx5FBofScGa3dDFFC0jQYfjasaKtv
8BVAqvLKb6UxV1SX21AmUHU1M1w3uMBltxRcCs9g9hE8Rv8EamNhPce1sr08BA8N
xwlgg96KxXcYXs6SdPjtXLPHg6Vgvt5xh2Vnq5IIN+SbQpZJgBbilg=3D=3D
=3D805T
=====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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
