| « Patented or not patented? | Simpler is Better (Cold Boot Attacks) » |
I guess the easiest way to understand and implement EnRUPT32 as a block cipher would be something like this:
#define er1(k) (rotr(2*x[(r-1)%xw]^x[(r+1)%xw]^k^r,8)*9^k)
enRUPT (u32 *x, const u32 xw, u32 *key, const u32 kw)
{
u32 r, s=4, n=s*(2*xw+kw);
for (r=1; r<=n; r++) x[r%xw] ^= er1(key[r%kw]);
}
unRUPT (u32 *x, const u32 xw, u32 *key, const u32 kw)
{
u32 r, s=4, n=s*(2*xw+kw);
for (r=n; r ; r--) x[r%xw] ^= er1(key[r%kw]);
}
Yes. This is it. A complete block cipher. There is nothing more to it. If it is used with arbitrary but constant 2n block sizes, it should be almost as fast as an unrolled implementation, almost as fast as the AES for the 4-word blocks and the 4-word keys.
Trackback URL (right click and copy shortcut/link location)
I really appreciate your feedback, guys!
Of course it is a good idea to reject an s-box with some linear bits in it when a better one can be used at the same cost, but does the entire 32-bit or 64-bit wide operation really have to be non-linear? It can be completely linearised anyway at a small cost of guessing all the carry bits and even cheaper with algebraic methods. The goal was to make that nonlinearity accumulate consistently and sufficiently by the end of the cipher.
As I wrote in the paper, I will not be surprised to see successful non-adaptive statistical attacks up to 3/4 of the cipher and successful adaptive attacks even beyond that, but not for the complete cipher. If you believe that the linear characteristics you found are iterative or potentially exploitable for the full cipher, I am all ears.