potential break or real break?

since my last thread, a month or so ago, after taking into account the
things discussed and suggested, i have revised my equation twice. In my
attempt to describe them i will be using code for the things i don't know
how to represent in notation. In the first revision i am using 2 IV's called
oddly enough, IV and IV2. each IV is derived the same way from different
sources. Please note that this is a stream and therefore works with 1 byte
at a time.

hashednonce = SHA512(passphrase & nonce)

hashednonce is stored for a later use.

a practical OTP is then defined using the hashednonce in the following way

keyfragment = hashednonce
counter =1
do until Kstring = len(message)
if counter = 16383 then
SHA512(keyfragment)
keyfragment = f(keyfragment)
Kstring = Kstring & keyfragment
counter = 1
else
keyfragment = f(keyfragment)
Kstring = Kstring & keyfragment
counter ++
end if
loop

the counter allows for every bit variation within a 512 bit key fragment,
once the counter limit has been reached the last used keyfragment is
rehashed and the process continues until the length of the message is
reached.

The permutation function is defined as the following.

keyfrag = keyfragment
Lshift = left(keyfrag,1)
Lshift = asc(lshift)
Lshift--
Lshift = Abs(Lshift - 256)
Lshift = chr(Lshift)
Rshift = right(keyfrag,len(keyfrag)-1)
keyfrag = Rshift & Lshift
for n = 1 to 64
mid$(temp,n,1) = hashednonce[n] XOR keyfrag[n]
next n
keyfragment = temp

The key creation and permutation sequences have remained almost static
almost every revision made.

As mentioned above the cipher uses two IV's, i will describe the last two
revisions made, starting with the first revision made since my last visit
here, and why it is flawed.

Each IV uses three sequential ascii codes concatenated to the one before in
a long integer variable, these ascii codes are dynamic and change throughout
the cipher process. for example IV will be K[1,2,3] for the first round. for
the secound around the IV will be K[2,3,4] and so on and so forth through to
the end of the internal state.

IV2 however is a little different as the source from which is it derived is
substituted with a 512 bit block of ciphertext after every 64th character is
processed. the method is the same, the source isn't.

In he first revision the cipher was c[i] = P[i] xor ((IV xor IV2) modd 256)
this is the same as saying ((IV mod 256) xor (IV2 mod 256)). It soon became
apparent that if an attacker knows P[i] that they could derive the mod value
of IV2 by a bitwise XOR with P[i] and the mod value of IV and vice versa.
Does this constitute a real break or a potential break? and does this fall
under a known plaintext attack?

The second revision is slightly moer complex and I hope to have elilminated
the above flaw.

The initial value of IV and IV2 are derived the same way, how they are used
has changed.

c[i] = P[i] xor ((((IV mod 256) ^2) xor ((IV2 mod 256) ^2)) mod 256)

I have yet to detect the same flaw or any other flaw in the second revision.


.

Relevant Pages
Quantcast