Cryptography-Digest Digest #460, Volume #14 Mon, 28 May 01 06:13:01 EDT
Contents:
Re: Evidence Eliminator Detractors Working Hard But No Result? (Andrew Sullivan)
Re Slide Attacks (was Re: How do boomerang attacks work?) (Tom St Denis)
Re: Stream Cipher combiners (Tom St Denis)
Re: How do boomerang attacks work? (David Wagner)
Re: 2,2-multipermutation? (Serge Vaudenay)
Re: The HDCP Semi Public-Key Algorithm (Scott A Crosby)
Re: Re Slide Attacks (was Re: How do boomerang attacks work?) (John Savard)
Re: James Felling: Sorry to break your bubble (Anthony Stephen Szopa)
----------------------------------------------------------------------------
Date: Mon, 28 May 2001 12:52:30 +1000
From: Andrew Sullivan <[EMAIL PROTECTED]>
Reply-To: dev/null
Crossposted-To:
alt.privacy,alt.security.pgp,alt.security.scramdisk,alt.privacy.anon-server
Subject: Re: Evidence Eliminator Detractors Working Hard But No Result?
Does anybody know where I can get a copy of Spam Eliminator? These b******s are
getting beyond a joke.
EE Support wrote:
>
> Eric Lee Green is exposed for posting blatant lies about Evidence
> Eliminator. He has been proved to be lying in this debate.
>
> Don't get dis-informed - get the facts:
>
> Eric Lee Green targets Evidence Eliminator users with false web pages:
>
> http://www.evidence-eliminator.com/dis-information.shtml
>
> --
> Best Regards,
> The Evidence Eliminator Support Team
> http://www.evidence-eliminator.com/support.shtml
> --
> Technical Support Questions: Before submitting additional questions,
> please make sure you have searched the Evidence Eliminator
> KnowledgeBase online which can answer most questions instantly at
> http://www.evidence-eliminator.com/support/kb/search.shtml
>
> "Eric Lee Green" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > On Tue, 15 May 2001 23:55:25 GMT, Philip Smith <[EMAIL PROTECTED]>
> > wrote:
> > >EE Support wrote:
> > >> There are those who occupy these newsgroups who's last intention is
> talking
> > >> about facts :-)
> > >
> > >Yes, you are still here.
> >
> > I see they still have not addressed the fact of the unprofessional
> > behavior of their employee on this newsgroup, for example. Or the fact
> > of their unprofessional behavior in advertising their competitors and
> > critics.
> >
> > I have no comment about the product itself, but the company
> > has a definite image and attitude problem.
> >
> > --
> > Eric Lee Green mailto:[EMAIL PROTECTED]
>
> Eric Lee Green is exposed for posting blatant lies about Evidence
> Eliminator. He has been proved to be lying in this debate.
>
> Don't get dis-informed - get the facts:
>
> Eric Lee Green targets Evidence Eliminator users with false web pages:
>
> http://www.evidence-eliminator.com/dis-information.shtml
>
> --
> Best Regards,
> The Evidence Eliminator Support Team
> http://www.evidence-eliminator.com/support.shtml
> --
> Technical Support Questions: Before submitting additional questions,
> please make sure you have searched the Evidence Eliminator
> KnowledgeBase online which can answer most questions instantly at
> http://www.evidence-eliminator.com/support/kb/search.shtml
> >
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re Slide Attacks (was Re: How do boomerang attacks work?)
Date: Mon, 28 May 2001 03:03:19 GMT
[EMAIL PROTECTED] wrote:
>
> Tom St Denis wrote:
>
> > If I am not mistaken the Slide Attack is a birthday paradox based attack
> > where you try to find two pairs of texts that are slightly out of
> > phase... i.e
> >
> > P Q
> > R1 --
> > R2 R1
> > R3 R2
> > R4 R3
> > -- R4
> > P' Q'
> >
> > That way you know the input to R4 to form Q' was. Many feistels will
> > fall if you know the input and output (if the round function is a
> > bijection that is).
> >
> > The chances of getting this is about 2^(n/2) randomly. So against say
> > DES with 1 round key this requires 2^32 texts and trivial time.
> >
> > Tom
>
> I'm working through the "Slide Attacks" paper by Biryukov & Wagner.
> If I'm interpreting the discussion on page 3 correctly, the "fixed
> secret key" means the same sub-key is used on all rounds. Is this
> correct? Then in the 2K-DES example on page 6, only two sub-keys
> are used. I'm still trying to get a handle on how the method is
> applied to sub-keys that are related but different. Does a good key
> schedule
> defeat this attack?
Well if you have two round keys you want
R1 -- K1
R2 -- K2
R3 R1 K1
R4 R2 K2
-- R3 K1
-- R4 K2
I think..... not sure off hand, The idea is to expose the input to the
last round.
Generally if your keys are round variant then you're immune to this
attack.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Stream Cipher combiners
Date: Mon, 28 May 2001 03:45:28 GMT
Tom St Denis wrote:
>
> A while back someone suggested looking into diff combiners (other than
> xor) for stream ciphers.
>
> Why not consider my original decorrelated system?
>
> Ie generate two bytes A and B (A is a element of Z*/257 and B is an
> element of Z257) and simply do
>
> C = A(P+B) mod 257
>
> P = C/A - B mod 257
>
> The only attack I can see is forcing P to zero to get AB. In this case
> we will know whenever B is zero since A cannot be zero. If we change it
> such that both A and B are elements of Z*/257 we will never get zero and
> the result is perfectly decorrelated.
Well the best combo I can see is to use mult in Z* and addition in Z
(modulo 257/256 respectively).
Alternatively, let's consider simply
C = S[P xor X1] xor X2
Where S is some nonlinear bijection such as GF inversion (which is also
an involution).
Fixing P at zero will give us S[X1] xor X2, which is not a linear
function.
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: How do boomerang attacks work?
Date: Mon, 28 May 2001 04:36:20 +0000 (UTC)
>I'm working through the "Slide Attacks" paper by Biryukov & Wagner.
>If I'm interpreting the discussion on page 3 correctly, the "fixed
>secret key" means the same sub-key is used on all rounds. Is this
>correct?
Yes, in the simplest case. There are generalizations to the case
where subkeys repeat with some period p>1: e.g., when p=2, there are
only two subkeys, and they alternate (one subkey is used in the odd
rounds, the other in the even rounds). A small example is given in
the "Slide Attacks" paper, and many extensions are given in our
follow-on paper "Advanced Slide Attacks".
>Does a good key schedule defeat this attack?
Yes. You can view slide attacks as being an important motivation
for having a good key schedule, if you like.
------------------------------
Date: Mon, 28 May 2001 08:17:00 +0200
From: Serge Vaudenay <[EMAIL PROTECTED]>
Subject: Re: 2,2-multipermutation?
Here b_new = a xor S[ a xor b ]
and a_new = S[ a xor b ]
where S is a permutation
a_new is ok (it is a (2,1)-multipermutation)
( a_new , b_new ) is ok (it is a permutation)
but b_new is ok iff for all b, a -> b_new is a permutation
Actually, you can prove that this is a (2,2)-multipermutation iff S is
an
orthomorphism on GF(2^n) which means that both S and S[x] xor x are
permutations.
Serge
Tom St Denis wrote:
>
> To get away from politics for a bit...
>
> Does the following pseudocode define a 2,1 Multipermutation? (a,b) forms
> the input
>
> 1. a = a xor b
> 2. a = S[a]
> 3. b = b xor a
> 4. b = S[b]
>
> Where S is some bijection. assume for no entries in S does S[a xor b] xor b
> equal zero (i.e not linear enough).
>
> From what I can tell if 'b' or 'a' differs (not both) a will differ and
> 2^n - 1 of the time (assume S is a n-bit function) b will not differ ...
> hence it's not a 2,2 multipermutation.
>
> Is this true?
> --
> Tom St Denis
> ---
> http://tomstdenis.home.dhs.org
------------------------------
From: [EMAIL PROTECTED] (Scott A Crosby)
Subject: Re: The HDCP Semi Public-Key Algorithm
Date: 27 May 2001 23:29:43 -0700
[EMAIL PROTECTED] (John Savard) wrote in message
news:<[EMAIL PROTECTED]>...
> The description of the HDCP scheme at
>
> http://www.digital-cp.com/
>
> gives a simple shift-register based stream cipher that I believe to be
> quite secure.
>
> Also, an unusual scheme of allowing devices to agree on a session key
> is described.
>
> Each device has its own 40-bit public key, which it communicates to
> other devices to which it opens a channel, and its own secret key,
> which consists of 40 binary words of the length of the key that it is
> desired to establish (56 bits, but this is, I believe, an unimportant
> detail).
>
> The public keys all consist of an equal number of 1 bits and 0 bits.
>
They're not really public keys, but rather device ID's that are used to index
into an array of private device-keys. The 'equal number of 0 bits and 1 bits'
is mostly irrelevent to the weakness.
> If two devices each use the other device's public key to indicate
> which words to XOR together from its own secret key, they will both
> agree on the same session key.
>
> How on Earth could this work? What is the theory behind it? A paper on
> a weakness of this scheme, at the Cryptome site, talked about linear
> dependencies, but was heavy reading, and didn't seem to explain what I
> was interested in.
I was the author of that paper. Basically, construct the following:
Let S be a secret symmetric matrix of values in Z_{2^56}
Let the private key arrays A_keys, B_keys for two devices be:
A_keys = S * A_ksv.
B_keys = S^T * B_ksv = S * B_ksv.
What will A_keys * B_ksv and B_keys * A_ksv be?
A_keys B_ksv = (S * A_ksv) * B_ksv.
B_keys A_ksv = (S^T * B_ksv) * A_ksv.
Which are equal.
Note that S need not be symmetric if we partitian the devices into
transmitters and recievers, where transmittters do not communicate
to transmitters, and recievers do not communicate to recievers
The scheme, as given is weak, if you can get the vector of secret keys
A_keys for a sufficient number of devices with linearily independent ksv's,
you can compute S, and forge any desired device ID. With partial information,
you can still do fairly well, see the paper:
http://cryptome.org/hdcp-weakness.htm
For a description of the shared secret generation protocol, and the
weaknesses in it.
It is hard to call something broken unless you know the exact design
requirements of the mechanism. I conject that the weakness I discovered
violates the design requirments, and thus breaks the system, but cannot
prove this.
>
> Of course, it isn't a true public key system - a trusted authority, to
> generate any secret key in this system, is able to generate all the
> keys.
>
Correct. Though public key systems have an issue thats tantemount to this
complexity: How to create trusted (signed) keys, which still requires some
centralization.
> But I think I've come to a possible explanation.
>
> Each device's key pair originates from a permutation of the numbers
> from 1 to 40. The public key of each device is a vector of bits
> corresponding to the numbers 1 through 20 in the permutation.
>
This would be equivalent to an S where rows were permutations of other
rows. The actual construction of S above is more general.
>
> Still, the disguise is awfully thin. Perhaps I've missed something.
>
A lot. :)
I hope the above helps, or read the paper again. Look at the description of the
key construction protocol from the perspective of linear algebra.
The paper is dense, and HTML isn't the easiest way to see it.
My email is in the paper, please CC any replies there.
Scott Crosby
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Re Slide Attacks (was Re: How do boomerang attacks work?)
Date: Mon, 28 May 2001 08:34:36 GMT
On Mon, 28 May 2001 03:03:19 GMT, Tom St Denis <[EMAIL PROTECTED]>
wrote, in part:
>Generally if your keys are round variant then you're immune to this
>attack.
Nearly all block ciphers use different keys for each round. If the
keys vary in a regular fashion from round to round, I suppose one
could still perform a slide attack if one happened to find two
suitably related keys, although that would be a very rare
circumstance. Ignoring the practicality issue, do most block ciphers
have key schedules immune even to that form of the slide attack?
It appears that DES is immune to that attack, because of the pattern
of rotations before Permuted Choice II is applied in the key schedule.
The alternation of type A and type B rounds in SKIPJACK prevents that
attack from being applied to it, unless one slides the key schedule by
a full sixteen rounds (half the cipher). Interestingly enough, sixteen
rounds of SKIPJACK might be vulnerable to a boomerang attack.
Rijndael uses round constants which are not linear in their
relationship to avoid being vulnerable to this attack.
How about my Quadibloc designs?
Quadibloc I uses a schedule of shifts that is nonuniform.
Quadibloc II uses a key-dependent S-box, produced at the end of the
key schedule, so that a shifted key schedule would produce a different
key-dependent S-box.
This applies to Quadibloc III as well.
Quadibloc IV specifies key augmentation as a mandatory part of the key
schedule, otherwise it might be susceptible. (Key augmentation: using
intermediate results in an execution of the cipher itself to produce
subkeys that are thoroughly scrambled.)
Quadibloc V uses a key-dependent S-box, and requires key augmentation.
Quadibloc VI generates subkeys for the outer steps last, and produces
a key-dependent S-box at the end of key generation. In addition, a
MacLaren-Marsaglia construction is used to produce subkey bytes; since
this involves an initial fill follwed by an ongoing process, it is not
uniform.
Quadibloc S produces a key-dependent S-box at the end, and uses a
simplified form of MacLaren-Marsaglia subkey generation.
Quadibloc VII generates the key-dependent S-boxes first, which still
prevents a slide attack, and also uses a simplified form of
MacLaren-Marsaglia subkey generation.
Quadibloc VIII generates the subkeys for the outer steps last, uses an
elaborate MacLaren-Marsaglia construction to produce subkey bytes, and
uses information produced both before and after main subkey generation
to produce a key-dependent S-box.
Quadibloc IX also produces a key-dependent S-box at the end, and uses
a method based on the MacLaren-Marsaglia PRNG for generating subkey
bytes.
So it appears I've been lucky; in some cases I haven't really
consciously stuck anything in to make the key schedule irregular, but
it has always been complicated enough to be nonuniform anyhow.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: James Felling: Sorry to break your bubble
Date: Mon, 28 May 2001 02:16:38 -0700
HiEv wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > James Felling: Sorry to break your bubble
>
> First of all, the phrase is "burst your bubble" not "break your bubble".
>
> > Reference: OAP-L3: "The absurd weakness."
>
> And we decided to make this a new thread why? I guess you needed to
> stroke your own ego more by putting down the one guy who was posting
> decent responses to your lame ASS [that's Anthony's initials, not a
> swear word].
>
> I should also note, that after breaking off this new thread you proceed
> to try and trash the guy, but you don't even quote him once! If we want
> to follow you we now have to go back to another thread.
>
> Should I mention the lousy cross post too?
>
> > Tell me, do you have very many stupid people who pay you money for
> > expounding such logic as you have demonstrated in your past three
> > or four posts? Wait! Don't answer that right now. First read the
> > following.
>
> (gag, choke, sputter)
>
> Pot: Pot to Kettle, Pot to Kettle, come in Kettle!
> Kettle: Kettle here.
> Pot: You are black.
>
> > As you will see from looking at the first 105 permutations that the
> > first 5 digits are: 0 1 2 3 4. No matter how many times you run
> > your 105! process these first five digits of the group of 105
> > permutations will always be the same.
>
> Oh, yeah, easy to follow the context here, eh? Roughly, what was said
> earlier was that Anthony would have a problem with some numbers not
> being shuffled. His response (above) is that the suggested method would
> have the same problems.
>
> He doesn't address the possibility that his algorithm may have the same
> problem.
>
> > Now if you are aware of the way OAP-L3 works, you will know that
> > this will result in very very poor random digit output: basically
> > unusable.
>
> Which is how just about everyone feels about it in the first place.
>
> > You will also find further redundancy in the sixth digit. Over a
> > group of just 105 permutations this is unacceptable with OAP-L3.
> [snip rambling diatribe about how the suggested fix won't work]
>
> Still nothing about the existing problem mentioned by James.
>
> > I could pursue this analysis further but your suggestion of my
> > "design flaws" has turned out to be nothing more than your myth and
> > your suggestion to correct these fantastic "flaws" has turned out to
> > be a fraud.
> >
> > I sure hope everyone is listening.
> [snipped sequential list of permutations from 0 to 104]
>
> And where do you disprove the design flaw he pointed out again? I don't
> see it here.
>
> > Tell me, do you have very many stupid people who pay you money for
> > expounding such logic as you have demonstrated in your past three
> > or four posts? Wha'da ya say?
>
> If I needed someone in the encryption arena, I'd be more likely to hire
> him than you. He's maintained a level head thoughout most of this,
> while you keep going to insults.
>
> I admit I haven't been free of insults in this message, but it doesn't
> seem like you pay much attention to reason.
>
> > If you have two encryption software methods I suggest you consider a
> > corollary of Occum's Razor: choose the one that is simplest and
> > easiest to understand in its entirety over the one you cannot
> > comprehend with certainty to the fullest.
>
> Argh! It's "Occam's Razor" not "Occum's Razor", and your version seems
> to imply you shouldn't try to figure things out if you don't understand
> them. Besides, simple != secure. Neither does complex mean secure,
> thoroughly examined for weaknesses with none found suggests that it is
> secure though. However you seem to get upset when anyone says that they
> think they see a weakness.
>
> I'm glad you aren't a ship captain. "Captain, there is a leak on one of
> the lower decks!" "Have that man thrown overboard! How dare he talk
> about my ship like that. It's treason!"
>
> Nowhere in this huge insult of this message do you address whether
> James's fix is necessary, you merely attack him. That does not speak
> well of your algorithm.
>
> > (Damn, that felt good. Maybe I'm ready for Bruce?)
>
> Yes, I'm sure insulting people who attempt to make helpful suggestions
> makes you feel like a big man. Heaven forbid you should actually listen
> to someone.
>
> If your product can't take any criticism without you breaking down into
> insults, do you really think that people are going to buy/use it?
>
> --
> "Outlook not so good." That magic 8-ball knows everything! I'll ask
> about Exchange Server next.
(I posted this 24 hours ago but don't see it here so I've posted it
again.)
Actually I did post this reply to his post in the original thread.
I posted it here as well because I know that some readers haven't
been following that original thread.
(Be sure to read the last 5 lines of this reply post.)
I am not going to go back and pull out my politeness handbook but he
is the one who came up with the "nasty" flaw comment. When you start
horse playing around with a gorilla I would expect the play to get a
little rough.
I think it is significant when someone says that I have egg on my
face then gives me a suggestion to fix or improve my design then
come to find out that his suggestion is so completely bogus as to
nearly defy description although I did manage to describe why his
suggestion is all washed up.
So with my stunning proof that he doesn't know what he is talking
about with his own suggestion as to what I should do or how he has
come up with a better mouse trap, how can you continue to blindly
give his original comments anything but skepticism?
But you answered this question in your own post: "Which is how just
about everyone feels about it in the first place." (I presume you
are referring to OAP-L3.) You have chosen to "feel" instead of
think.
Don't you have a brain? Why don't you use it then? He clearly
doesn't know what he is talking about here yet you still "feel" his
original comments to be valid.
I responded that his fixed point argument is immaterial. When a
different process is run these fixed points are no more.
If his point(s) is/are valid then when the final OTPs are generated
then you can surely point out to us where and how and why these
alleged "flaws" have affected the OTP output where you can determine
something, anything, etc. (keep hoping) that you can claim has
compromised the output.
To claim there is a flaw requires that one be able to point it
out. Point out any flaw in the final OTP output as a result of these
(immaterial) "flaws." If they are immaterial then they are not
"flaws." Perhaps a better phrase would be inconsequential anomalies
or immaterial peculiarities of OAP-L3.
If you are saying that these "flaws" are material to the final OTP
output then I will ask you as I ask everyone: prove it in the
slightest sense. Give us a clue. Give us something to chew on.
The recommended use of OAP-L3 is to randomly choose the processes to
run and randomly choose what order to run them in and to input
random data into each process.
Check this out. Here are the first 105 permutations from the file
after I have run this particular process ten times with random
input for each run. Now compare this output to what JF suggested.
Array number: 0 0 1 2 3 4 5 6 7 8 9
Array number: 1 0 1 2 3 4 5 6 7 9 8
Array number: 2 0 1 2 3 4 5 6 8 7 9
Array number: 3 0 1 2 3 4 5 6 8 9 7
Array number: 4 0 1 2 3 4 8 9 6 7 5
Array number: 5 0 1 2 4 5 9 7 8 3 6
Array number: 6 0 1 2 4 6 3 5 8 9 7
Array number: 7 0 1 2 4 6 3 8 9 7 5
Array number: 8 0 1 2 5 4 3 6 8 7 9
Array number: 9 0 1 2 5 6 3 4 8 7 9
Array number: 10 0 1 2 7 5 9 6 4 3 8
Array number: 11 0 1 3 4 5 7 8 2 9 6
Array number: 12 0 1 3 4 6 2 9 5 8 7
Array number: 13 0 1 3 4 6 2 9 7 5 8
Array number: 14 0 1 3 8 6 5 9 2 7 4
Array number: 15 0 1 4 3 2 7 5 6 9 8
Array number: 16 0 1 4 3 2 8 6 7 5 9
Array number: 17 0 1 4 3 6 5 7 2 8 9
Array number: 18 0 1 5 2 3 9 6 8 4 7
Array number: 19 0 1 5 2 3 9 7 6 4 8
Array number: 20 0 1 5 2 6 3 7 4 8 9
Array number: 21 0 1 5 3 7 2 9 4 8 6
Array number: 22 0 1 5 4 9 6 7 8 2 3
Array number: 23 0 1 5 4 9 8 3 2 6 7
Array number: 24 0 1 6 7 4 8 9 2 3 5
Array number: 25 0 1 6 7 4 8 9 2 5 3
Array number: 26 0 1 6 7 4 8 9 3 2 5
Array number: 27 0 1 6 9 8 4 5 3 2 7
Array number: 28 0 1 6 9 8 7 2 3 4 5
Array number: 29 0 1 7 2 8 6 9 4 3 5
Array number: 30 0 1 7 3 6 2 8 4 5 9
Array number: 31 0 1 7 6 2 3 9 5 4 8
Array number: 32 0 1 7 6 2 4 5 9 8 3
Array number: 33 0 1 7 6 2 4 8 3 9 5
Array number: 34 0 1 7 6 4 2 3 9 8 5
Array number: 35 0 1 7 6 4 2 5 3 8 9
Array number: 36 0 1 7 8 3 2 6 9 5 4
Array number: 37 0 1 7 8 3 4 5 9 6 2
Array number: 38 0 1 8 2 9 4 5 3 7 6
Array number: 39 0 1 8 3 2 6 9 5 4 7
Array number: 40 0 1 8 3 2 7 4 6 5 9
Array number: 41 0 1 8 4 5 6 2 3 9 7
Array number: 42 0 1 9 7 5 3 4 8 2 6
Array number: 43 0 1 9 7 5 3 4 8 6 2
Array number: 44 0 1 9 7 5 3 6 2 4 8
Array number: 45 0 1 9 8 5 7 2 3 4 6
Array number: 46 0 2 1 5 6 4 9 8 3 7
Array number: 47 0 2 1 5 6 7 8 9 4 3
Array number: 48 0 2 1 6 5 8 3 7 9 4
Array number: 49 0 2 1 7 9 6 8 3 4 5
Array number: 50 0 2 1 7 9 6 8 3 5 4
Array number: 51 0 2 1 9 3 7 6 5 8 4
Array number: 52 0 2 1 9 4 5 3 8 7 6
Array number: 53 0 2 1 9 4 5 6 8 7 3
Array number: 54 0 2 1 9 5 7 8 6 3 4
Array number: 55 0 2 4 1 6 3 9 8 7 5
Array number: 56 0 2 4 3 1 7 5 9 6 8
Array number: 57 0 2 4 3 1 7 6 8 9 5
Array number: 58 0 2 4 3 1 7 9 5 8 6
Array number: 59 0 2 4 3 5 9 7 6 1 8
Array number: 60 0 2 4 3 6 5 8 1 7 9
Array number: 61 0 2 4 9 5 1 7 6 8 3
Array number: 62 0 2 4 9 5 1 7 8 3 6
Array number: 63 0 2 4 9 5 1 7 8 6 3
Array number: 64 0 2 4 9 5 1 8 3 6 7
Array number: 65 0 2 4 9 6 3 8 7 5 1
Array number: 66 0 2 5 1 7 6 4 8 9 3
Array number: 67 0 2 5 3 9 8 4 7 6 1
Array number: 68 0 2 5 4 9 8 6 3 7 1
Array number: 69 0 2 6 1 9 5 7 8 3 4
Array number: 70 0 2 6 9 3 1 8 7 4 5
Array number: 71 0 2 6 9 3 1 8 7 5 4
Array number: 72 0 2 6 9 3 4 1 8 7 5
Array number: 73 0 2 7 1 6 5 8 3 9 4
Array number: 74 0 2 7 1 6 5 8 4 3 9
Array number: 75 0 2 7 1 6 5 8 4 9 3
Array number: 76 0 2 7 1 6 5 8 9 3 4
Array number: 77 0 2 7 1 9 8 5 4 6 3
Array number: 78 0 2 7 3 1 8 4 9 5 6
Array number: 79 0 2 8 3 6 4 1 9 7 5
Array number: 80 0 2 9 4 3 8 6 7 5 1
Array number: 81 0 2 9 4 8 6 7 5 3 1
Array number: 82 0 2 9 4 8 7 1 3 5 6
Array number: 83 0 2 9 4 8 7 1 3 6 5
Array number: 84 0 2 9 4 8 7 3 1 5 6
Array number: 85 0 2 9 6 1 3 7 8 5 4
Array number: 86 0 2 9 6 1 5 3 7 4 8
Array number: 87 0 2 9 6 1 5 3 7 8 4
Array number: 88 0 2 9 6 1 8 7 5 4 3
Array number: 89 0 2 9 6 3 4 5 8 1 7
Array number: 90 0 2 9 8 6 5 1 3 4 7
Array number: 91 0 2 9 8 6 5 1 3 7 4
Array number: 92 0 3 1 8 4 6 9 2 7 5
Array number: 93 0 3 1 8 5 7 4 2 6 9
Array number: 94 0 3 1 8 5 7 4 6 9 2
Array number: 95 0 3 1 8 5 7 9 4 2 6
Array number: 96 0 3 1 8 9 7 2 4 5 6
Array number: 97 0 3 1 9 5 6 2 8 7 4
Array number: 98 0 3 4 6 9 5 1 7 8 2
Array number: 99 0 3 4 8 1 7 5 6 2 9
Array number: 100 0 3 4 8 5 7 2 9 1 6
Array number: 101 0 3 4 8 5 9 6 1 2 7
Array number: 102 0 3 4 8 5 9 6 1 7 2
Array number: 103 0 3 4 8 6 2 1 5 9 7
Array number: 104 0 3 4 9 2 5 6 1 7 8
JFs suggestion will never ever even come close to this. Every
single one of his 105 permutation groups will always have the first
5 or 6 digits exactly the same no matter how many times he runs
his process.
I seem to have concretely defended my position. If it is not clear
enough then tell us a problem you have with OAP-L3 and I will address
it further for you.
JFs suggestion that my groups are 105 permutations is misleading.
Technically this is true when you look only at one specific running
of the process. But the effect is cumulative over the entire
3,628,800 permutation set. The more the process is run the more the
effected group is expanded: the entropy over the entire permutation
set increases.
His suggestion was exactly 105 permutations long and remained so no
matter how many times he ran the process. The entropy was confined
within each 105 permutation group within the entire permutation set.
As you said, my process also shows some redundancy. This is inherent
in this process. But it does add entropy over the entire permutation
set. You can quantify the entropy. You know exactly where you
stand.
When you randomly run processes and input random data in each process
you can calculate what the output entropy is. And each process
increases the entopy over the entire permutation set.
At first glance you may not be too impressed with the above 105
permutations. Keep in mind that since you are randomly running each
process it is unlikely that you will run the Mix a Mixfile process 10
times in a row. But when you do run it it will add the usual entropy
to the output file. And it makes a big difference in what sequence
or order you run the processes in.
And keeping in mind how the permutations transform each other and
index or reference each other to generate random digit output you
will realize that the cumulative entropy and inherent inefficiency
designed into OAP-L3 will result in very good random number
distributions. There are utility programs that come with OAP-L3
that allow you to quantify the random number output distribution.
The random output numbers are excellent.
No single process was designed to randomly shuffle the entire
permutation set. Each was designed to add a modest amount of
entropy. And in combination all the processes were designed to at
least effectively reach enough of the possible key space to make
OAP-L3 practicably unbreakable: quite so.
Now keep in mind that this is just the first half of the overall
process. Once you use three thoroughly and randomly shuffled
MixFiles to generate random digits and only use about a random 70%
of these digit triplets you further thoroughly reprocess these
random number (000 - 255) files.
If you can even reasonably suggest any possibility of some sort of
flaw in the final OTP files generated, again, we would all like to
hear of it.
By the way, I wouldn't put it past JF to have made his post knowing
all along that his suggestion was bogus. He might just have wanted
to see if I was intelligent enough to see through it.
But in so doing he has heard from many of you, as well.
Cheers.
(Get a sense of humor.)
------------------------------
** 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
******************************
