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

On 9 Feb, 01:26, "r.e.s." <r...@xxxxxxxxxxxxxxxx> wrote:
<j...@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 ...

It certainly is not on my behalf.

Although there *are* many ways to create a large-size block within
the keystream,

Well you are very unclear you mean there are many ways to create any
blocks from within the keystream or do you mean there are many ways to
create a unique block from within the keystream.

Because it is *both* of above, there are many different blocks, and
there are many identical unique blocks created from different internal
states in the manner below for *ONE KEY* and only *ONE KEY*

KEY(X)
OUTPUT_PRNG(D),
BUFFER_PERM(A)
BUFFER_PERM(B)
BUFFER_PRNG(C)

Algoritm
A=Expand X
B=ReverseA

START loop
SHUFFLE A,B
C=A^B^C
D=^C
PRINTF D
(IF YOU USE IT FOR ENCRYPTION WOULD BE WISE TO)
PLAINTEXT=^D
END loop

How hard could the above me to understand???

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.

You just did go from being plain silly, to annoyingly stupid.
A and B are the expanded key X.
You do not need any other key A and B changes during the shuffle
algorithm

The key for the overall cipher includes
*all* of such key material needed by the decryption function.

No the key is the original key, rest is part of the *ALGORITHM*
The *ALGORITHM* is not the key, and will never be

END OF STORY

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.- Dölj citerad text -

You are dreaming again the *ALGORITHM* is not part of the *KEY* and
will never be.
A *KEYEXPANSION* of X to create A does not make A the key.
A *SHUFFLE* of A does not make A the key.

Is there no end to your stupidity?

I tried to explain this in a very nice manner, but now i am not sure
what you are up to?
Tell me exact which of the steps above you have a hard time to
understand, and i may be able to help you.

If you just here to obfuscate the algorithm *** off.

Jonas Thörnvall


- Visa citerad text -


.