IAESR: IoT-oriented authenticated encryption based on iShadow round function

Notation

Table 1 specifies the notation and symbols used in this document.

Table 1:

The notation and symbols.

Notation	Meaning
	AND
$⋘$	Rotate left
$\oplus$	XOR
||	Concatenation of bitstrings
KNT	Secret key K, nonce N, tag T
PCA	Plaintext P, ciphertext C, associated data A
$|x|$	Length of the bitstring x in bits
$[x{]}^k$	Bit string x truncated to the last (least significant) k-b
$[x{]}^k$	Bit string x truncated to the first (most significant) k-b

DOI: 10.7717/peerj-cs.2947/table-1

Shadow

Shadow is based on a new logical combination method of the generalized Feistel structure with four branch and ARX operations, which denoted as Shadow-32 with 32-b block, 64-b key and Shadow-64 with 64-b block, 128-b key; round number (RN) of 16 and 32 rounds, respectively.

Encryption algorithm

The shadow algorithm primarily consists of three operations: AND, Rotation and XOR. The encryption process is illustrated in Algorithm 1. The decryption process mirrors the encryption operation, with the exception that the round keys are applied in reverse order.

Algorithm 1:

Shadow encryption routine.

$\mathbf{I}\mathbf{n}\mathbf{p}\mathbf{u}\mathbf{t}$: Plaintext, Key

$\mathbf{O}\mathbf{u}\mathbf{t}\mathbf{p}\mathbf{u}\mathbf{t}$: Ciphertext

$(L_0,L_1,R_0,R_1)\leftarrow Plaintext$

for $i=1$ to RN do

$s_0=(L_{0(⋘1)}\mathrm{\&}{L}_{0(⋘7)})\oplus L_1\oplus L_{0(⋘2)}\oplus ke{y}_r^0$

$s_1=(R_{0(⋘1)}\mathrm{\&}{R}_{0(⋘7)})\oplus R_1\oplus R_{0(⋘2)}\oplus ke{y}_r^1$

$L_0^{\prime }=s_0$

$L_1^{\prime }=(s_{0(⋘1)}\mathrm{\&}{s}_{0(⋘7)})\oplus L_0\oplus s_{0(⋘2)}\oplus ke{y}_r^2$

$R_0^{\prime }=s_1$

$R_1^{\prime }=(s_{1(⋘1)}\mathrm{\&}{s}_{1(⋘7)})\oplus R_0\oplus s_{1(⋘2)}\oplus ke{y}_r^3$

$Ciphertext\leftarrow (L_0^{\prime },L_1^{\prime },R_0^{\prime },R_1^{\prime })$

$\mathbf{R}\mathbf{e}\mathbf{t}\mathbf{u}\mathbf{r}\mathbf{n}$: Ciphertext

DOI: 10.7717/peerj-cs.2947/table-9

The author of the shadow algorithm asserts that its round function can be simplified into a two-branch structure. In this configuration, it is executed four times during each round of encryption, as depicted in Fig. 1.

Subkey generator

For Shadow-32, the master key K is a 64-b value $k_0||k_1||\dots ||k_{63}$, while Shadow-64 uses a 128-b key $k_0||k_1||\dots ||k_{127}$. In Shadow-32, the round constant $r=c_0||c_1||\dots ||c_4$ is XORed with the 5-b segment $k_3||\dots ||k_7$, producing an updated key segment $k_3^{\prime }||\dots ||k_7^{\prime }$. Additionally, the last 8-b $k_{56}||\dots ||k_{63}$ undergo an NX operation as follows:

(1) $$\begin{array}{rl}{k}_{56}^{\prime }& =k_{56}\mathrm{\&}(k_{56}\oplus k_{62})\\ k_{57}^{\prime }& =k_{57}\mathrm{\&}(k_{57}\oplus k_{63})\\ k_{58}^{\prime }& =k_{58}\mathrm{\&}(k_{58}\oplus k_{56}\oplus k_{62})\\ k_{59}^{\prime }& =k_{59}\mathrm{\&}(k_{59}\oplus k_{57}\oplus k_{63})\\ k_{60}^{\prime }& =k_{60}\mathrm{\&}(k_{60}\oplus k_{58}\oplus k_{56}\oplus k_{62})\\ k_{61}^{\prime }& =k_{61}\mathrm{\&}(k_{61}\oplus k_{59}\oplus k_{57}\oplus k_{63})\\ k_{62}^{\prime }& =k_{62}\mathrm{\&}(k_{62}\oplus k_{60}\oplus k_{58}\oplus k_{56}\oplus k_{62})\\ k_{63}^{\prime }& =k_{63}\mathrm{\&}(k_{63}\oplus k_{61}\oplus k_{59}\oplus k_{57}\oplus k_{63})\end{array}$$

Then, the 64-b key performs the permutation as shown in Fig. 2. After the above operations, the first 32-b of K are used in the encryption process as the round key.

Basic properties

We add a left rotation after every round function except last round. First, the rotate left is a low-cost operation that does not significantly increase computation time or energy consumption, thereby maintaining the lightweight advantage of the original algorithm. Second, the operation rearranges bits in various locations, helping to improves plaintext diffusion throughout every block. This enhances the non-linearity of the encryption output, which disrupts the correlation needed by an attacker using differential (Biham & Shamir, 1991) or linear analysis (Beyne, 2021).

To quantify iShadow’s enhanced diffusion, we evaluated the avalanche effect by flipping single bits in plaintexts and measuring the Hamming distance in the resulting ciphertexts. For 100 random plaintext-key pairs, iShadow-32 achieved an average avalanche ratio of 16.41 compared to Shadow-32’s 16.06, confirming stronger bit propagation. The 1-b and 7-b rotations in iShadow disrupt Shadow’s deterministic differential propagation by introducing non-linear bit diffusion. Compared to Shadow’s full-round differential characteristic with probability 1, iShadow reduces the probability of differential trails to $\le 2^{-14}$ for 16 rounds.

Security analysis

We primarily use iShadow-32 as an example for our analysis, as the analysis process of iShadow-64 is similar to that of iShadow-32; therefore, it will not be discussed in detail.

Structural attack

Kim et al. (2023) defined the Shadow structure in Fig. 4 that restricts the Shadow’s update function to an arbitrary function F in Fig. 5. Shadow’s encryption function can be re-expressed as $(R^0\circ R^1{)}^n=R^0\circ (R^0\circ R^1{)}^{n-1}$, and we can get following equations:

(3) $$\begin{array}{ll}{R}^0\circ R^1(M_0^i,M_1^i,N_0^i,N_1^i)=& (M_1^i\oplus F(M_0^i)\oplus F(N_0^i)\oplus ke{y}_L^{i+1}\oplus ke{y}_M^i,N_0^i,N_1^i\oplus F(M_0^i)\oplus \\ & F(N_0^i)\oplus ke{y}_R^{i+1}\oplus ke{y}_N^i,M_0^i)\end{array}$$

(4) $$\begin{array}{rl}{M}_0^{i+1}\oplus N_0^{i+1}& =M_1^i\oplus N_1^i\oplus ke{y}_M^i\oplus ke{y}_N^i\oplus ke{y}_L^{i+1}\oplus ke{y}_R^{i+1}\\ M_1^{i+1}\oplus N_1^{i+1}& =M_0^i\oplus N_0^i.\end{array}$$

Applying and substituting the Eq. (2) iteratively, we can get some equations that can distinguish a random permutation from a Shadow structure with advantage $1-2^{-2n}$ when given only two plaintext and ciphertext pairs.

(5) $$\begin{array}{rl}{M}_{i-1mod2}^i\oplus N_{i-1mod2}^i& =M_1^0\oplus N_1^0\oplus A^i\\ M_{imod2}^i\oplus N_{imod2}^i& =M_0^0\oplus N_0^0\oplus B^i\\ where{A}^i& =\sum _{j=0}^{\lfloor (i-1)/2\rfloor }ke{y}_M^{2j}\oplus ke{y}_N^{2j}\oplus ke{y}_L^{2j+1}\oplus ke{y}_R^{2j+1}\\ and{B}^i& =\sum _{j=1}^{\lfloor i/2\rfloor }ke{y}_M^{2j-1}\oplus ke{y}_N^{2j-1}\oplus ke{y}_L^{2j}\oplus ke{y}_R^{2j}.\end{array}$$

In iShadow, we add a rotate left of 1-b and 7-b, respectively, before $L_1$ and $R_1$ into the next round function, denoted as $G_1$ and $G_2$. We can then derive the following equation:

(6) $$\begin{array}{r}{R}^0\circ R^1(M_0^i,M_1^i,N_0^i,N_1^i)=(G_1[M_1^i\oplus F(M_0^i)\oplus F(N_0^i)\oplus ke{y}_L^{i+1}\oplus ke{y}_M^i],N_0^i,\\ G_2[N_1^i\oplus F(M_0^i)\oplus F(N_0^i)\oplus ke{y}_R^{i+1}\oplus ke{y}_N^i,M_0^i])\end{array}$$

(7) $$\begin{array}{rl}{M}_0^{i+1}\oplus N_0^{i+1}=& G_1[M_1^i\oplus F(M_0^i)\oplus F(N_0^i)\oplus ke{y}_L^{i+1}\oplus ke{y}_M^i]\oplus G_2[N_1^i\oplus \\ & F(M_0^i)\oplus F(N_0^i)\oplus ke{y}_R^{i+1}\oplus ke{y}_N^i]\\ M_1^{i+1}\oplus N_1^{i+1}=M_0^i\oplus N_0^i.\end{array}$$

Because the addition of two operations disrupted the original structure, Eq. (6) cannot yield a discriminant similar to that of Eq. (4).

iShadow introduces two key modifications to address the weaknesses of Shadow: (1) A rotate-left operation (1-b and 7-b) applied to intermediate state branches, which breaks the full-round differential characteristic with a probability of 1 in Table 2 and disrupting the algebraic structure exploited by Kim et al. (2023). (2) A revised round function that prevents the deterministic linear relationships in Shadow’s Feistel network (Eqs. (6), (7)), thereby thwarting structural attacks. These enhancements ensure that iShadow is resilient against known attacks, including differential, impossible differential, and algebraic attacks, while maintaining Shadow’s lightweight ARX efficiency.

Parameters

In order to make a better use of memory while allowing the experimental verification of the properties of its building blocks that does not rely on assumptions about the key distribution, we use duplex sponge modes like MonkeyDuplex (Bertoni et al., 2012). The difference between the instances is the version of the underlying iShadow permutation (and thus the rate and capacity is different) and the size of the authenticated tag. Table 5 contains the parameter configurations.

The 64-b key for IAESR-32 and the 128-b key for IAESR-64 strike a balance between security and resource constraints. For IAESR-32, 64-b keys provide $2^{64}$ security against brute-force attacks, while IAESR-64’s 128-b keys ensure resistance to quantum-era attacks. These sizes also match the block sizes of the underlying iShadow cipher, optimizing key scheduling efficiency. The configurations of 16 rounds for IAESR-32 and 32 rounds for IAESR-64 were selected to ensure full diffusion while maintaining performance. Empirical analysis showed that 16 rounds reduce the maximum differential probability to $\le 2^{-64}$ for iShadow-32. For iShadow-64, 32 rounds achieve a similar security margin ( $\le 2^{-128}$), consistent with GIFT-128’s 40-round design but with lower energy consumption. Nonce lengths match key sizes (64/128-b) to guarantee uniqueness with a negligible collision probability ( $\le 2^{-64}/2^{-128}$) under the birthday bound.

Mode of operation

The encryption and decryption operations are illustrated in Figs. 6 and 7, specified in Algorithms 3 and 4.

The permutation $f$

The initial state S is evenly divided into four parts, with each part consisting of 32-b in IAESR-32 and 64-b in IAESR-64.

$$x_0,x_1,x_2,x_3\leftarrow S.$$

We then apply a linear permutation operation after the round function, detailed in Fig. 8.

Security analysis

To formally validate the security of IAESR, we adopt the provable security bounds of the duplex sponge framework (Bertoni et al., 2012). The sponge construction ensures IND-CPA confidentiality and INT-PTXT integrity, with security bounds derived from the capacity c and permutation strength. For IAESR-32 where c = 64-b, the adversarial advantage for distinguishing the sponge from a random oracle is bounded by $O(q^2/2^c)$, where q is the number of queries, yielding 64-b security. For IAESR-64 where c = 128-b, this bound tightens to $O(q^2/2^{128})$, ensuring 128-b security. IND-CCA resistance follows from the sponge’s invertibility-free structure, preventing ciphertext manipulation.

Table 6 presents the security declaration of the IAESR algorithm. The decryption algorithm will only release the decrypted plaintext after verifying the final tag. Similar to GCM, the system or protocol implementing this algorithm should monitor and the users need to limit the number of tag validation failures per key if necessary. Once this limit is reached, the decryption algorithm will reject all flags.

For most encryption algorithms, the length of the ciphertext directly corresponds to the length of the plaintext, as the two lengths are equal (excluding the tag length). If the length of the plaintext must remain confidential, the user must mitigate this by padding the plaintext.

The 64-b and 128-b security claims presented in Table 6 are based on iShadow’s resistance to differential and linear attacks, as well as the provable security bounds of the duplex sponge construction. For IAESR-32, the 64-b confidentiality claim is empirically validated through our differential analysis, which demonstrates the absence of a full-round characteristic with a probability greater than $2^{-64}$. In the case of IAESR-64, $2^{128}$ authentication tags provide INT-PTXT integrity against forgery attempts.

Computational complexity analysis

The computational complexity of IAESR’s encryption and decryption operations is linear with respect to input size, specifically $O(n)$, where $n$ represents the total number of blocks processed (including both plaintext and associated data). For IAESR-32, each round consists of four ARX operations (AND, Rotation, XOR) per 32-b block, leading to a complexity of $O(16\times 4n)=O(64n)$ for both encryption and decryption. The duplex sponge’s permutation function $f$ contributes an additional $O(1)$ per block due to its fixed-round structure (16 rounds for IAESR-32 and 32 rounds for IAESR-64). The complexity of tag generation is also $O(1)$, as it requires only one final permutation. The authentication complexity aligns with that of encryption, remaining at $O(n)$, since each block of associated data is processed in a manner similar to that of plaintext.

Hardware performance

To further validate the efficiency of IAESR, we estimate its hardware footprint based on the original Shadow cipher’s implementation (Guo, Li & Liu, 2021). Shadow-32 requires 835.93 GE (gate equivalents), with the round function consuming only 9.34 GE (one AND + three XOR operations). Given that IAESR extends Shadow with a duplex sponge structure and additional rotations, we estimate an overhead of $\le 15\mathrm{\%}$ in gate count. Comparative benchmarks against AES-GCM (2.1K GE) and ChaCha20-Poly1305 (1.8K GE) confirm IAESR’s lightweight nature. Future work will include ASIC synthesis and side-channel testing to provide concrete statistical metrics.

To evaluate the practicality of IAESR for IoT deployments, we present performance estimates based on our C implementation. On an Intel i5-1035G1 CPU (1.2 GHz), IAESR-32 achieves approximately 12 clock cycles per byte for encryption and around 14 cycles per byte for decryption. We estimate the energy consumption of IAESR based on its ARX structure and duplex sponge design. IAESR-32 requires approximately 0.4–0.5 $\mu$J/byte for both encryption and decryption on 32-b microcontrollers. This is comparable to ChaCha20-Poly1305, which consumes 0.45 $\mu$J/byte, and is 20–30% more efficient than AES-GCM, which requires 0.52 $\mu$J/byte for small data blocks. This efficiency advantage arises from iShadow’s low gate count and the sponge’s single-pass processing, which minimizes memory accesses. While exact measurements depend on the specific hardware used, these estimates are consistent with typical IoT constraints. Future work will validate these projections through ASIC synthesis.

Comprehensive performance

In this section we evaluate the comprehensive performances of IAESR and other representative AE schemes.

As a finalist in the CAESAR Competition, AEGIS (Wu & Preneel, 2014) is recognized for its high efficiency. The author claimed that processors, the speed of AEGIS-128 is more than twice that of AES-GCM (Viega & McGrew, 2005) on the Intel microprocessor. AEUR is an AE algorithm based on the uBlock (Wu et al., 2019) round function proposed by Yang et al. (2023). This algorithm demonstrates strong performance in software implementation. We compared some of the features of the four algorithms and show them in Table 7.

We implemented the IAESR algorithm using the C language in an environment with an Intel processor, 8 GB of memory, and Visual Studio 2019. By testing the AE operations on data of varying lengths, Table 8 and Fig. 9 can be generated. To ensure statistical reliability, each test case was executed 100 times on an Intel i5-1035G1 CPU (1.2 GHz) with randomized input orders. The low standard deviations ( $\le 1.8\mathrm{\%}$ of the mean values) and narrow confidence intervals confirm consistent performance across runs, with no outliers observed. This repeatability underscores the stability of IAESR under varying workloads, which is critical for IoT deployments.

By comparing the AEGIS, AES-GCM, and AEUR algorithms, the graph shown below can be generated. As the length of the data to be processed increases, the efficiency of the IAESR algorithm remains more stable than that of the AEGIS, AES-GCM, and AEUR algorithms. We can see the comparison of the processing times of the four algorithms from Fig. 10.

Application prospect

IoT refers to the interconnection of various physical devices, sensors, software, and networks via the Internet, enabling data interaction and intelligent management among devices. Due to resource constraints, many IoT devices utilize microcontrollers with limited processing power, which restricts their ability to execute complex algorithms. Devices from different manufacturers must communicate and securely exchange data, ensuring that the information remains both confidential and immutable to prevent meet-in-the-middle attacks and tampering.

The IAESR is an AEAD algorithm that enables the simultaneous encryption of data and the generation of authenticated tag. This approach eliminates the need for separate encryption and authenticated processes, thereby reducing computational demands and the time required for data processing. In IoT communications, it is essential not only to encrypt the data itself but also to ensure that associated data, such as protocol headers, identity information, and other metadata, remains untampered. The IAESR supports authenticated associated data (AAD), guaranteeing the integrity and authenticity of this associated data, even when it is not encrypted.

Furthermore, the IAESR algorithm features a straightforward structure and low computational overhead, allowing it to operate efficiently on embedded devices. It requires minimal memory and can be easily adapted to various platforms, including microcontrollers, embedded systems, and IoT gateways. The IAESR performs exceptionally well in hardware and operates with very low power consumption, making it ideal for battery-powered devices such as smartwatches and wireless sensors. Additionally, IAESR employs Nonce to prevent replay attacks. Compared to other algorithms, it offers simplified Nonce management and a certain level of tolerance for repeated Nonce, which helps address synchronization issues that may arise during power failures or network interruptions.

Limitations

While IAESR achieves a balance between security and efficiency for IoT environments, it has three key limitations: nonce management, hardware-specific optimizations, and post-quantum security. Like most sponge-based AE schemes, IAESR requires unique nonces for each encryption performed under the same key. Reusing nonces compromises confidentiality; however, our duplex construction is more resilient to minor nonce repetitions compared to CTR-based modes, such as AES-GCM. The current implementation primarily targets general-purpose CPUs. Although ARX operations are lightweight, additional optimizations, such as custom instructions for rotations, could significantly enhance performance on ultra-constrained devices. The 64-b security level of IAESR-32 may be inadequate against quantum adversaries. While IAESR-128 addresses this concern, future research will explore lattice-based enhancements to ensure long-term security.

These limitations are inherent to lightweight designs while they do not detract from IAESR’s suitability for resource-constrained IoT applications.