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...