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

On 7 Feb, 18:32, David Taylor <davidt-n...@xxxxxxxxxx> wrote:
On 2007-02-07, j...@xxxxxxxx <j...@xxxxxxxx> wrote:

On 7 Feb, 14:14, David Taylor <davidt-n...@xxxxxxxxxx> wrote:
On 2007-02-07, j...@xxxxxxxx <j...@xxxxxxxx> wrote:
On 5 Feb, 23:26, rossum <rossu...@xxxxxxxxxxxx> wrote:
On 5 Feb 2007 09:36:28 -0800, j...@xxxxxxxx wrote:

I said that the "BLOCK ENTROPY" within a cipher AKA the way to create
a UNIQUE block by downmixing internal streams in a cipher can exceed
the keyentropy.

Then how can you decrypt a message? If the block entropy exceeds the
key entropy, then given the key the receiver cannot decide which of
the possible blocks the key can generate is the correct block to
decrypt with.


Keyexpanded shuffles/permuation ciphers are not key to block 1:1
They are key to stream 1:1 ciper

So there is really no problem, you have to know where you are in the
permutation cycle for the key that is all.

Then that's all an attacker needs to know to decrypt it too.

Now you are lying *BIG* and i am pretty sure you are aware of it,

You can not find out the other permutation vector, using the known one
you can not reverse the algorithm to find an earlier block backtrack.
You have no idea of the offset startvalues for the algorithm,

Look. If your intended recipient can decrypt the message purely using
your algorithm and the secret key, so can any attacker.

If your attacker needs more information, so does your intended recipient.

If you transmit that information secretly, it's equivalent to being
part of the key.

And most important of all you do not have any idea of the value in the
PRNG buffer.

If I (the attacker) don't, how does anyone else?

How do you communicate this information to the other end without telling
the attacker? (Hint: if you do it secretly, it's essentially part of
the key)

There is no information to communicate, so there is no hint and you
probably missunderstod the subject or are deluded

If you think that an actual shuffle of a deck of byted need anything
to put out a new shuffled block you are misstaken, it doesn't even
need a counter.


We do not need to communicate any extra entropy or information just
the original KEY so both parties can generate the stream.

If you are expanding the key without "any extra entropy" it must
be deterministically expanded. There is no new entropy, thus anyone
with your (public) algorithm can use the (secret) key to derive this
amazingly pointless keystream.

Yes anyone who have the original key can create the expanded key, find
the offset values of the permutations and the offset value of the PRNG

I do not know any cipher there it would make sense for this not to be
possible, do you?

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.

It is better to try to bruteforce the key and regenerate the original
keystream that is why you should use a time factor within the

(Resistance is futile you will be assimilated, we are the Borgs)

If they test every key, they will get every keystream. There is no
need to test all the other keystreams that your algorithm cannot

Yes of course they can store 2^256 *initial unique
blocks(keydependent)* of the (PRNG OUTPUT "BLOCK") once you expanded
the key, reversed the key creating a mirror shuffled them and XOR them
together, to create the initial state of the PRNG buffer.

It will take some time though.... and i do not think you have the
storage for 2^256 * 2048 bit.

But of course you are right in that given *RIGHT KEY* every cipher is
The bruteforce time for ciphers with same key entropy differs though
it depends on the time it takes to complete the keysetup and generate
first outputblock. For stream ciphers it would be the the time it
takes to initialise and generate the first outputblock of the stream.
David Taylor- Dölj citerad text -

- Visa citerad text -- Dölj citerad text -

- Visa citerad text -


Relevant Pages