Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: David Taylor <davidt-news@xxxxxxxxxx>
- Date: Wed, 7 Feb 2007 17:32:33 +0000 (UTC)
On 2007-02-07, jt64@xxxxxxxx <jt64@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.
rossum
Keyexpanded shuffles/permuation ciphers are not key to block 1:1
ciphers.
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.
*THIS IS A STREAM GENERATOR OUTPUT IN BLOCKS OF 256 BYTES, THE STREAM
IS BASED ON AN EXPANDED KEY*
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.
If they test every key, they will get every keystream. There is no
need to test all the other keystreams that your algorithm cannot
generate.
--
David Taylor
.
- Follow-Ups:
- References:
- Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: jt64
- Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: rossum
- Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: jt64
- Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: David Taylor
- Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- From: jt64
- Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- Prev by Date: Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- Next by Date: Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- Previous by thread: Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- Next by thread: Re: Key entropy, stream entropy, block entropy, block population entropy AKA uniique stream length
- Index(es):
Relevant Pages
|