Cryptography-Digest Digest #323, Volume #14 Wed, 9 May 01 20:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (Doug Kuhlman)
Re: The novel _enigma_ by Robert Harris (Jim D)
Integrity check algorithm ("Uros Podlogar")
Re: Integrity check algorithm ("Tom St Denis")
Bitsliced Cipher ("Tom St Denis")
Re: Random and not random (James Felling)
Re: free en/decryption library (James Felling)
mathematical definition of phi ("Dopefish")
Re: Optimizing AES throughput (Harshal Chhaya)
Re: mathematical definition of phi (Bill Unruh)
Re: Bitsliced Cipher ("Tom St Denis")
Re: Random and not random (Mok-Kong Shen)
Re: Random and not random (Mok-Kong Shen)
Re: Random and not random (Bryan Olson)
Re: Bitsliced Cipher ("Kostadin Bajalcaliev")
Re: Bitsliced Cipher ("Tom St Denis")
Re: Random and not random (Mok-Kong Shen)
Re: Random and not random (Matthew Skala)
Re: Random and not random (Mok-Kong Shen)
Re: Random and not random (Bryan Olson)
Re: Random and not random (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Wed, 09 May 2001 14:55:48 -0500
jlcooke wrote:
>
<SNIP>
>
> If length(Ki) == 256 while length(Pi) == length(Ci) == 128 (as in
> AES256)
>
> There are 2^256 possible keys, and only 2^128 transformations from any
> P_i to C_i.
>
False. There are (2^128)! (yes, 2^128 factorial) transformations (maps)
from P to C, if both are of size 128 bits. That is significantly more
than merely 2^256.
Doug
------------------------------
From: [EMAIL PROTECTED] (Jim D)
Subject: Re: The novel _enigma_ by Robert Harris
Date: Wed, 09 May 2001 20:11:30 GMT
Reply-To: Jim D
On 8 May 2001 21:52:04 GMT, [EMAIL PROTECTED] (Ed Pugh) wrote:
>1. U.S.A. B-17s stationed in Britain.
>
>Chapter 1, Section 2, page 16, lines 15-18.
>
>Near the beginning of the novel, the hero, Tom Jericho, is
>walking toward an American air field in Britain, near Cambridge
>in mid-March, 1943. He is enjoying a sunny sky:
>
> ".. the sky was a glory -- a pure blue dome above the flat
> landscape of East Anglia, filled for miles with the silver
> specs of aircraft and the white scratches of contrails."
>
>Would Allied war planes have been silver by this time, or would
>they have still been painted olive-green?
Possibly. Well, they *were* Americans after all!
>Also, I always thought that only jet engine planes would form
>contrails. Would piston-prop driven airplanes form white
>contrails in the sky?
No. Piston-engined aircraft can leave contrails.
>Did German U-boats have AC electric power systems?
I would have thought DC, but they could well have an AC supply
as well. If it was only DC they would have had to use an inverter
to produce AC and that *would* make some noise.
>If so, then did the U-boat Enigmas have an AC power supply? In short,
>would a U-boat Enigma "hum" when it was turned on? If so, then
>what, exactly, would cause the "hum"?
Author's embellishment?
Read Wolfgang Hirschfeld, "The Secret Diary of a U-Boat".
Orion Paperback, 1997. ISBN 0 75281 116 9.
WO Hirschfield was a Radio Officer on U-Boats throughout the
Battle of the Atlantic. You might get some clues there.
--
______________________________________________
Posted by Jim D.
Nole me vocari, ego te vocabo.
jim @sideband.fsnet.co.uk
dynastic @cwcom.net
______________________________________________
------------------------------
From: "Uros Podlogar" <[EMAIL PROTECTED]>
Subject: Integrity check algorithm
Date: Wed, 9 May 2001 22:31:57 +0200
Here is short story. I would like to encode message with private key. Then I
will publish message with public key. Everyone could decode message with
public key, but none could generate another message only with public key.
I would use this routine to sign the document so that everybody could check
its integrity, but nobody could change document and generate another
signature.
Which algorithm should I use?
Thank you
Uros
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Integrity check algorithm
Date: Wed, 09 May 2001 20:35:15 GMT
"Uros Podlogar" <[EMAIL PROTECTED]> wrote in message
news:zLhK6.8$[EMAIL PROTECTED]...
> Here is short story. I would like to encode message with private key. Then
I
> will publish message with public key. Everyone could decode message with
> public key, but none could generate another message only with public key.
>
> I would use this routine to sign the document so that everybody could
check
> its integrity, but nobody could change document and generate another
> signature.
>
> Which algorithm should I use?
Well you can use RSA or ElGamal to encode the hash of the message.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Bitsliced Cipher
Date: Wed, 09 May 2001 20:52:27 GMT
I would appreciate comments (please!).
It's not a commercial cipher or anything just for the sake of research. My
design achieves 409 megabits/sec on my Athlon 1.2ghz that's about 24 cycles
per byte (code is written in C not asm). I probably could get it down
around 20 cycles per byte in assembly.
The main features of the cipher
1. Very simple. The complete source is about 100 lines of C code with
white spaces and comments
2. No tables or magic constants (except one in the key schedule).
3. Very simple operations in the cipher all boolean operations essentially
which means it may be very well suited for hardware platforms.
The C source is at http://tomstdenis.home.dhs.org/tc15.c
I have updated the linear transform to increase the avalanche effect. I
plan on analyzing it wrt various attacks and see if I can break it. I would
appreciate any feedback or comments.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 16:11:38 -0500
Mok-Kong Shen wrote:
>
> You are not arguing at the level of the above quote of
> mine (i.e. arguing directly against it) but is evidently
> continuing reasoning directly on the OTP issue with the
> help of an analogy in my view. There is nothing against
> analogy in general. I used one. But I don't see that
> your points invalidate the formal logical result I claimed
> in the previous post. (It could though (I don't know yet)
> on the other hand be used to show that the premise is
> invalid.)
>
> Bryan Olson has in his previous post expressed his
> viewpoint (I assume that you agree with him) that 'there
> is no best or worst permutation to choose' and I have from
> that logically deduced 'any choice is equivalent to the
> other' and from that deduced 'the choice is entirely free'.
> This deduction is a 'purely' formal logical operation in
> the sense that it is fairly independent of the specific
> instance (namely our OTP issue) to which it is applied.
> My logical deduction could be flawed, I don't know for
> sure at the moment. But in that case the flaw should be
> clearly demonstratable like any invalid deduction chain in
> logic purely formally, isn't it? To be precise, denoting
> any 'permutation' by x (or y, if different from x), we
> have the following:
>
> There is no best or worst x to choose --->
> Any choice x is equivalent to any other choice y --->
> One is entirely free to choose an (arbitrary) x
>
> Could you show the flaw in this chain in the 'formal'
> sense (i.e. forgetting momentarily about the issue
> of OTP to which this logical reasoning is applied)?
> I mean we are debating, thanks to the analysis of
> Bryan Olson, currently at a more abstract level, which
> is easier for exposing eventual flaws present. After
> we have settled this formal logical issue, which
> I believe is of value by itself, we can (should) go
> back to discuss, if necessary, again the concrete OTP
> issue (a concrete instantiation of the above logical
> formula). If you consider this formal treatment of
> our topic to be inappropriate, I should appreciate to
> know your concrete reasons.
>
> (Note that 'There is no best or worst x to choose' is a
> premise in the above. If it is false for our OTP issue,
> then of course the above logical deduction chain need
> not be further considered.)
>
> M. K. Shen
Ok. Let me try and formalize it.
Given a stream of Random data R, of length m*n divide this stream into m pieces
R(i) each n bits in length.
Let Q={ set of all possible permutations P of the integers {1,2,....,n} }
index Q in a set manner. Then let P(i,j) be the value that the ith permutation in
Q maps j to.
Let Q*= number of permutations in Q
given k an arbitrary integer between 1 and Q*.
let F(x1,x2,.....,xm) be a maping that takes m n-bit numbers and maps them to the
integers between 1 and Q*.
let || denote the concatenation operator
Then
case 1:the stream R(1) || R(2) || .... || R(m) is a good random source.
case 2:the stream R(P(k,1)) || R(P(k,2) || .... || R(P(k,m) is a good random
source, as knowledge of k in no way compromises the stream.
case 3:the stream R(P(F(R(1),R(2),....R(m)),1) || R(P(F(R(1),R(2),....R(m)),2) ||
.... ||R(P(F(R(1),R(2),....R(m)),m) will only be 100% secure if F is a constant
value -- i.e. not dependent in any way upon the various R's.
If it is in some way dependent upon one or more of the R's then it becomes
possible with an extensive comrpomise of the system to eliminate possible values
of the R's upon which the system depends.
example: we have intercepted the ordered stream except for a brief period
containing R(i), and we know all details of the algoritim.
In case 1 M(i)= Plaintext(i) xor R(i) remains secure, there are 2^n equally
possible values.
In case 2: The message encrypted with R(i) remains secure as there are still 2^n
possible values.
In case 3, however the situation changes. If the F chosen is dependent upon R(i)
the fact that we know the ordering of the R's and the function means that we can
work the function backwards and gather information about R(i) that way. Since we
know the ordering we then know the value of F(x1,x2,..,xm). since this is true we
can eliminate an R(i) if it would result in the wrong value for F. This means that
we are no longer 100% secure, as we now have the ability to reject some quantity
portion of the space of all possible R(i)'s this can possibly even completely
break the code for R(i)
(i.e if q* >2^n and F(x1,x2,....,xm) =xi then what we will have leaked is the
exact value of R(i). This is a complete break of the system for a that message. --
much less secure than cases 1 or 2.
True the example given is an extreme one, and is this is best described as a
theoretical hole in the method, but since it is just as easy to not use a
permutation choice not dependent upon the stream, why risk it.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: free en/decryption library
Date: Wed, 09 May 2001 16:16:39 -0500
yomgui wrote:
> as long as the last operation is a xor with a pseudo random number I
> maintain it's a xor.
> whatever I do before the result is at least as secure as the final xor.
> I am sure you can understand that.
>
an Xor based stream cypher which is what this sounds like is only as secure as
the PRNG. Xor in and of itself adds no security, it is merely the way in which
the data is combined.
------------------------------
From: "Dopefish" <[EMAIL PROTECTED]>
Subject: mathematical definition of phi
Date: Thu, 3 May 2001 19:50:46 -0500
is there some sort of mathematical expression that i could use to find
phi(n) on my TI-89 calculator?
fish
--
======BEGIN SIGNATURE======
A.K.A "Dopefish" or "fish" for short on Usenet.
Microsoft? Is that some kind of toilet paper?
"Rockin' the town like a moldy crouton!"
- Beck (Soul Suckin' Jerk - Reject)
"Help me, I broke apart my insides. Help me,
I've got no soul to sell. Help me, the only thing
that works for me, help me get away from
myself."
- Nine Inch Nails (Closer)
=====BEGIN GEEK CODE BLOCK=====
Version: 3.12
GO dpu s++:++ a---- C++++ U--->UL
P L+ E? W++ N+++ o+ K--- w+>w+++++
O--- M-- V? PS+++ PE Y-- PGP t 5--
X+ R tv b+ DI D+ G-- e- h! r z
======END GEEK CODE BLOCK======
(www.geekcode.com)
======END SIGNATURE======
------------------------------
From: [EMAIL PROTECTED] (Harshal Chhaya)
Subject: Re: Optimizing AES throughput
Date: Wed, 09 May 2001 21:41:08 GMT
Thanks to David Crick (and the nice people at NSA), I have the data I
was looking for. The VHDL implementations done by NSA to help NIST in
round 2 of the AES process have details on throughput etc.
Thanks,
Harshal
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: mathematical definition of phi
Date: 9 May 2001 22:08:34 GMT
In <3af1fd12$[EMAIL PROTECTED]> "Dopefish"
<[EMAIL PROTECTED]> writes:
>is there some sort of mathematical expression that i could use to find
>phi(n) on my TI-89 calculator?
That would mean you would have to be able to factor n. Since factoring
is hard, you might be able to do it for small n, but not large n. Of
course if you know n is prime, then it is easy.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Bitsliced Cipher
Date: Wed, 09 May 2001 22:29:27 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:f6iK6.52991$[EMAIL PROTECTED]...
> I would appreciate comments (please!).
>
> It's not a commercial cipher or anything just for the sake of research.
My
> design achieves 409 megabits/sec on my Athlon 1.2ghz that's about 24
cycles
> per byte (code is written in C not asm). I probably could get it down
> around 20 cycles per byte in assembly.
Well toying with a LT analyzer I wrote I think I came up with a slightly
better LT. It's less symmetric words on the same half (if you noticed my LT
is a feistel network) so the diffusion is a bit less ordered in appearance.
Modified source at
> The C source is at http://tomstdenis.home.dhs.org/tc15.c
I would appreciate comments please. Anything at all!
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 00:40:27 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > Bryan Olson wrote:
> [...]
> > > I did not post anything so misleading. I wrote:
> > > | There is no best or worst permutation to choose; only good
> > > | and bad methods by which to make the choice.
> > >
> > > > and see what result
> > > > you'll get. It's a rather simple task, isn't it?
> > >
> > > To show the that it's nonsense is a simple task.
> > > There's no defined min and max among distinct permutations.
> > >
> > > But the real error is that you are still looking in the
> > > wrong place. It's the method of choosing the permutations
> > > that can destroy perfect secrecy, not any property of
> > > particular permutations. You had to deliberately chop my
> > > sentence in half to lead yourself so astray.
> >
> > I am sorry to say that I am rather surprised by your
> > 'apparent' (I hope unreal) inability to capture meanings
> > of stuffs (fairly carefully written by others) according
> > to the proper contexts that are prevailing. Note that
> > the words 'best' and 'worst' in your own claim imply
> > that there is a measure to evaluate the permutations
> > according to certain (your chosen) criteria (for your
> > application purposes etc.)
>
> False; I told you there is *no* best or worst permutation and
> I told you the reason: good or bad is property of the way you
> choose permutations, not the permutations themselves.
To more thoroughly clear the matter up, let's consider
a hypothetical yet concrete scenario. Suppose I am the
cipher clerk and you are my boss, the chief of the
encryption department. I come to you and tell you that
I have 3 OTP segments and 3 messages to encrypt and ask
you whether there is any difference with the choice of
the 6 possible permutations for sending the messages,
i.e. whether the opponent could have a better chance
to crack in the one case than in the other. What would
be your answer? I suppose you would certainly answer
'No' (for that exactly corresponds to your previous claim
'there is no best or worst permutation to choose'), isn't
it? That means (irrespective of whether your judgement of
the real situation is indeed correct or not) you have
'deemed' that the 6 alternatives are equivalent in matters
of security. In this case I am entirely free to choose any
one of these, isn't it?
(If your answer were 'Yes', it would indeed have been a
more interesting case for me. For my next question would
be: Which of the 6 alternatives is the best one, i.e.
offering the highest security?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 00:48:07 +0200
James Felling wrote:
>
[snip]
> Ok. Let me try and formalize it.
[snip]
I suppose that, in order to avoid eventual unnecessary
debates, it is best that I settle first an apparent
misunderstanding between Bryan Olson and me. (I have just
answered his post.) I hope that's o.k. for you.
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 16:20:45 -0700
Mok-Kong Shen wrote:
> To more thoroughly clear the matter up, let's consider
> a hypothetical yet concrete scenario. Suppose I am the
> cipher clerk and you are my boss, the chief of the
> encryption department.
You would be so fired.
> I come to you and tell you that
> I have 3 OTP segments and 3 messages to encrypt and ask
> you whether there is any difference with the choice of
> the 6 possible permutations for sending the messages,
> i.e. whether the opponent could have a better chance
> to crack in the one case than in the other. What would
> be your answer?
It would be the same correct answer that multiple people
have already given you many times: Just be sure the
choice of permutation is independent of the content of
the segments. See my previous posts, or Matthew Skala's
posts or James Felling's posts.
--Bryan
------------------------------
From: "Kostadin Bajalcaliev" <[EMAIL PROTECTED]>
Subject: Re: Bitsliced Cipher
Date: Thu, 10 May 2001 01:18:58 +0200
H
Your cipher has pass my initial avalanche effect test. Since it is 128-bit
cipher, 128000 random pairs (x,y) where x and y differ in k-bits 1<= k <=
128 are tested, if the cipher produce a strong avalanche effect there should
be a combinatorial distribution no matter which input difference is
presented to the cipher. The results are sent to your e-mail. Nice work,
even I did not expect a cipher using only xor to show this results.
Kb
Tom St Denis wrote in message ...
>I would appreciate comments (please!).
>
>It's not a commercial cipher or anything just for the sake of research. My
>design achieves 409 megabits/sec on my Athlon 1.2ghz that's about 24 cycles
>per byte (code is written in C not asm). I probably could get it down
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Bitsliced Cipher
Date: Wed, 09 May 2001 23:29:06 GMT
"Kostadin Bajalcaliev" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> H
>
> Your cipher has pass my initial avalanche effect test. Since it is 128-bit
> cipher, 128000 random pairs (x,y) where x and y differ in k-bits 1<= k <=
> 128 are tested, if the cipher produce a strong avalanche effect there
should
> be a combinatorial distribution no matter which input difference is
> presented to the cipher. The results are sent to your e-mail. Nice work,
> even I did not expect a cipher using only xor to show this results.
Thanks. Can you send the program too? I want to run the test for a bit
longer to get better values (i.e more realistic).
The cipher *seems* secure for two reasons. The LT is good at mixing up the
bits. So the output of the LT is a series of linear functions of the input
bits. Second the sbox is non-linear so overall the cipher appears
nonlinear.
Of course mdw or wagner or myself might break the cipher in the next week or
so.... so
DONT USE MY CIPHER IN A REAL PRODUCT!
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 01:33:43 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > To more thoroughly clear the matter up, let's consider
> > a hypothetical yet concrete scenario. Suppose I am the
> > cipher clerk and you are my boss, the chief of the
> > encryption department.
>
> You would be so fired.
>
> > I come to you and tell you that
> > I have 3 OTP segments and 3 messages to encrypt and ask
> > you whether there is any difference with the choice of
> > the 6 possible permutations for sending the messages,
> > i.e. whether the opponent could have a better chance
> > to crack in the one case than in the other. What would
> > be your answer?
>
> It would be the same correct answer that multiple people
> have already given you many times: Just be sure the
> choice of permutation is independent of the content of
> the segments. See my previous posts, or Matthew Skala's
> posts or James Felling's posts.
But this is a Yes/No question, isn't it? In all business
transactions, there are alternatives. One picks the
one with the highest estimated chance of success (gain).
If there is no difference in that, then one takes an
arbitrary one. Why should crypt be any different in
that 'general' behaviour? Note that, if a dependency
on the content of the OTP segments could result in
any difference, that means directly I could determine
one permutation out of the 6 that the opponent has the
least chance of success and consequently I should have
chosen that one, instead of making a random choice (your
independent choice). Is that right?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Random and not random
Date: 9 May 2001 16:35:36 -0700
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>cipher clerk and you are my boss, the chief of the
>encryption department. I come to you and tell you that
>I have 3 OTP segments and 3 messages to encrypt and ask
>you whether there is any difference with the choice of
>the 6 possible permutations for sending the messages,
>i.e. whether the opponent could have a better chance
>to crack in the one case than in the other. What would
>be your answer? I suppose you would certainly answer
I'm still hoping to get you to play my poker game.
I'll fairly deal out two hands, face down. You don't see them, I don't
see them. If I choose the one on the left and give you the one on the
right, is that fair? Yes, of course it is. If I choose the one on the
right and give you the one on the left, is that fair? Yes, that's fair,
too. So you don't care which one I choose, right? THE PERMUTATION
DOESN'T MATTER, RIGHT?
Fine. I will look at the two hands, and then make one of the choices
described above. It'll be fair either way, right?
Want to play the game? If not, why not, and how is it meaningfully
different from your OTP scenario?
--
Matthew Skala
[EMAIL PROTECTED] "I fish stranger things than you
http://www.islandnet.com/~mskala/ out of my granola every morning."
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 01:44:23 +0200
Matthew Skala wrote:
>
> Want to play the game? If not, why not, and how is it meaningfully
> different from your OTP scenario?
My answer sounds unbelievable but is true. Unfortunately
(maybe fortunately), I have never played any card games in
my life.
M. K. Shen
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Wed, 09 May 2001 16:51:08 -0700
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
> >
> > Mok-Kong Shen wrote:
[...]
> > > There is no best or worst x to choose --->
> > > Any choice x is equivalent to any other choice y --->
> > > One is entirely free to choose an (arbitrary) x
> > >
> > > Could you show the flaw in this chain in the 'formal'
> > > sense [...]
> >
> > The above is not formal logic, and even as informal logic it
> > is much too vague. That said, I suspect the flaw is
> > assuming that a predicate true of any constant from some set
> > must also be true of a random variable ranging over the same
> > set. There is no best or worst permutation to choose, only
> > good and bad methods by which to make the choice.
>
> To suspect is one thing, to demonstrate is another.
Your argument was not sufficiently well defined to allow a
definitive demonstration of where it goes wrong. As for
demonstrating the error in your application to encryption,
see my specific quantitative analysis of choosing the
permutation by sorting. I got the basic example from Paul
Schlyter, so you could also see his posts. Matthew Skala
also explained the error, and James Felling has now
presented a quantitative demonstration.
--Bryan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Thu, 10 May 2001 01:57:29 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> >
> > Bryan Olson wrote:
> > >
> > > Mok-Kong Shen wrote:
> [...]
> > > > There is no best or worst x to choose --->
> > > > Any choice x is equivalent to any other choice y --->
> > > > One is entirely free to choose an (arbitrary) x
> > > >
> > > > Could you show the flaw in this chain in the 'formal'
> > > > sense [...]
> > >
> > > The above is not formal logic, and even as informal logic it
> > > is much too vague. That said, I suspect the flaw is
> > > assuming that a predicate true of any constant from some set
> > > must also be true of a random variable ranging over the same
> > > set. There is no best or worst permutation to choose, only
> > > good and bad methods by which to make the choice.
> >
> > To suspect is one thing, to demonstrate is another.
>
> Your argument was not sufficiently well defined to allow a
> definitive demonstration of where it goes wrong. As for
> demonstrating the error in your application to encryption,
> see my specific quantitative analysis of choosing the
> permutation by sorting. I got the basic example from Paul
> Schlyter, so you could also see his posts. Matthew Skala
> also explained the error, and James Felling has now
> presented a quantitative demonstration.
The ordering of your news server may have a problem..
The actual (most recent) post of mine is of
Thu, 10 May 2001 01:33:43 +0200, just send some 5-10
minites ago. Please respond to that.
M. K. Shen
------------------------------
** 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
******************************
