Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length

On 2007-02-08, jt64@xxxxxxxx <jt64@xxxxxxxx> wrote:
On 8 Feb, 15:06, "John Hadstate" <jh113...@xxxxxxxxxxx> wrote:
On Feb 8, 7:57 am, j...@xxxxxxxx wrote:

I claimed there is more (entropy) in the ways to create a specific
output (PRNG block) from the internal states. Then there is entropy in
the key (making cryptanalysis futile), bold statement i know, but i
think that is the fact and why cryptographers refuse plain facts.

Your claim is, as one previous respondent said, patently absurd. Look
at the following example.

I have a two-bit key, which can take on values 00, 01, 10, or 11. I
establish a mapping to a key-stream (your "permutations") as follows:

Key Key-stream
00 00100001000111100010111
01 10101000001101110001101
10 01111100001010100001110
11 10101010000010101000011

Now I encrypt with the key-stream. The recipient (and the attacker)
both know how to map the keys into key-streams, and to brute-force
this cipher, the attacker only has to choose one of four key-streams.
It doesn't matter how long the key-stream is (which determines how
many permutations there are), these key-streams have only TWO BITS of
entropy and nothing will change that.

Now, you say, "But those key-streams (permutations) are not the only
set of four that are possible." That is true. You could define
another set of 4 permutations, but how would the sender and the
recipient know which set of 4 to choose? You must add one more key
bit to choose between the two sets of four. Now how many bits of
entropy are in the chosen key-stream? THREE BITS, and the attacker now
has to choose from among 8 permutations.

The only way you can get more entropy into the key-stream is to add
more unpredictable bits to the key upon which the key-stream depends.
If you try any other way of adding entropy (such as randomly re-
mapping the permutations themselves), the legitimate recipient will
not be able to decipher the message (using the key alone).

The game you are playing is to pretend that the attacker doesn't know
how to map key bits into key-streams. That violates one of the basic
rules of modern crypto.

Ok i try to give a simplified byte example although i am not sure i
can convince any of you at this point.

Blocksize 10 bytes [10!]=3628800
Keysize 2 bytes [2^8]=256
Expanded key=Shuffleblock 3,6,9,1,4,7,2,5,8,10
Reversed shuffleblock 10,8,5,2,7,4,1,9,6,3

Do you agree that the shuffle length is 10! unique *blocks* if the
shuffle algorithm reach every position?

IF it reaches every position. How CAN it reach every position, if
it only has a 16 bit key?

This gives 3628800 blocks unique blocks when combined just the XOR of
the two shuffles agreed?

Given that the PRNG BUFFER truly is random it could contain one of
2^80 different unique values agreed?

Frankly, I've lost track of what you're talking about and I can't find
your original post where you explain this. How do you seed this PRNG?
How do you decrypt without transmitting the seed to the other end?

Given that the actual period of the stream PRNG OUTPUT BLOCKS could be
10! * 2^80
(This is if there is a different value in the PRNG BUFFER each time
the permutation cycle reach it end, and i can not prove this but i
think it will be)

It "could" be, but it could also NOT be that. Simply saying "I think
I'm right" will not convince anyone who is arguing strongly that you
are wrong.

Now the question arise for one specific PRNG OUTPUT how many ways are
their to create it using the XOR together shuffles, that are XOR with
the PRNG BUFFER in the manner.
PRNG OUTPUT=SHUFFLE^RSHUFFLE^PRNGBUFFER.

I claim that for any XOR together shuffle there can be a free to chose
value in the buffer.

What is "a free to chose value in the buffer"? What effect does it have?

So what i basically claim is that the way to create any PRNG OUTPUT is
10!

What?

10! is certainly a bigger number 2^8 the key entropy

Yes, it's a bigger number. It's not in any way a measure of the entropy
in your expanded key, but it's a bigger number.

--
David Taylor
.

Relevant Pages