# SIMECK-T: An Ultra-Lightweight Encryption Scheme for Resource-Constrained Devices
## 2 Methodology
### Implementation
A 64 bit block cipher in counter mode requires a new key every \(2^{n/2-16}\) blocks [99], which means that a new key should be deployed/generated for every 512 KB of encrypted data. A strategy like this cannot be envisioned on ciphers with a 32-bit block size because given \(n=32\), a new key would be required for every 4 bytes of plaintext. An improved SIMECK round function [100] could be important for the proposed SIMECK-T cipher, where a block size of 64 bits is used instead of 32 as in [100], and the encryption key is 128 bits. An increase in the number of rounds to 5 SIMECK rounds, each containing 7 TEA rounds (a total of 40 rounds), should be applied whenever this is not a drawback for the limited resources. The fact that SIMECK-T successfully produces random output is very important. The cipher passes the \(\chi^{2}\) test introduced by [PERSON] [73], and the law of the iterated logarithm tests in all three forms, weak, medium, and strong, introduced by [PERSON] [28, 89]. The metrics used by [PERSON] et al. [31] are also passed. The net advantage of SIMECK-T over SPECK-R [19], or over the newly discovered SIMECK-R cipher, which has also been made available as free software [101], is the lack of substitution boxes. No lookup memory is required, there are no side channels, and no communication bottleneck is perceived since all operations can be performed in local 32-bit registers. This also means that any available memory on a resource-constrained device can be used for other purposes. For IoT devices, variables that are stored in memory--and more importantly the tables--constantly draw power from scavenged resources and battery supplies. For this reason, even though lightweight cryptography approaches like that demonstrated by SPECK-R [19] can offer decent protection levels, an ARX solution like SIMECK-T is lighter in resources and easier to implement. A 128-bit block size for lightweight cryptography is not always applicable. A 32-bit block size is sometimes used, but it is too little by modern standards. A 64-bit block size like the one in SIMECK-T seems to be the right choice, and a 128-bit key that changes every 512 KB offers sufficient protection [99]. The SPECK-R algorithm only uses a 96-bit key [19]. The role of the \(psum\) and \(pmul\) variables that depend on the derived key and the password in Algorithm 1 is to defeat neural classifiers which have been shown to successfully attack reduced rounds of ciphers with small block sizes [102]. ## 6 Conclusions

Lightweight cryptography is an important challenge for resource-constrained devices and the Internet of Things. A selection of Addition-Rotation-XOR (ARX) block ciphers, designed for software implementations, were improved using the dynamic substitution layer of SPECK-R [19]. Reduced-round versions of these augmented ciphers were compared to produce pseudo-random output, and SIMECK was found to be the best performing candidate in the form of SIMECK-R.

Based on the operators within the round function of SIMECK and the one used by the TEA cipher, also performing very well in our tests, a lightweight encryption scheme was obtained using only ARX instructions based on existing SIMECK [29] and TEA [30] algorithms. The encryption scheme was based on a 64-bit block size and 128-bit keys, suitable for resource-constrained devices. The performance of the new algorithm in electronic code book (ECB) mode and in counter mode (CTR), was studied on a Raspberry PICO 2040 device. Implementation of a password-based key derivation function (PBKDF) was also evaluated, using SIMECK-T as the back-end and MDC-2 to create a hash function. The results show that the encryption scheme is very fast. The proposed encryption scheme combines 3 rounds of SIMECK with 5 internal rounds of TEA for a total of 18 rounds. Where possible, we recommend that 5 rounds of SIMECK be combined with 7 rounds of TEA for a total of 40 rounds. Our tests on Raspberry PICO show that the performance impact is negligible.