# Improving differential cryptanalysis of a vulnerable cipher

How to avoid differential cryptanalysis attacks when you are inventing new cipher?

Let's say you have a $$16$$-round $$128$$-bit cipher vulnerable on differential cryptanalysis attacks. Now let's say you will add between every round:

• bitwise NOT (optional you make it ot not - randomly),
• xor with $$128$$-bit subkey,
• moving bits by $$0$$ to $$127$$ places.

Now it looks like the attacker have to guess many variables first (we defined it by keys), to make differential cryptanalysis attack. Because he can do it easily only without this obstructing steps between rounds. Is it good idea to use it, if I would like to make cipher resistant on differential cryptanalysis?

## 1 Answer

Your cipher seems quite vulnerable to side-channels the way you describe it. Also, differential cryptanalysis depends mostly on a secure S-box. The steps you describe are superficial, since they don't effectively destroy patterns.

Assuming you're using an SP-network, which is generally what a 16-round block cipher would be, let's see what the steps are to perform encryption:

For each round, you

1. Perform the nonlinear operation (S-box) on the plaintext
2. mix the key with your intermediate ciphertext
3. permutate the bits of your immediate ciphertext, providing diffusion

Your obstructing steps are:

• bitwise NOT (optional you make it ot not - randomly),

A bitwise NOT destroys no patterns and provides no nonlinearity Deciding randomly whether to perform this operation only adds 1 bit per round, and makes side-channels that much more likely. This step is pretty much useless while adding potential for faulty implementation.

• xor with 128-bit subkey,

You should be mixing the round key anyway. I don't see how this is any different from a normal round cipher.

• moving bits by 0 to 127 places.

This could add 7 bits of security per round... maybe? but would be near-impossible to implement without allowing side-channel attacks. Data-dependent memory accesses are a really bad idea (I assume the amount you move the data would depend on the key, the plaintext, or some wacky logic based on both; this would immediately allow side-channels).

If, however, you mean to move the bits by some predefined amount, congratulations! You've implemented a P-box... Which you should be using anyway, considering you're making an SP-network.

### In short,

If you want to resist differential cryptanalysis, the real solution is to design the nonlinear component (S-box) in a way that isn't vulnerable to differential cryptanalysis. Perhaps you could steal the S-box from AES since it's already well-understood?

Addendum: Make sure to defend against slide attacks! Your key cycle should be decently designed, as well, and side-channel attacks are horribly easy to accidentally allow in your implementation.

• I got many comments. First - key schedule is as strong as 2B or 2C here, because it is almost identical to main cipher (but again it is vulnerable to differential cryptanalysis attacks, if I won't fix it). Kind of similar to Speck (the Speck key schedule uses the same round function as the main block cipher). So it could be resistant to slide attacks. Key schedule classification: crypto.stackexchaange.com/questions/33975/… – Tom Sep 29 '20 at 0:40
• Second - I'm using practically nonlinear functions in every inch, but they got only one simple defect, one type of linear properties. And it make possible one type of differential cryptanalysis attacks (I know exactly what differential the attacker can use). So I have to prevent this kind of attack. Bitwise NOT destroys no patterns - but it is one bit to guess + moving bits, we got 8 bits to guess, so in $16$ rounds attacker have to guess $128$-bit number, to make known differential cryptanalysis attack. So even if we don't destroy patterns - it could be enough. – Tom Sep 29 '20 at 0:55
• I actually wrote an encryption algorithm that uses a similar principal as your bitwise NOT idea, except it applies it in a nonlinear way... You could take ideas from my algorithm. – Serpent27 Sep 29 '20 at 1:02
• Third - amount that I move depend on $265$-bit key schedule cipher which works on $128$-bit key. This key schedule cipher first takes $128$-bit key (expanding it), to make $16$ rounds. Then it splits main $128$-bit key into $16$ $8$-bit inputs. Now it produces $16$ $265$-bit keys for every of $16$ round (we split that $265$ into specific round keys). So amount that I move the block depend on the key, but it is not wacky logic based - it is just cipher in cipher (key schedule is cipher by his own). – Tom Sep 29 '20 at 1:09
• So amount thaht I move the block depend on the key, but it is not wacky logic based you're still opening yourself up to extremely hard-to-fix side-channels. Data-dependent permutation means data-dependent memory accesses. Data-dependent memory access mean broken implementation. – Serpent27 Sep 29 '20 at 1:13