Re: New RUIX cipher
From: Matthew Fisher (matthew.fisher_at_convergys.com)
Date: 02/21/05
- Next message: Bill Leary: "Re: Thou shalt have no other gods before the ANSI C standard"
- Previous message: prep_at_prep.synonet.com: "Re: [Lit.] Buffer overruns"
- In reply to: toorandom_at_gmail.com: "New RUIX cipher"
- Next in thread: Eduardo Ruiz: "Re: New RUIX cipher"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 21 Feb 2005 09:52:40 -0800
Eduardo,
I love amateur ciphers thanks for posting. I believe your cipher has
some flaws perhaps you can change my mind :-)
I think we can push a 'differential' through your cipher with a 100%
probability.
Here is my thought, take two plaintexts whose exclusive-or looks like
x000 0000
0000 0000
0000 0000
0000 0000
0000 0000
0000 0000
0000 0000
0000 0000
The 'x' can be any value basically two plain texts that vary only in
the first word. Now let's see what happens when the text go through the
encode.
First we 'transpose', which leave the exclusive-or matrix the same.
Then we do a non-linear s-box substitution which also leaves the
exclusive-or matrix the same. Then we add the same key to both
plain-texts which also leaves the exclusive-or matrix unchanged. Then
we are at the top of the next round. Sooo, it appears that a
differential will go right through.
With such a differential we may be able to recover the key and we can
certainly distinguish the cipher from a random permutation.
Your cipher is AES like but is missing the mix columns step. This is a
diffusion problem. See Biham et al differntial attacks on DES.
Have fun,
Matthew
toorandom@gmail.com wrote:
> 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...
- Next message: Bill Leary: "Re: Thou shalt have no other gods before the ANSI C standard"
- Previous message: prep_at_prep.synonet.com: "Re: [Lit.] Buffer overruns"
- In reply to: toorandom_at_gmail.com: "New RUIX cipher"
- Next in thread: Eduardo Ruiz: "Re: New RUIX cipher"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
