Re: New RUIX cipher

• Previous message: David Wagner: "Re: hash function"
• In reply to: toorandom_at_gmail.com: "New RUIX cipher"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 21 Feb 2005 15:26:31 -0800

Thanks for the comments.

About the rounds .. yes i think you are right.. but well , i decided
to put 3 rounds minimum because of the implementation , at
mathematical level , it could be great , but what happen if its
planned to be a standard (i know my cipher is very very far of being a
standard) but , i thought in a fast computation , how many rounds do
you recommend using my scheme.

About the differential analysis

Yes , i thought in that , after publishing this... , im just thinking
how can i make more secure, without being slow.. , i think , i need
to implement another transformation after key addition , or.. what do
you recommend using my scheme ?

Thanks for the comments i apreciate that.

Eduardo Ruiz Duarte

"toorandom@gmail.com" <toorandom@gmail.com> wrote in message news:<1108934964.232160.96060@o13g2000cwo.googlegroups.com>...
> Hi im just interested in modern cryptology , and i made something , but
> i want an opinion from experts, i made some statistical analysis but ,
> i would like other opinions. im a student of mathematics in the first
> year, and i was reading some books related to the design of rijndael
> and other algorithms , finite fields , etc.. my algorithm is like a
> feistel cipher , i made some tests , and i think is not too bad , but
> you are the experts ,
>
> C implementation can be found in
>
> http://www.badc0ded.org.ar/files/C/betaruix/
>
> The implementation has a main() routine that calls the encode function
> , to encode a file from file system using a file descritor and reading
> 64 bytes of the file on a loop , and writing the output .
>
> compile in this way with gcc , or use your favorite compiler.
>
> shell$> gcc cook_key.c ruix.c -O3 -o ruix
>
>
>
> 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...

• Previous message: David Wagner: "Re: hash function"
• In reply to: toorandom_at_gmail.com: "New RUIX cipher"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]