Re: Permutating keys at bitlevel good idea?

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

.

Relevant Pages
Quantcast