Ruix0.1 Cipher Specifications
Eduardo Ruiz Duarte
rduarte@ciencias.unam.mx
512 bit per block
256 bit key length
a matrix of 8x8 is filled with plain data
A transposition of the data is applied then each element of the matrix
is evaluated with a non linear box generated with genbox.c , the box was designed
with correlation prevention , confusion and difusion and other related tests
Rounds are calculated taking 3 bits of the key expansion and computing 2x+1 where
x is the value of the 3 bits got.. so minimum i have 3 rounds and max 17 rounds
(need to be a odd number because of the transformation process (transposition is pairing) )
The keyspace is linear (256 bits) this means that all keys are strong in the ciphertext, and the cook_key routine expands this ..
(key is unsigned short and minimum i need 144 bits) for expansion to 256 bits
(key is "short" type)
for(i = 0 ; i < 9 ; i++ )
{
key[(i+1)%9] += ((key[i]+(key[(i+1)%9]+(j+i))) | 0xff)%0xffff;
j--;
}
This is just
ki+1 mod 9 = ki+1 mod 9 + (ki+ki+1mod9) + (j+i)) + 256 mod 65535
after this expansion , i compute the expansion of the rest (112 bits)
and 16 bits more for the rounds and only if needed.
so 128 bits are expanded from the key.
The structure of the key is
typedef struct key_t
{
unsigned int s,t,u,v,w,x,y,z;
unsigned char rd16[2];
unsigned short k;
}ruix_ctx;
This is because the key is evaluated again with the non-linear box , that difuses the key ..
a transposition is calculated too... with the key , soo the key is non-linearized..
the purpose of this is to generate a pseudo-random generation of the key to omit linear
combination and intersection of the transformations between blocks be empty
finally in each round i xor the key with the corresponding plaintext 512 bits with 256 bits
i make key addition xoring the corresponding 4 byte key with plaintext integer..
the other half of the plaintext is being xored again but mixing the key with the next part of the key. i mean
B is an integer array containing the plaintext data each element if 4 bytes
b[0] ^= key.s;
b[1] ^= key.t;
b[2] ^= key.u;
b[3] ^= key.v;
b[4] ^= key.w;
b[5] ^= key.x;
b[6] ^= key.y;
b[7] ^= key.z;
b[8] ^= key.s ^ key.t;
b[9] ^= key.t ^ key.u;
b[10] ^= key.u ^ key.v;
b[11] ^= key.v ^ key.w;
b[12] ^= key.w ^ key.x;
b[13] ^= key.x ^ key.y;
b[14] ^= key.y ^ key.z;
b[15] ^= key.z ^ key.s;
Key is generated in the same way when decoding and encoding...
no matter the order , still being computed with a self inverse function.
this is a problem when i permute the key per round , but this is gonna be implemented in other versions of this algorithm
for now key is changed per block. and the entropic keyspace will be generated first.
Structure of rbox and irbox
rbox(irbox(x)) = x
rbox is a nonlinear bijective function it goes from f: A->A A = { 0,1,2 ..., 255 }
it was generated with genbox.c , it finds correlation , difussion , and confusion....
the purpose of this is to randomize the plaintext before being computed the key addition..
7 rounds produced very nice results , media of the data is 127.8 aprox. ,
compression algorithms over the data encoded produces bad results because it can find
correlation between data, the purpose of this is to evade atacks using low level cryptanalysis
and index of coincidence checking... ,
this boxes are mappings over a finite domain & can be represented by polynomial functions
with a finite number of terms using tools like lagrange interpolation for modeling the algebraic structure.
If you wanna see a ZERO file of 65535 bytes ciphered with a trivial password (AAAA)
is here
http://www.badc0ded.org.ar/files/unsorted/
the name of the files is
cero.RUIX-HEX.txt 19-Feb-2005 01:12 160k
cero.RUIX.txt 19-Feb-2005 01:11 64k
cero.txt.bz2 19-Feb-2005 01:12 65k
cero.RUIX-HEX is a hexdump of the file
cero.RUIX.txt is the file
and cero.txt.bz2 is cero.RUIX.txt with a high quality compression algorithm (bz2)
just for looking that is bigger than the not compressed file.
note: the programm is embedded with a main() routine that uses the encode() function to encode data coming from a file descriptor allocated in a char buf[8][8] array on a loop
it was compiled in UNIX, i hope it will work
genbox.c has unistd.h just to satisfy the declaration of some functions but you can
delete the line including this , if you have microsoft windows
another thing is , i didnt put a padding function , so if the file is not multiple of 64
it will put trash at the final of the file in the decoding process...
sorry i know this is a bad programmer issue , but i had to finish it and that is not part of the algoriothm , but soon ill put with PKCS5 padding...