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

<jt64@xxxxxxxx> wrote ...
"John Hadstate" <jh113...@xxxxxxxxxxx> wrote:
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.

I never claimed there was more keystreams than entropy, i claimed a
2048 bit block within the keystream could be created in more than ways
then the key have entropy, it is a totally different issue.

It looks to me as though there's a lot of confusion involving misuse
of the word "KEY". I think others have already tried to explain this
to you, but let me give it a try ...

Although there *are* many ways to create a large-size block within
the keystream, the decryption function will then require not only a
key for the keystream, but *also* a key for producing that large-size
block from the keystream. The key for the overall cipher includes
*all* of such key material needed by the decryption function.

Can we agree on that the ways to create one block of 2048 bits PRNG
OUTPUT from the internal states can be done in more ways then the KEY
have entropy?

Only if your "KEY" is understood to be merely *part* of the decryption
key (and so is misleadingly put in all caps) -- the rest of the key
includes material that determines exactly which of the many ways is
chosen to process the keystream.

Relevant Pages