Re: Permutating keys at bitlevel good idea?

Just to make Tom upset i do state that the keyrescheduler actually
reach every possible password [but it will take a very long time Tom],
but if you just guess a password the keyrescheduler probably sooner or
later spit it out.

You may get lucky and catch in within the 10 first keyreschedulings Tom
on the other hand it really could take forever well not exact but 2^256
is an awful lot of reschedulings Tom.

Oh i need some help though Tom i would need you to estimate the optimal
byteblocksize before rescheduling and i know you have the time now ever
since " the hype regarding S-boxes dissapeared" and there is really not
any meaningful by "PLAYING" with them.

Best regards JT ;)
j...@xxxxxxxx skrev:

If someone would find it interesting to see how such a key rescheduler
would work i could fix/code one for Streambuddy.

I can't say how many unique resheduled password such a resheduler
actually would create.
But the password-bit rescheduling could be rearranged in 256! ways,
they would not be unique of course but since we here work with a
savestate and a permutatoin reverse there may actually be more
resheduled keys than the initial permutation rkeys>256! i leave that to
the mathematical inclined to find out.

But i actually think that is the case due to the lagging savestate....

BR No1 ;)
jt64@xxxxxxxx skrev:

To find out password state inv password state and savestate pw from
keysheduled password would actually be as hard as bruteforce each
keysheduled key.

It maybe not a oneway function but to "break down"/reverse the output
xor into the three bitstreams to break the keyschedule, must actually
be as hard as bruteforce the cipher, since the encoding principles fore
password share same encoding principles as the permutation byte PRNG
that is used to XOR the plaintext.

Wouldn't it?

JT
jt64@xxxxxxxx skrev:

How about this for resheduling a password (the bitpermutation is based
upon password) see streambuddy but with bytes.

[init]->
password^invpassword=savestatepw
permutate password at bitlevel
permutate invpassword at bitlevel

[while more passes/byteblocks to reshedule]->
password^invpassword^savestatepw=keysheduled password
password^invpassword=savestatepw
permutate password at bitlevel
permutate invpassword at bitlevel



for the last permutation could be used to serve when xor the new one.
t64@xxxxxxxx skrev:

Could it be a good idea working with bitpermutation at key?
When rescheduling key?
I know how to do it at low cost but is it a good idea, what is the
optimal bytelength before rescheduling key, if we play with the thought
that it is used for a cipher with the heart in a 256 byte permutation.

I understand that distributions of 0 and 1 will render different many
unique solutions if used strictly with permutation so maybe a XOR of
password during keysetup would be beneficial


JT

.