Dear all,
We have just developped a new block cipher called Raiden, following a
Feistel Network structure by means of genetic programming. Our
intention now consists on getting as much feedback as possible from
users, so we encourage you to test the algorithm and send us your
opinion. We would also like to receive enhancements and new versions of
the algorithm, developed in other source languages and platforms.
Our idea on developing this cipher is to propose it as an alternative
to TEA block cipher. TEA is a very interesting cipher with lots of real
applications. It is very simple and fast, and it reaches an acceptable
level of security by the application of a lot of cycles.
Nowadays TEA has been broken, and several weaknesses of the algorithm
have been discovered. Since most of these weaknesses are related to its
Key Shedule routine, the authors, Roger Needham and David Wheeler
proposed an extended version of the algorithm with a more complex one.
This new version, which they called XTEA, did not have the expected
success of its antecessor, in part because it is slower.
The algorithm known weaknesses, as well as its popularity, have made us
to think it was the time to develop an alternative to TEA. This
alternative, presented in this page, must have the next features:
* It must be as quick as TEA, to be used in the same real world
applications
* It must be stronger, to avoid TEA weaknesses
To develop this new block cipher we have used a genetic
programming-based technique. More on this to follow in a coming
scientific paper.
Description of Raiden
----------------------------
Raiden is a very small and compact cipher. It works with blocks of 64
bits and keys of 128. As it can be seen below, the algorithm has the
same main structure as TEA: it is structured in cycles, where one cycle
contains two feistel rounds, and for both of them, the same round key
is used. In each round, the output of the round function on a sub block
is used to feed the other one. The round function of the algorithm has
the same size as TEA's one, but, as commented in section Raiden
Strength, it seems to be stronger.
The Key Schedule routine is more complex than TEA's, but it is simple
enough to not overload the cipher execution time. To maximize the
entropy introduced by this function, in each round, its output feeds
the position i%4 of the key array. This makes the key array passed to
the function to evolve as the algorithm is executed, and thus
generating new round keys for each cycle with that 128 bit array. This
also makes that function to behave much as a PRNG. After analyzing the
algorithm, as commented in it homepage
(
http://raiden-cipher.sourceforge.net/ in the Results section), we
propose the execution of sixteen cycles. Below, the code of Raiden
encoding routine is shown.
void raiden(unsigned long *data,unsigned long *result,unsigned long
*key)
{
unsigned long b0=data[0],
b1=data[1],i,k[4]={key[0],key[1],key[2],key[3]}, sk;
for(i=0; i< 16; i++)
{
sk=k[i%4]=((k[0]+k[1])+((k[2]+k[3])^(k[0]<<k[2])));
b0 +=((sk+b1)<<9)^((sk-b1)^((sk+b1)>>14));
b1 +=((sk+b0)<<9)^((sk-b0)^((sk+b0)>>14));
}
result[0]=b0;
result[1]=b1;
}
The cipher receives the plain text in 'data' parameter, and puts the
cipher text in the 'result'. Key contains the 128 bit cipher key.
The cipher follows a Feistel structure, so the decoding is made in the
same way than the encoding but applying the round keys in the inverse
order. This is the Raiden decoding routine.
void decode_raiden(unsigned long *data,unsigned long *result,unsigned
long *key)
{
unsigned long b0=data[0],
b1=data[1],i,k[4]={key[0],key[1],key[2],key[3]},
subkeys[16];
for(i=0;i< 16;i++){
//Subkeys are calculated
k[i%4]=((k[0]+k[1])+((k[2]+k[3])^(k[0]<<k[2])));
subkeys[i]=k[i%4];
}
for(i=15; i!=-1; i--)
{
//Process is applied in the inverse order
b1 -= ((subkeys[i]+b0)<<9)^((subkeys[i]-b0)^
((subkeys[i]+b0)>>14));
b0 -= ((subkeys[i]+b1)<<9)^((subkeys[i]-b1)^
((subkeys[i]+b1)>>14));
}
result[0]=b0;
result[1]=b1;
}
In this case, the function receives the ciphertext in the 'data'
parameter and puts the plain text in the 'result'. The round keys are
calculated at the beginning of the function, and then they are applied
in the inverse order as they were when ciphering.
The algorithm is free to anyone, and has been developed in ANSI C
source code under Linux.
We propose you to develop new versions of it using other programming
languages and platforms.
Raiden Strength
---------------------
The main weaknesses of TEA, such as the Related Key Cryptanalysis, or
the equivalent keys, are related with its Key Shedule routine. Thus,
one of the main objectives when developing this new cipher has been to
develop an stronger Key Shedule function than TEA's.
The function developed is also very simple, but not as much as TEA's.
TEA Key Shedule function consists only on adding a constant
(0x9e3779b9) to a variable. Thus, it is very simple to, knowing the
round key of cycle i, obtain the keys corresponding to the previous and
the following cycles. This is not the case in our algorithm, in which
doing so it is not a trivial problem.
Therefore, the Key Shedule function behaves more as a Hash Function or
pseudorandom number generator, and does not have the same weaknesses as
TEA Key Schedule. Raiden's Round Function provided much better results
in the statistical tests than TEA's one, so we can conclude it is also
stronger, and, therefore, that the whole algorithm is also stronger.
When we analyzed the algorithm using the statistical tests ENT,
Diehard, NIST and Sexton, we realized that Raiden results when applied
16 cycles were, in many ocassions better, and at least comparable, to
TEA results when applied 32. This made us to conclude Raiden is
stronger than TEA and that 16 cycles would be an enough security margin
for the algorithm to be applied. The mentioned results can be consulted
in the Results of statistical tests on Raiden section at
http://raiden-cipher.sourceforge.net/
About the Authors
------------------------
Raiden has been developed by:
Julio Cesar Hernandez Castro, e-mail: jcesar_at_inf_dot_uc3m_dot_es
Javier Polimon Olabarrieta, jpolimon_at_gmail_dot_com
Don't hesitate to contact the authors with your feedback.
Similar Threads
