## 1 Introduction

Encryption technology is being used in a large number of applications today, and many different encryption algorithms have been proposed for use in various environments. Security is always the most important consideration for a cryptographic primitive. This is achieved through cryptanalysis, where we try to find ways to break the security guarantees given by the designers. For symmetric ciphers this is usually equivalent to finding a secret key faster than doing exhaustive search on the secret key.

Several cryptanalytic techniques can be tried when assessing the strength of a cipher. In this paper we will focus on algebraic cryptanalysis, characterised by formulating the attacker’s problem as solving a system of equations. Representing a cipher as an equation system can be done in several ways, and over different fields. In this paper we will only be concerned with the binary field

### Our contribution.

It is easy to join all the individual MRHS equations into one matrix/vector multiplication with a (large) right-hand side set of potential solutions. We call this the joined system matrix. We show which linear operations we can do on the joined system matrix without changing its solution space, and without increasing the space complexity of the right-hand side set. This allows to bring the joined system matrix into a special form, allowing for fast execution of a simple brute-force solving algorithm. We describe a recursive algorithm using a guess/verify approach for solving a joined MRHS system and explain its complexity.

In the last part of the paper we test the algorithm on some well-known block ciphers and show that the analytic complexity estimates match the observed complexities very closely. One interesting observation we make is that for some of the proposed variants of LowMC [1] using very few S-boxes, we can actually do encryption via the MRHS solver faster than in the standard reference implementation. This can be explained with the fact that there is a very high number of linear operations compared to the number of non-linear operations in these versions. The joined MRHS representation merges all the dense linear layers in LowMC into one big matrix, and in total there are less XORs to be done working on this matrix than executing the round-by-round linear layers in the standard specification.

## 2 Preliminaries

We denote the finite field with two elements as *p* is clear from the context, we may just write

A Multiple-Right-Hand-Sides (MRHS) equation over

where *l*-bit vectors. We say that

A system of MRHS equations *m* MRHS equations with the same dimension *n*, i.e.

where each

Throughout the paper, *n* will always denote the number of variables in an MRHS equation system, and *m* will always be the number of equations in the system. The length of the vectors in *l*. By writing

### Joined system matrix.

Given an MRHS equation system *joined system matrix*:

Similarly, we denote *S*. The problem of solving an MRHS equation system can now be stated as finding some *block*, and we sometimes speak of block *i* in

## 3 Solving algorithm

In this section we describe an algorithm for solving an MRHS system, and determine its complexity. We start with bringing the system into a special form.

### 3.1 Transforming MRHS system to full echelon form

We may perform linear transformations on the rows of *S*. Doing linear operations on the rows of

*Let *

If

We may also perform column operations on *S* in order to preserve the solution space.

*Let *

If

The problem with applying Lemma 2 in practice is that *S* can be very big. Each individual

However, by restricting

Let

where each

In the following we assume this restriction on *i* of

Given an MRHS system *full echelon form* if each block in

with

We can change any joined MRHS system

- (1)Compute the matrix
that brings$\mathbf{E}$ into standard reduced row echelon form, where we also create 0’s above every leading 1:$\mathbf{M}$ .${\mathbf{M}}^{\prime}=\mathrm{\mathbf{E}\mathbf{M}}$ - (2)Let the number of leading 1’s in block
*i*be and let${p}_{i}$ initially be an$\mathbf{U}$ identity matrix. Permute the columns in block$r\times r$ *i*such that all leading 1’s are moved to the left, and make the same permutation on the same columns of . This creates an upper triangular sub-matrix at the place where$\mathbf{U}$ is in Definition 3. Next, add columns of the triangular sub-matrix, starting from the left-most one, to create zeroes to the right of the leading 1’s on each row of block${\mathbf{I}}_{{p}_{i}}$ *i*. Make the same additions on the columns of . Then block$\mathbf{U}$ *i*gets the form given in Definition 3, and we can define as in (3.1) where each$\mathbf{U}$ corresponds to block${\mathbf{U}}_{i}$ *i*. Finally, will then be in full echelon form.${\mathbf{M}}^{\prime \prime}={\mathbf{M}}^{\prime}\mathbf{U}$ - (3)Compute new sets
.${S}_{i}^{\prime}={S}_{i}{\mathbf{U}}_{i}$

The system *n*) by doing linear algebra operations. This is done once for the whole system as a pre-processing step, so in the following we will always assume that the system in question is in full echelon form.

### 3.2 Algorithm searching for solution to MRHS system

Here we present an algorithm for searching exhaustively for possible solutions to an MRHS system. Since *x* has been guessed, the rest of *x* becomes uniquely determined and can be verified as correct or not. Hence the algorithm guesses on small parts of *x*, and keeps track of possible ways to extend a current guess.

### Informal description of algorithm.

The algorithm is accurately described in Algorithm 1. The process can be briefly explained as follows.

We separate *x* into parts *i* of *j* of

At some point we run into cases where no possible choice of *i* is in *i* of *x* by selecting *m* of

The reason for having *i* of *i*.

When

### Parallelism.

We can precompute a list *L* of partial solutions *d*. Then we can distribute the search to

In our implementation we store the precomputed vectors

### 3.3 Algorithm complexity

In each level of the recursion we compute one projection and do a table lookup. On each lookup we obtain a list *i* with probability at least *N* times on level *i*, we expect to continue

If the vectors in the sets

The total number of recursion calls corresponds to the number of accesses to the lookup tables. The expected number of solutions can be estimated as

The total number of block XORs can be computed as

We can slightly reduce the number of XORs by storing vectors

We can estimate the chance of zero

On the bit level or the instruction level, the number of XORs must take into account the number of bits in each block, and the internal parallelism of XOR instructions. The number of single bit XORs (without taking into account zero

When using *w*-bit internal parallelism, we cannot directly divide *w*, because on some levels we cannot use the whole *w* birs in the word. Instead, the number of expected *w*-bit XOR instructions can be expressed as

Similar estimates can be done for

### Example.

Suppose that *i* (we can model AND-gates with random linear combinations of variables as inputs in this setting). Let us suppose that we have *m* variables and *m* MRHS equations (blocks). Now assume a simple case where

The number of recursion calls is

so *x*-vectors by matrix

### Another example.

Suppose that *i* again, *m* variables and *m* MRHS equations (blocks). Now assume a case, where a single leading 1 in each block, i.e. *i*.
The expected number of solutions is as before

The number of recursion calls is

and the number of XORs is

Randomly generated systems will typically have almost all blocks without internal linear dependencies. Thus, they are most likely of type 1 (hard to solve), and systems of type 2 must be constructed artificially. On the other hand, systems produced from cryptanalytic problems have a lot of internal structure that comes from the algorithm implementation. We observe the effect of this structure for selected ciphers in Section 4.

## 4 Representing SL ciphers as MRHS systems

In the following we study several ciphers. We adopt the term *SL cipher* to a cipher that can be represented as a sequence of linear (or more precisely, affine) transformations and substitution layers realised by S-boxes.

### 4.1 Modelling an SL cipher as an MRHS system

Let *s*,

As SL ciphers only have linear (affine if additions of constants occur) operations apart from S-boxes, all input bits to all S-boxes can be described as linear (affine) combinations of the variables we have defined. We create one MRHS equation for each S-box *i* as follows:

where *c* is the constant part of the input affine combinations and we use the natural mapping between integers and vectors over

The first *t*, and

Constructing the joined system matrix of the MRHS system models the complete cipher. The model is flexible enough to cover all of the currently used ciphers that use S-boxes^{1}, and a linear or affine layer in-between layers of S-boxes.

The model is based on a single plaintext/ciphertext (P/C) pair. To model multiple encryption instances, new variables must be defined for plaintext, ciphertext and S-box output bits, except for S-boxes used in the key schedule. Variables for the user-selected key and key schedule S-boxes are re-used across different P/C pairs. If multiple P/C pairs are used, all MRHS equations may still be merged into one joined system matrix.

### 4.2 Fixing known bits

If the purpose of constructing the joined system matrix is to do algebraic cryptanalysis, we assume we have a known plaintext/ciphertext pair. By fixing the first and last *x* to their correct values we get a reduced system. If the original joined system is

where *p* and *c* are the known values of the P/C pair and

we get a reduced MRHS system

### 4.3 Encryption as MRHS solving

In an algebraic attack, we fix the variables for the plaintext and ciphertext bits. The task for the cryptanalyst is then to solve the remaining system, using Algorithm 1 or by other means, to find the values of the variables for the key bits.

However, it is also possible to do regular encryptions using the MRHS representation. In this case we fix the plaintext and the key variables. The task is then to “solve” the reduced system to find the values of the ciphertext variables. In a joined MRHS system where the initial equations were joined in the natural order (round by round) and both plaintext and key variables are fixed, Algorithm 1 will not do any guessing but rather just do look-up’s for the values of the intermediate variables before finding the ciphertext bits in the end.

For many ciphers there is nothing to gain from doing encryptions this way, but if the cipher contains a lot of linear operations, encryption can go faster using the MRHS representation. LowMC is a cipher that has a dense affine transformation in each round, and the MRHS representations packs all of this linearity more efficiently together such that less XORs need to be done when encrypting via Algorithm 1.

We show this for the LowMC version with one S-box per round,

The number of XORs done in one encryption according to the LowMC specification can be computed as follows: The linear layer in each round needs approximately

The number of columns in the joined MRHS matrix is

## 5 Experiments with concrete ciphers

In this section we report on experiments done with Algorithm 1 on some ciphers. In the experiments we reduce the key space by always setting a certain amount of key bits to zero and get a reduced system. This is done to get practical running times so we can measure the observed time complexity of Algorithm 1.

We have focused on four (families of) ciphers: DES [8], AES [3], Present [2], and version 2 of LowMC [1]. We have tried various experiments with key sizes between 18 bits and 24 bits. The results are very similar between the choice of key size, thus we only present results for 22-bit unknown key bits. This choice makes individual experiments reasonably fast, but not so fast that time measurement errors become significant.

These families all fit into our SL cipher framework, while providing enough variety in design choices (Feistel/SPN), S-box sizes, linear layer type (permutation, MDS, random), different key schedules. We only provide short notes on SL models of each family, as we suppose the reader is familiar with the design of these ciphers.

### 5.1 Ciphers tested

In our model we use standard DES parameters

Our model of AES has parameters

We have selected a version of Present with

Finally, we focus on the LowMC cipher which allows a variable number of S-boxes, block and key size. Only

We use a custom software implemented in SAGE [9] to generate instances of MRHS systems based on the SL model described above. The generator software produces an instance with

The generated instance is given to a fast solver, which is a C implementation of Algorithm 1. The algorithm searches the full space (it does not stop after producing a solution). It reports the total number of recursive calls (same as table lookups) *c*, the number of XORs *x*, and the running time *t* of the search.

The solver can also generate random instances of MRHS systems with specified parameters, and estimate the complexity

### 5.2 Brute force attacks with MRHS solver

Running times for DES, plus estimate for exhaustive search.

Rounds | 22-bit key [s] | Full [CPUyear] | Ratio |

4 | 0.06 | 31.73 | 0.12 |

5 | 0.32 | 176.10 | 0.68 |

6 | 0.82 | 447.08 | 1.73 |

7 | 1.41 | 770.16 | 2.98 |

8 | 2.32 | 1262.89 | 4.88 |

9 | 3.37 | 1834.37 | 7.09 |

10 | 4.58 | 2494.90 | 9.64 |

11 | 5.94 | 3235.56 | 12.50 |

12 | 7.38 | 4018.46 | 15.53 |

13 | 8.95 | 4870.76 | 18.82 |

14 | 10.60 | 5772.60 | 22.31 |

15 | 12.06 | 6563.20 | 25.36 |

16 | 13.68 | 7448.42 | 28.78 |

OpenSSL | 0.48 | 258.76 | 1.0 |

We started the experiments with estimating a CPUyear cost for exhaustive key search on DES with the MRHS solver, depending on the number of rounds. The results are summarized in Table 1. We compare the estimated exhaustive search time of our solver with the results obtained from OpenSSL speed command on the same PC. The results indicate that the running time of the MRHS solver are comparable to standard exhaustive search, with slight advantage for the four and five round versions.

In Table 2, we compare the results of 22-bit exhaustive key search for different cipher instances. We include the size of the system, the total running time of the solver, and the time of exhaustive search using a software implementation of the cipher. We have used DES and AES implemented in OpenSSL (1.0.2g) using the speed command. Present implementation was taken from [7], and LowMC implementation from [5].

We see that the MRHS solver is typically slower than the optimised cipher implementations. On the other hand, the complexity does not grow exponentially with the size of the system (as is expected for a random non-linear equation system). Depending on optimisations and implementation platform, we can expect that brute-force attack with MRHS solver is competitive with some implementations of ciphers. This is confirmed when comparing our implementation with the reference implementation of LowMC with a low number of S-boxes per round.

Running times of the solver (MRHS) and reference implementations (ref. SW) for different ciphers.

Cipher | s | n | m | l | MRHS [s] | ref. SW[s] | |

DES | 8 | 470 | 128 | 10 | 64 | 13.6 | 0.48 |

Present80 | 17 | 2066 | 527 | 8 | 16 | 114.4 | 0.12 |

AES128 | 20 | 1494 | 200 | 16 | 256 | 57.9 | 0.58 |

LowMC64-1 | 1 | 450 | 164 | 6 | 8 | 12.9 | 45.82 |

LowMC64-2 | 2 | 450 | 164 | 6 | 8 | 12.4 | 23.71 |

LowMC128 | 31 | 1010 | 372 | 6 | 8 | 55.5 | 9.24 |

LowMC256 | 49 | 1530 | 588 | 6 | 8 | 108.8 | 25.71 |

### 5.3 Expanded results for various versions of LowMC cipher

In Figures 1 and 2 we show results from exhaustive key search experiments with the LowMC cipher with a single S-box and variable number of rounds, from 22 to the recommended 164. The key size was set to 22 bits, so the running time of experiments is in the order of seconds.

We have measured the number of lookups and XORs in the implementation of Algorithm 1. The measured results are compared with the estimates obtained by equations (3.2), (3.3), and (3.4), respectively. The

In Figure 3, we compare the running time of the same experiment with the running time of the brute-force attack that uses the LowMC implementation from [5]. The brute force attack only uses the functions cipher.setkey and cipher.encrypt in a loop over all 22-bit keys. Both programs were compiled with the same compiler and level of optimisation and run on the same computer. Note that both solvers go through the whole range of keys/potential solutions, and do not stop if the key is found sooner. For low number of rounds, algebraic representation gives a huge speedup in checking the key. This converges to about 3.5-times faster encryption via the MRHS solver for the full version of the cipher.

This speed-up can be explained by the different numbers of XORs needed to be done in the reference implementation and in Algorithm 1. In an exhaustive key search the plaintext and ciphertext are fixed, and only the key is changed for every encryption. The number of XORs needed for checking one key in the reference implementation can be estimated as follows. To make one round key we must perform approximately

single-bit XORs to check one key using the standard implementation. With

Fixing the key in the MRHS representation takes approximately

Setting

### 5.3.1 Increasing the number of S-boxes

In Figures 4–6 we compare exhaustive search run-times across different versions of LowMC: with 8, 4, 2, and 1 S-boxes per round (denoted by *s*). In each version we set the maximum number of rounds as 164/*s*, and plot the results for cipher versions with smaller number of Sboxes only in the range of rounds above the previously attained number of rounds. The behaviour of the solver is consistent across different versions of the cipher.

Note that the largest size of the MRHS system for each case is the same, as it is derived from the total number of S-boxes used in the encryption. This behaviour is most pronounced when comparing the running times with the reference software implementation of LowMC (Figure 6): while the running time of the software implementation grows linearly in *s* increases.

## 6 Conclusions and discussion

All symmetric ciphers can be modelled as a system of Boolean equations, represented as a fully joined MRHS matrix. We have devised an algorithm that solves the system in the MRHS matrix model, and estimated its complexity. Actual implementations show the estimates are very accurate. With other solvers, like F4, ordinary glueing/agreeing with MRHS systems, or SAT-solvers, it is difficult to predict actual running time from the initial system. The fully joined MRHS system helps on this situation, as solving time can be determined by only examining the structure of the matrix.

We also observe that for full-scale ciphers the complexity is only exponential in the number of variables representing the user-selected key, and not in the total number of variables. For ciphers with reduced rounds the joined MRHS matrix can reveal at which point we get lower than brute force solving complexity. For instance, eight rounds of Simon32 has complexity

It is possible to guess the values of *t* linear combinations of variables such that the number of leading 1’s in some blocks decreases by *t*. This will decrease some numbers *t*, and hence we decrease running time with a factor *more* than a factor

The final interesting finding in this work is that versions of LowMC with very few S-boxes can be more efficiently implemented in the MRHS model. This comes from the fact that with few S-boxes the steps of the cipher are close to being successive linear operations. The MRHS implementation merges a lot of the linear-upon-linear parts of the operations, resulting in less XORs needing to be done using the MRHS representation. It is then possible to implement encryption more efficiently, with a speed-up factor of 1.85 when doing the linear operations of the cipher.

In the exhaustive key search scenario the gain from using the MRHS solver is even bigger since the LowMC key schedule must be executed for every key tested. With one S-box per round the MRHS representation for exhaustive search is close to four times faster to use than the standard reference implementation. This may be interpreted as a valid attack since we can do a full search of the 80-bit key space in approximately the same time it takes to do *also* done in the MRHS model, this speed advantage disappears.

We hope that the community on analysing symmetric encryption algorithms finds the work in this paper useful, and that modelling a cipher using its joined MRHS matrix may serve as a tool in assessing ciphers’ strength against algebraic cryptanalysis.

## References

- [1]↑
M. Albrecht, C. Rechberger, T. Schneider, T. Tiessen and M. Zohner, Ciphers for MPC and FHE, Advances in Cryptology – EUROCRYPT 2015, Lecture Notes in Comput. Sci. 9056, Springer, Berlin (2015), 430–454.

- [2]↑
A. Bogdanov, L. R. Knudsen, G. Leander, C. Paar, A. Poschmann, M. J. B. Robshaw, Y. Seurin and C. Vikkelsoe, PRESENT: An ultra-lightweight block cipher, Cryptographic Hardware and Embedded Systems – CHES 2007, Lecture Notes in Comput. Sci. 4727, Springer, Berlin (2007), 450–466.

- [3]↑
J. Daemen and V. Rijmen, The Design of Rijndael: AES – The Advanced Encryption Standard, Information Security and Cryptography, Springer, Berlin, 2002.

- [4]↑
H. Raddum and I. Semaev, Solving multiple right hand sides linear equations, Des. Codes Cryptogr. 49 (2008), no. 1–3, 147–160.

- [5]↑
T. Tiessen, An implementation of the lowmc block cipher family, https://github.com/tyti/lowmc, 2016.

- [6]↑
P. Zajac, A new method to solve MRHS equation systems and its connection to group factorization, J. Math. Cryptol. 7 (2013), no. 4, 367–381.

- [7]↑
B. Zhu, An efficient software implementation of the block cipher present for 8-bit platforms, https://github.com/bozhu/PRESENT-C/, 2013.

- [8]↑
Data Encryption Standard, Federal Information Processing Standards Publication (FIPS PUB) 46-3, National Bureau of Standards, 1999.

- [9]↑
The Sage Developers, SageMath, the Sage Mathematics Software System (Version 7.2), 2016, http://www.sagemath.org.

## Footnotes

^{1}

An S-box can be any Boolean function