# Efficient Parallel Implementation of CTR Mode of ARX-Based Block Ciphers on ARMv8 Microcontrollers
## 3 Related Works
### Parallel Implementation of CTR Mode of Operation on the NEON Engine
#### 4.2.2 HIGHT-CTR Optimization  
In the HIGHT-CTR mode, we propose a parallel implementation that simultaneously processes 48 encryptions by applying the proposed data parallelism technique to the HIGHT-CTR mode optimization. As for the optimization method of HIGHT-CTR mode, the proposed optimization of CTR mode in the existing work [7] is used. The HIGHT-CTR mode optimization proposed in the previous work is shown in Figure 6. The 64-bit block of HIGHT consists of a 32-bit variable counter and fixed nonce. In the same way as the LEA-CTR optimization, some round operations for up to five rounds have been efficiently bypassed through pre-computation of the round operations for the fixed nonce part. To implement optimization of HIGHT-CTR mode in parallel, we utilize register scheduling similar to the proposed parallel implementation of HIGHT. The round function of HIGHT requires more TEMP registers than other block ciphers (LEA and CHAM) to store intermediate values. Thus, when loading RK and Table values from memory into registers, three vector registers are used respectively, and the remaining vector registers are utilized as TEMP registers. Algorithm 6 shows the parallel implementation of the initial 1-5 rounds of the optimized HIGHT-CTR mode by looking up the pre-computation value for a fixed nonce part. After round 5, it is the same as the proposed parallel implementation of HIGHT, and the encryptions of the remaining plaintexts are performed by efficiently interleaving NEON instructions using the Temp register. In Round 1, only four words (\(X_{0,0}-X_{0,3}\)), the counter value, need round operations, and the remaining words (\(X_{0,4}-X_{0,7}\)) are already pre-computed with a fixed value part, so round operations are not required. In Round 2, since \(X_{1,1}\) and \(X_{1,5}\) words are part of the variable counter, round operations for \(X_{1,1}\) and \(X_{1,5}\) words are performed by looking up the pre-computation table. Steps 3-13 show the round function for \(X_{1,1}\) and \(X_{1,5}\) words. In Step 3, round operation for \(X_{1,1}\) word is efficiently performed using the pre-computation with only \(ADD\) instruction. Steps 4-13 are a round function for \(X_{1,5}\) word and the cache is used in the round function. In Round 3, the \(X_{2,7}\) word is affected by the counter, so it is no longer possible to pre-compute intermediate value, and round operation is required. In Steps 15-25, to perform the round function for \(X_{2,7}\) word, a modular addition is performed to the pre-computed \(X_{2,7}\) word and \(X_{2,6}\) word applied to the \(F_{0}\) function and \(XOR\) operation. In Round 4, round operations of \(X_{3,1}\) and \(X_{3,3}\) words affected by the counter are required. Steps 27-36 are the process of performing the round function for \(X_{3,1}\) word, and Steps 37-38 process round function for \(X_{3,3}\) word with only \(XOR\) instruction by loading the pre-computation table into vector registers. In Round 5, all words are affected by the counter, so pre-computation is no longer possible, and all words require round operations. In Steps 40-48, the last pre-computation value is used to perform a round function of \(X_{4,3}\) word. Through the HIGHT-CTR mode optimization, some round operations up to the initial five rounds were processed as a simple table lookup. After round 5, encryption is performed in the same way as the proposed parallel implementation of HIGHT. ```
1:v0-v7(Plaintexts), v24-v31(Roundkeys and Table)
2:v0-v7(Ciphertexts)
3: Loading RK and the table, (x1: RK Address, x2: pre-computation table Address)
4:LD1 [v30.16b-v31.16b], [x1],#32
5:LD1 [v28.16b-v29.16b], [x2],#32
6:2 Round Function
7:ADD v7.16b, v7.1



#### 4.2.3 Revised CHAM-CTR Optimization

In this section, we present a parallel implementation of the revised CHAM-CTR mode optimization.