Lightweight Sensor Data Encryption on ESP32 Using the Pi Number for Dynamic Operations

Abstract

Since intercepted sensor data can reveal user activities, lightweight cryptography is essential for protecting information in resource-constrained devices. Although ARX-based lightweight schemes offer high computational efficiency, their lack of inherent non-linear substitution and permutation layers motivates their integration into secure cryptographic designs. This paper proposes LSEPI (Lightweight Sensor Encryption Using PI), a lightweight stream cipher for protecting electrical sensor data. LSEPI employs a single-round substitution-permutation design that combines the AES substitution box with a key-dependent dynamic permutation and a dynamically selected XOR mask derived from the secret key and the digits of the number $\pi$. To mitigate the computational cost of pseudorandom sequence generation, the first 20 KB of the decimal expansion of $\pi$ are stored on both the ESP32 and Android device. Encryption is performed on the ESP32 during the simultaneous acquisition and computation of voltage, current, power, and energy, while decryption is performed on an Android application for user-selected time intervals. Statistical evaluation shows that LSEPI achieves an entropy of 7.9971 with a single encryption round, comparable to Speck-CTR with 32 rounds (7.9970) and Ascon (7.9969), and higher than the approximately 7.18 reported for recent lightweight proposals. The encrypted data also satisfies the chi-square goodness-of-fit criterion, exhibits correlation coefficients close to zero, and achieves average avalanche effects of 50.005% for one-bit plaintext changes and 50.08% for one-bit key changes. GLCM-based texture metrics are comparable to those of Speck-CTR and Ascon. The known-plaintext analysis indicates that recovering the key-dependent masking sequence requires determining or inverting the key-dependent permutation; thus, despite the use of XOR operations, the attack does not directly succeed. From a computational perspective, LSEPI requires 135 μs per sensor record after initialization, adding only 0.04% overhead to the computation of the electrical variables on the ESP32.

1. Introduction

Sensors are widely used to monitor physical environments, generating large volumes of data from the measurements they collect. These data are valuable because they can be analyzed to detect patterns and support decision-making processes [1]. Since sensor devices often transmit these data through the Internet, protecting the privacy and confidentiality of the collected data has become a fundamental requirement [2]. While the widespread adoption of sensor networks has enabled numerous applications, it has also introduced significant security challenges, particularly regarding communication through untrusted networks such as the Internet [3]. Furthermore, the embedded devices commonly employed to acquire and transmit sensor data, such as microcontrollers (e.g., ESP32) [4], are resource-constrained platforms characterized by limited computational capabilities, restricted RAM and ROM memory, and low energy availability compared with conventional computers [5]. These limitations are even more critical when additional tasks must be executed, leaving only a limited computational budget for security mechanisms [6].

Considering the importance of protecting sensed data [7] under these resource constraints, lightweight cryptography has emerged as an appropriate solution. Lightweight cryptography comprises cryptographic algorithms specifically designed to provide adequate security while requiring fewer computational resources than conventional cryptographic techniques [8]. In these environments, it is essential to minimize the total processing workload because data acquisition, encryption, and transmission must all be performed within the constrained capabilities of the embedded device [9].

Among the development platforms commonly used for lightweight cryptographic algorithms, the ESP32 has become one of the most representative. Some algorithms have been adapted for implementation on this platform, including AES-128-ECB, SPECK-128-ECB [10], and AES-256-GCM [11]. Other approaches include lightweight keyed hash functions that combine chaos theory, the Parabola Chaotic Map, and hardware-assisted security mechanisms [12]. Nevertheless, traditional chaotic-map-based approaches often require a considerable number of iterations to generate pseudorandom sequences with suitable statistical properties, which limits their efficiency in lightweight encryption scenarios [13].

Conventional cryptographic algorithms, such as the original AES, are computationally demanding for resource-constrained devices, motivating the development of lightweight alternatives. For example, Ali et al. replaced the MixColumns transformation with cyclic permutations to reduce computational complexity; however, this approach was implemented on laptops rather than microcontrollers [14]. Similarly, Gupta et al. proposed a lightweight image encryption scheme inspired by block ciphers that employs a substitution–permutation network (SPN) based on a designed S-box [15]; nonetheless, due to resource constraints, the resulting entropy improved only from 6.0 to approximately 7.0, which remains below the ideal value of 8.0. Most of these approaches still rely on multiple encryption rounds, although reduced-round variants have been proposed to decrease computational overhead [16]. Another distinguishing characteristic of lightweight cryptography is the reduction in key and block sizes. For instance, while AES relies on relatively large shared keys (e.g., 128 bits) to encrypt large data blocks, lightweight cryptographic schemes frequently process smaller data blocks, making the use of shorter keys more appropriate for constrained environments [17]. As an example, the ultra-lightweight block cipher Speck, designed for applications requiring high throughput and low latency, supports key sizes as small as 64 bits [18,19].

Other research lines have explored single-round encryption schemes as an alternative to conventional multi-round designs. The approach proposed in this work belongs to this category. Single-round lightweight cryptographic algorithms often incorporate dynamic operations, such as permutations, to compensate for the reduced number of rounds while preserving an adequate level of security and improving computational efficiency. An example of this approach is the proposal presented by Noura et al. [20]. However, the highest entropy value reported for the encrypted information in that work was approximately 7.18, which is lower than the ideal entropy of 8.0. The single-round design has also been adopted in other cryptographic primitives, including message authentication, as demonstrated by Noura et al. [21]. Likewise, Witwit et al. proposed an ultra-lightweight encryption algorithm for resource-constrained Internet of Things (IoT) devices that combines an S-box with Addition, Rotation, and XOR (ARX) operations to achieve a balance between security and execution speed, reporting entropy values of approximately 7.18 [22]. Another representative proposal is LESCA, introduced by Noura et al., which employs a single-round function for keystream generation together with a simple key-update mechanism while avoiding substitution operations [23].

Compared with block ciphers, stream ciphers generally require fewer computational resources, making them particularly attractive for resource-constrained environments [24]. Furthermore, incorporating dynamic operations into the encryption process reduces the dependence on multiple rounds, thereby improving efficiency compared with schemes that rely exclusively on static transformations [25]. Consequently, achieving an appropriate balance between computational efficiency and cryptographic security remains one of the primary challenges in lightweight cryptography, where hardware–software co-design strategies have been analyzed to simultaneously improve performance and maintain security guarantees [26].

Motivation: Sensor data may contain sensitive information capable of revealing private behaviors that could compromise users’ security if intercepted during transmission. To address this challenge, lightweight cryptographic algorithms have been deployed on microcontrollers that simultaneously acquire sensor measurements, process the data, encrypt the resulting information, and transmit it in real time. Some lightweight cryptographic proposals are based on ARX operations, which are well suited for efficient implementation. Representative examples include Speck [18,19], which employs multiple encryption rounds, and SUL32C [22], which adopts a single-round design. ARX-based constructions lack the inherent non-linear substitution and permutation layers that SPN designs employ to ensure adequate confusion and diffusion [27]. To improve their security, different proposals have incorporated SPN components, such as permutations [14] or substitution boxes [22], while avoiding the complete SPN structure. Nevertheless, these approaches have reported entropy values below the theoretical optimum of 8.0, with values around 7.18 in some cases [20,22]. Consequently, there remains a need for lightweight cryptographic algorithms that preserve the security of SPN-based designs while maintaining execution speeds.

Contribution: This paper proposes LSEPI (Lightweight Sensor Encryption Using PI), a lightweight stream cipher designed to protect the privacy of sensor data. The proposed algorithm is implemented on an ESP32 microcontroller, where each sensor measurement is encrypted individually as it is generated. The corresponding decryption process is performed on an Android mobile application for a user-selected time interval. LSEPI adopts a substitution–permutation design that combines the AES substitution box (S-box) with a dynamic permutation generated from the secret key. Prior to the substitution stage, the plaintext is combined through a byte-wise XOR operation with a dynamically selected segment of the string $S_x$, which is derived from both the secret key and the decimal digits of the number $\pi$. To mitigate the computational overhead, the first 20 KB of the decimal expansion of $\pi$ are stored in the memory of both the ESP32 and the Android device, thereby eliminating the execution time associated with pseudorandom sequence generation. Furthermore, LSEPI adopts a single-round design to reduce the additional computational cost introduced by the substitution and permutation stages. This is relevant, considering that the ESP32 must not only encrypt but also compute the corresponding electrical quantities, including voltage, current, power, and energy consumption, before transmitting each encrypted measurement.

The remainder of this paper is organized as follows. Section 2 presents the materials and methods employed in this study, including the security and performance evaluation metrics, as well as the Speck and Ascon algorithms used for comparison. Section 3 describes the proposed encryption scheme, including preprocessing stage, dynamic permutation process, sensor data acquisition and computation of electrical variables, and the corresponding encryption and decryption procedures. Section 4 presents the experimental results, including both the security analysis and performance evaluation. Section 5 discusses the obtained results, highlighting the main findings and their implications. Finally, Section 6 concludes the paper.

2. Materials and Methods

This section describes the metrics used to evaluate the proposed method and the reference algorithms used for comparison. These include statistical measures, such as entropy, correlation, and goodness-of-fit, along with texture analysis using the Gray-Level Co-occurrence Matrix (GLCM) for energy, homogeneity, and contrast, as well as the avalanche effect and throughput. Finally, an overview of the Speck and Ascon algorithms is provided.

2.1. Information Entropy

Information entropy, denoted by H, is defined by Equation (1) and quantifies the degree of randomness in a sequence of bits. In cryptographic applications, information entropy is widely used to evaluate the statistical security of encrypted data [28]. In this study, entropy is computed from a $256\times 256$ grayscale image generated by concatenating the encrypted strings produced by the proposed cryptosystem. For comparison, additional images of the same dimensions are constructed from the plaintext strings and from the corresponding ciphertexts produced by Speck and Ascon.

The function ${log}_2$ denotes the base-2 logarithm. An ideally encrypted image should exhibit an entropy value close to the theoretical maximum of 8.0, indicating a nearly uniform distribution of pixel intensities. Such a distribution reflects a high degree of randomness and unpredictability, thereby providing greater resistance against statistical attacks.

$$H=-{\displaystyle \sum _{x=0}^{255}}P\left(x\right){log}_{2}P\left(x\right),$$

(1)

where:

• x: The intensity level of a pixel ranging from 0 to 255.
• $P\left(x\right)$: The probability that a pixel in the image takes the value x.

2.2. Correlation Coefficient

The correlation coefficient, denoted by r, is a statistical measure whose values range from $-1$ to 1. In cryptographic image analysis, it is used to evaluate the linear dependency between adjacent pixels [29]. Effective encryption should produce correlation coefficients close to zero, indicating that the spatial relationships present in the original image have been eliminated. The correlation coefficient is computed according to Equation (2) and is evaluated for adjacent pixel pairs in three directions: horizontal, vertical, and diagonal.

$$r={\displaystyle \frac{\frac{1}{w}\left({\sum }_{i=1}^w(x_i-\overline{x})(y_i-\overline{y})\right)}{\sqrt{\frac{1}{w^2}\left({\sum }_{i=1}^w{(x_i-\overline{x})}^2\right)\left({\sum }_{i=1}^w{(y_i-\overline{y})}^2\right)}}},$$

(2)

where:

• w: The number of pixels randomly selected from the image.
• $x_i$: The value of pixel i.
• $y_i$: The value of the adjacent neighbor pixel of pixel i.
• $\overline{x}={\sum }_{i=1}^w{x}_i/w$: The mean of the sampled pixels.
• $\overline{y}={\sum }_{i=1}^w{y}_i/w$: The mean of the corresponding neighbor pixels.

2.3. Goodness-of-Fit Test

The chi-square (${\chi }^2$) test is a statistical hypothesis test used to evaluate whether the histogram of an image follows a uniform distribution [30]. The null hypothesis states that the pixel intensity values are uniformly distributed, whereas the alternative hypothesis assumes that the distribution deviates from uniformity. Since each pixel is represented by an 8-bit value, there are 256 possible intensity levels. The test statistic is computed using Equation (3). According to the Central Limit Theorem, the ${\chi }^2$ statistic can be approximated by a normal distribution with mean $\mu =255$ and standard deviation $\sigma =22.5$ [31]. Using a significance level of $\alpha =0.01$, the null hypothesis is rejected if ${\chi }^2\ge 308$; otherwise, it is not rejected.

$${\chi }^2={\displaystyle \sum _{i=0}^{255}}{\displaystyle \frac{{(o_i-\exp )}^2}{\exp }},$$

(3)

where:

• $o_i$: Observed frequency of pixels with intensity level i.
• $\exp$: Expected frequency of each intensity level under a uniform distribution, computed as the total number of pixels in the image divided by 256.

2.4. Texture Analysis

Texture analysis is performed using the Gray-Level Co-occurrence Matrix (GLCM), which characterizes the spatial relationships between neighboring pixel intensities in an image [32].

The GLCM energy, denoted by E, measures the uniformity of the gray-level distribution in the image. An energy value of 1 corresponds to a completely uniform image, whereas values approaching 0 indicate greater randomness and lower uniformity, which are desirable properties for encrypted images. The energy is computed using Equation (4).

$$E={\displaystyle \sum _{i=1}^{256}}{\displaystyle \sum _{j=1}^{256}}g{(i,j)}^2,$$

(4)

where:

• $g(i,j)$: GLCM element located at row i and column j.

The GLCM homogeneity, denoted by $H^{*}$, evaluates the similarity between neighboring gray levels. It assigns greater weight to pixels with similar intensities and is defined in Equation (5). Lower homogeneity values indicate weaker spatial dependence between adjacent pixels, which is a desirable characteristic of encrypted images because it reflects a more random texture. As $H^{*}$ decreases within the range [0, 1], the quality of the encryption increases.

$$H^{*}={\displaystyle \sum _{i=1}^{256}}{\displaystyle \sum _{j=1}^{256}}{\displaystyle \frac{g(i,j)}{1+|i-j|}}.$$

(5)

The GLCM contrast, denoted by C, measures the local variations in gray-level intensities by quantifying the differences between neighboring pixels. It is computed according to Equation (6).

$$C={\displaystyle \sum _{i=1}^{256}}{\displaystyle \sum _{j=1}^{256}}{(i-j)}^{2}g(i,j).$$

(6)

2.5. Avalanche Effect

The avalanche effect, denoted by $AE$, is another metric for evaluating the security of encryption algorithms [33]. It measures the sensitivity of the encryption algorithm to small changes in either the plaintext or the secret key. Ideally, modifying a single input bit should cause approximately half of the output bits to change, indicating a strong diffusion property [34]. In this work, the avalanche effect is employed to evaluate the diffusion capability of the proposed algorithm by comparing pairs of ciphertexts whose plaintexts or secret keys differ by a single bit. The avalanche effect is computed according to Equation (7).

$$AE={\displaystyle \frac{{\sum }_{i=1}^n\left(C_{1,i}\oplus C_{2,i}\right)}{n}}\times 100\%,$$

(7)

where:

• $HD(C_1,C_2)={\sum }_{i=1}^n\left(C_{1,i}\oplus C_{2,i}\right)$ is the Hamming distance between the two ciphertexts $C_1$ and $C_2$, computed by applying the XOR operation to the corresponding bits of $C_1$ and $C_2$.
• n is the total number of bits in the ciphertext.

2.6. Throughput

Throughput, denoted by T, is a performance metric [35] that quantifies the amount of data processed by an encryption algorithm per unit time, expressed in bytes per second (B/s). It is defined as the average number of bytes encrypted per second and is computed according to Equation (8). Higher throughput values indicate a faster encryption process.

$$T={\displaystyle \frac{D}{t}},$$

(8)

where:

• D is the size of the encrypted data in bytes.
• t is the time, in seconds, required to encrypt D bytes.

2.7. Speck

For comparison purposes, the reference implementation employs the Speck128/128 symmetric block cipher [19] configured with a 128-bit block size, a 128-bit secret key, and 32 encryption rounds. The cipher adopts the original ARX structure, which is based on modular addition, bitwise rotations, and XOR operations, using the rotation constants $\alpha =8$ and $\beta =3$. Encryption is performed in Counter (CTR) mode, where a fixed 64-bit nonce is concatenated with a continuously incremented 64-bit global counter to generate the keystream. The secret key is derived from the user password followed by zero-padding to obtain a 128-bit key. To ensure a fair comparison with the proposal, each sensor record is encrypted independently. Unlike conventional Speck implementations, which typically encrypt an entire file or message as a continuous data stream, this work preserves the global counter across consecutive sensor records, ensuring that each nonce-counter pair remains unique throughout the encryption process and preventing keystream reuse.

2.8. Ascon

For comparison, the reference implementation also employs Ascon-AEAD128 [36], the authenticated encryption function standardized by NIST in SP 800-232. Ascon is a permutation-based scheme in which confidentiality and integrity are obtained from a single construction. The scheme operates on a 320-bit internal state organized as five 64-bit words and divided into a 128-bit rate and a 192-bit capacity, and is configured with a 128-bit key, a 128-bit nonce, and a 128-bit authentication tag. The state is initialized using a fixed initialization vector, the key, and the nonce, and is then transformed through 12 rounds during the initialization and finalization phases and 8 rounds between data blocks. Plaintext blocks are absorbed into the rate, and the resulting rate value is output directly as ciphertext. The authentication tag is extracted from the state during finalization. The secret key is derived from the user password followed by zero-padding to obtain a 128-bit key, as in Speck. To ensure a fair comparison with the proposal, each sensor record is encrypted independently with a distinct nonce.

3. Proposed Encryption Scheme

This section presents the proposed scheme. First, the preprocessing stage, which is executed on both the ESP32 and the Android mobile device, is described. Next, the permutation generation algorithm is introduced, in which the permutation is derived from the secret key and the $\pi$-based string. Subsequently, the procedure for acquiring and formatting the electrical sensor data to construct the plaintext is presented. The encryption process is then detailed by integrating the preprocessing stage, the generated permutation, and the sensor-data string. Finally, the decryption procedure, which is executed on the mobile device, is described.

To facilitate the understanding of the proposed scheme, three diagrams are provided. Figure 1 illustrates the complete encryption process, including the preprocessing stage and the generation of the plaintext from the electrical sensor data. To ensure reproducibility, the permutation procedure is detailed in Algorithm 1, while the pseudocode of the encryption procedure is given in Algorithm 2. Figure 2 presents the corresponding decryption process executed on the mobile device, whose pseudocode is provided in Algorithm 3. Figure 3 provides an overview of the complete communication process, including both the encryption and decryption processes. Finally, Figure 4 presents screenshots of the developed mobile application and the ESP32-based hardware implementation. Figure 4a shows the date-selection screen, Figure 4b displays the decrypted sensor records in tabular form, and Figure 4c illustrates the ESP32-based hardware implementation.

Figure 1. Encryption procedure of the proposal, including the preprocessing stage and the generation of the plaintext from the electrical sensor data.

Figure 2. Decryption procedure executed on the mobile device, including the preprocessing stage and plaintext recovery.

Figure 3. Overall architecture of the proposed secure communication, showing the encryption process on the ESP32 and the corresponding decryption process on the mobile device.

Figure 4. Implementation. (a) Initial screen for selecting the date range and entering the decryption password. (b) Display of the decrypted sensor measurements. (c) ESP32-based hardware setup used for sensor data acquisition and encryption.

3.1. Preprocessing

The following steps must be completed prior to the encryption or decryption process.

1.

A secret key K consisting of eight characters (64 bits) is established for each user.

2.

Starting from the original 64-bit secret key, 63 additional keys are generated by performing successive one-bit circular left shifts. Together with the original key, these form a sequence of 64 different 64-bit strings. The resulting bit stream is denoted by $S_k$.

3.

The first 20,480 bytes of the fractional part of $\pi$ in the hexadecimal format are extracted to construct a byte string of the same length, denoted by $S_{\pi }$.

4.

A byte-wise XOR operation is performed between $S_{\pi }$ and $S_k$. Since $S_k$ contains only 512 bytes, it is reused cyclically until all 20,480 bytes of $S_{\pi }$ have been processed. The resulting byte string is denoted as $S_x$.

5.

The secret key is interpreted as a 64-bit integer. The remainder of this integer modulo 20,480, denoted by r, is computed to determine the starting position within the string $S_x$ used by the permutation algorithm.

3.2. Permutation Algorithm

The following algorithm generates a permutation of n elements:

1.

Beginning at position r, the next $2n$ bytes of $S_x$ are extracted to form the array A.

2.

Equation (9) is applied to generate n coefficients $c_i$, for $0\le i\le n-1$, each represented by one byte and stored in the array C. The inputs $a_i$ correspond to consecutive two-byte values extracted from the array A.

$$c_i=a_{i}mod(n-i).$$

(9)

3.

An array I is initialized with the integers in ascending order from 0 to $n-1$.

4.

The permutation array P is then constructed iteratively. At each iteration, Equation (10) is computed:

$$P\left[i\right]=I\left[C\right[i\left]\right],$$

(10)

after which the selected element is removed from further consideration by replacing it with the last available element, as shown in Equation (11):

$$I\left[C\right[i\left]\right]=I[n-i-1].$$

(11)

This procedure is repeated for $0\le i\le n-1$, ensuring that each element is selected exactly once and that P is a valid permutation.

Algorithm 1 Permutation generation

Require: Byte string $S_x$, integer n, and starting position r Ensure: Permutation array P   1: Extract $2n$ consecutive bytes from $S_x$, starting at position r, and store them in A   2: for $i=0$ to $n-1$ do   3:       Extract next two-byte value $a_i$ from A   4:       $C\left[i\right]\leftarrow a_{i}mod(n-i)$   5: end for   6: $I\leftarrow [0,1,\dots ,n-1]$   7: for $i=0$ to $n-1$ do   8:       $P\left[i\right]\leftarrow I\left[C\right[i\left]\right]$   9:       $I\left[C\right[i\left]\right]\leftarrow I[n-i-1]$ 10: end for 11: return P

3.3. Electrical Sensor Data Collection

The procedure for acquiring the electrical sensor data consists of the following steps:

1.

Voltage and current are measured using the ZMPT101B voltage sensor and the SCT-013-000 current sensor, respectively. The analog outputs of both sensors, which represent the measured electrical quantities as proportional voltage signals, are connected to the analog input pins of the ESP32 microcontroller.

2.

The ESP32 converts the analog signals into digital values using its built-in Analog-to-Digital Converter (ADC). Each acquired sample is represented as shown in Equation (12):

$$V_{\mathrm{ADC}}\left(i\right),$$

(12)

where i denotes the sample index and $V_{\mathrm{ADC}}$ is the corresponding digital value produced by the ADC.

3.

The DC offset is estimated by computing the average value of the acquired samples as Equation (13) indicates:

$$\mathrm{Offset}={\displaystyle \frac{1}{N}}{\displaystyle \sum _{i=1}^N}{V}_{\mathrm{ADC}}\left(i\right),$$

(13)

where N is the total number of samples and $V_{\mathrm{ADC}}\left(i\right)$ denotes the i-th acquired sample.

4.

Each sample is corrected by subtracting the estimated offset as shown in Equation (14):

$$V_{\mathrm{AC}}\left(i\right)=V_{\mathrm{ADC}}\left(i\right)-\mathrm{Offset}.$$

(14)

5.

The root-mean-square (RMS) voltage is computed using Equation (15):

$$V_{\mathrm{RMS}}=\sqrt{{\displaystyle \frac{1}{N}}\sum _{i=1}^N{\left(V_{\mathrm{AC}}\left(i\right)\right)}^2}.$$

(15)

This calculation consists of squaring each corrected sample, averaging the squared values, and taking the square root of the resulting mean.

6.

The same procedure is applied to the current measurements to obtain the RMS current, denoted by $I_{\mathrm{RMS}}$.

7.

The electrical power is computed using Equation (16):

$$P=V_{\mathrm{RMS}}{I}_{\mathrm{RMS}}.$$

(16)

8.

The energy consumption is calculated from the measured power over the sampling interval t, as shown in Equation (17):

$$E=Pt.$$

(17)

9.

Finally, the measured quantities are concatenated into the sensor-data string $S_s$ using the format $S_s=$ voltage,current,power,energy, where each numerical value is converted into its character representation and commas are used as delimiters between consecutive measurements. The resulting string constitutes the plaintext input to the proposed encryption scheme.

3.4. Encryption Algorithm

The process of encrypting sensor data on the ESP32 involves the following steps:

1.

A pseudorandom integer x in the range $[0,20,479]$ is generated using the esp_random() function of the ESP32.

2.

A byte-wise XOR operation is performed between the sensor data string $S_s$, obtained according to the procedure described in Section 3.3, and a substring of $S_x$ with the same length as $S_s$, starting at byte position x. If the end of $S_x$ is reached, the extraction continues from the beginning of $S_x$ until a substring with the same length as $S_s$ is obtained. The resulting byte string is denoted as S.

3.

The value of x is appended to the end of S as a two-byte integer. The resulting string retains the notation S and is two bytes longer than in the previous step.

4.

The AES S-box is applied independently to each byte of S.

5.

The permutation derived from the secret key, following the procedure described in Section 3.2, is applied to S (i.e., $P\left(S\right)$). The permutation operates on the hexadecimal representation of the string S. Consequently, if S contains l bytes, the permutation is applied to its $n=2l$ hexadecimal symbols.

Algorithm 2 Encryption of sensor data

Require: Sensor-data string $S_s$, secret key K, and byte string $S_x$ Ensure: Ciphertext   1: Generate a pseudorandom integer $x\in [0,20,479]$ using esp_random()   2: Extract from $S_x$ a substring of length $|S_s|$, beginning at position x, $S_x[x:x+|S_s\left|\right]$   3: $S\leftarrow S_s\oplus S_x[x:x+|S_s\left|\right]$   4: Append x to S as a two-byte integer:        $S\leftarrow S\parallel {Byte}_2\left(x\right)$   5: Apply the AES S-box independently to each byte of S   6: Let $l\leftarrow \left|S\right|$ be the number of bytes in S   7: Convert S to its hexadecimal representation   8: $n\leftarrow 2l$   9: Generate permutation P using Algorithm 1 10: Apply P to the hexadecimal representation of S 11: return Ciphertext:$P\left(S\right)$

3.5. Decryption Algorithm

Before the decryption process begins, the user specifies the date range for the desired query through the Android application. The application retrieves all encrypted sensor records whose timestamps fall within the selected interval. The decryption procedure described in this subsection is then applied independently to each retrieved record.

1.

Apply the inverse permutation $P^{-1}$, generated from the secret key K according to the procedure described in Section 3.2, to the hexadecimal representation of the encrypted string.

2.

Apply the inverse AES Substitution Box (inverse S-box) to each byte of the resulting sequence to recover the intermediate string S.

3.

Extract the last two bytes of S and interpret them as a two-byte integer, which determines the starting position x in the string $S_x$.

4.

Perform a byte-wise XOR operation between the encrypted data contained in S and the substring of $S_x$ beginning at position x, where $S_x$ is generated according to the procedure described in Section 3.1.

5.

The resulting plaintext corresponds to the sensor-data string $S_s$, where the individual measurements are separated by commas, i.e., $S_s=$ voltage,current,power,energy.

Algorithm 3 Decryption of sensor data

Require: Ciphertext, secret key K, and byte string $S_x$ Ensure: Sensor-data string $S_s$   1: Convert the ciphertext to its hexadecimal representation   2: Generate the permutation array P using Algorithm 1   3: Apply the inverse permutation $P^{-1}$ to the hexadecimal representation of the ciphertext   4: Convert the resulting hexadecimal sequence into bytes   5: Apply the inverse AES S-box independently to each byte to obtain S   6: Extract the last two bytes of S   7: Interpret the extracted bytes as a two-byte integer:        $x\leftarrow {Byte}_2^{-1}\left(S[-2:]\right)$   8: Remove the last two bytes from S and update S to denote the resulting string.   9: Extract from $S_x$ a substring of length $\left|S\right|$, beginning at position x 10: $S_s\leftarrow S\oplus S_x[x:x+|S\left|\right]$ 11: return $S_s$

4. Results

This section presents the results of the proposed LSEPI cryptosystem, focusing first on security and then on computational performance.

To provide a robust statistical evaluation, the analysis is performed on grayscale images of size $256\times 256$ generated by concatenating the encrypted sensor-data strings, rather than evaluating each encrypted string individually. Figure 5 presents the five images considered in the analysis. The first image is constructed from the plaintext sensor-data strings. The second image is generated from the encrypted strings produced by the proposed LSEPI cryptosystem. The third and fourth images are obtained by encrypting the same plaintext strings using the Speck algorithm in CTR and ECB modes, respectively, while the fifth image is obtained using Ascon. The corresponding histograms of these five images are shown in Figure 6.

Figure 5. Comparison of the grayscale images used for the statistical security analysis: (a) Plaintext image constructed from the sensor-data strings. (b) Image encrypted using the proposed LSEPI. (c) Image encrypted using Speck in CTR mode. (d) Image encrypted using Speck in ECB mode. (e) Image encrypted using Ascon.

Figure 6. Histograms corresponding to the grayscale images presented in Figure 5, where the red line indicates the expected frequency under a uniform distribution. (a) Plaintext image. (b) LSEPI encrypted image. (c) Speck-CTR encrypted image. (d) Speck-ECB encrypted image. (e) Ascon encrypted image.

The quantitative results are summarized in Table 1, which reports the statistical metrics for the plaintext image and the images encrypted using LSEPI, Speck-CTR, Speck-ECB, and Ascon. As discussed in Section 2, an entropy value approaching the theoretical maximum of 8.0 indicates a high degree of randomness. For the chi-square goodness-of-fit test, values below 308 indicate that the histogram does not significantly deviate from a uniform distribution at a significance level of $\alpha =0.01$. Correlation coefficients close to zero indicate weak linear dependencies between adjacent pixels, reflecting effective decorrelation. Regarding the GLCM texture features, higher contrast values, together with lower homogeneity and energy values, indicate a more random texture and, consequently, stronger resistance against statistical attacks.

Table 1. Statistical security metrics of the plaintext image and the encrypted images generated using the proposed LSEPI, Speck-CTR, Speck-ECB, and Ascon, including information entropy, the chi-square goodness-of-fit test, correlation coefficients, and GLCM-based texture features.

Metric	Plain	LSEPI	Speck-CTR	Speck-ECB	Ascon
Entropy	3.2004	7.9971	7.9970	7.9583	7.9969
Chi-square	2,121,955.141	262.742	270.969	4037.992	278.734
Horizontal Correlation	−0.1473	0.0047	0.0003	−0.0265	−0.0051
Vertical Correlation	−0.0182	−0.0064	0.0086	0.0975	−0.0107
Diagonal Correlation	−0.0670	−0.0024	−0.0012	−0.0030	0.0026
GLCM Contrast	0.000	10.461	10.515	10.964	10.562
GLCM Homogeneity	1.000	0.390	0.389	0.385	0.389
GLCM Energy	1.000	0.016	0.016	0.016	0.016

In addition to the statistical metrics presented in Table 1, the test suite specified in the NIST SP 800-22 standard was applied to evaluate the degree of randomness of a bit string [37]. A sequence of 1,000,000 bits was generated by concatenating the encrypted sensor-data records produced by LSEPI. Table 2 presents the p-values obtained for each test.

Table 2. Results of the NIST SP 800-22 statistical test suite applied to the 1,000,000-bit sequence generated from concatenated LSEPI-encrypted sensor-data records.

Test	p-Value	Result
Frequency	0.651	Pass
Block Frequency	0.326	Pass
Cumulative Sums (1)	0.858	Pass
Cumulative Sums (2)	0.498	Pass
Runs	0.604	Pass
Longest Run	0.697	Pass
Rank	0.801	Pass
FFT (Spectral)	0.762	Pass
Overlapping Template	0.176	Pass
Universal Statistical	0.359	Pass
Approximate Entropy	0.179	Pass
Linear Complexity	0.654	Pass
Serial (1)	0.179	Pass
Serial (2)	0.030	Pass

As a complementary analysis, Table 3 evaluates the avalanche effect for 1600 pairs of sensor-data strings differing by one plaintext bit, while Table 4 considers the same number of pairs differing by one key bit. An ideal encryption algorithm should produce ciphertexts that differ in approximately 50% of their bits despite the minimal difference in the plaintext or the key. Table 3 and Table 4 present the maximum, minimum, and average avalanche-effect values observed during the experiments. In addition, Figure 7 shows the avalanche-effect distributions for one-bit changes in the plaintext and secret key. Specifically, Figure 7a corresponds to a one-bit change in the plaintext, while Figure 7b corresponds to a one-bit change in the secret key.

Table 3. Avalanche effect evaluation of LSEPI by modifying a single bit in the plaintext.

Case	Plaintext	Ciphertext (Hex)	Avalanche Effect
Max	117.03, 0.00, 0.00, 0.24	CF D0 A8 7C 47 61 A5 4C 2F F7 37 2C 78 74 CD E3 FD CC BA 34 FE BE 4A	62.5000%
	117.13, 0.00, 0.00, 0.24	AF 69 5C 83 A0 FE D6 8A 08 0F 2A 03 46 C7 3A BC 20 A6 6F EC B1 2D F0
Min	117.09, 0.00, 0.00, 0.24	E1 1C BB 27 F1 C6 3C 05 9E 57 C9 F9 71 21 55 F4 5B B9 CB FD 0F 7E 60	39.1304%
	116.09, 0.00, 0.00, 0.24	A1 0D 52 F0 E9 42 95 7A F7 D7 85 C1 22 2A FD 14 CF 78 21 7D 6F 78 76
Average			50.0055%

Table 4. Avalanche effect evaluation of LSEPI by modifying a single bit in the secret key.

Case	Secret Key	Ciphertext (Hex)	Avalanche Effect
Max	B68F91BACDCF3236	4D 41 7B BA 52 96 8A 9D 11 BE D3 7B E6 D4 8E E0 6E F3 BC 57 B8 06 F1	61.9565%
	B68F91BACDCE3236	A1 9D 9E 54 17 6F D8 74 C3 9A 2D 86 58 37 0B 1B 49 40 5E AE 6F 31 09
Min	B68F91B532303236	1F 79 85 34 0D 29 8C A7 84 A7 65 CA D7 81 7E 88 AF 80 A1 0F EA 81 E8	38.0435%
	B68F91A532303236	5B D3 34 F6 EB 39 AE 04 ED AE 65 6E 56 82 37 9D 62 01 62 1D A6 E5 07
Average			50.0842%

Figure 7. Avalanche-effect distributions for one-bit changes in: (a) The plaintext. (b) The secret key.

Table 5 summarizes the performance evaluation of the proposed scheme. The reported metrics include the preprocessing time on both the ESP32 and the Android device, the encryption time on the ESP32, the decryption time on the Android application, and the execution time required for sensor data acquisition and the computation of the electrical parameters. In addition, Table 5 reports the throughput, expressed in processed bytes per second.

Table 5. Performance metrics of the proposed LSEPI.

Metric	ESP32	Android
Preprocessing (μs)	2062	66
Encryption Time (μs)	135	–
Decryption Time (μs)	–	4
Throughput (bytes/s)	167,975	5,348,837
Sensor Reading and $S_s$ Generation (μs)	288,597	–

5. Results Analysis and Discussion

The results and discussion are organized according to the following aspects: statistical evaluation, key strength, attack models, avalanche effect, computational performance, modulo bias in the permutation, and current limitations of the proposed cryptosystem.

5.1. Statistical Evaluation

This section begins with the statistical security analysis of the proposed LSEPI cryptosystem. The obtained results are compared with those of the Speck cipher operating in CTR and ECB modes and of Ascon, as well as with the original plaintext sensor data. Rather than evaluating individual sensor records, the analysis is performed on five grayscale images constructed by concatenating multiple sensor-data records. Four of these images correspond to the encrypted data generated by LSEPI, Speck-CTR, Speck-ECB, and Ascon, whereas the remaining image is constructed from the plaintext records. This approach provides a more robust statistical evaluation by considering a substantially larger amount of data.

As shown in Figure 5a, the plaintext sensor records produce a highly homogeneous image. Its corresponding histogram, presented in Figure 6a, reveals that only a limited number of character values are present, resulting in a highly non-uniform distribution. This behavior highlights the importance of encrypting sensor data, since electrical consumption measurements often vary within a limited range. Consequently, the plaintext may reveal sensitive patterns related to the activities of a household or organization, thereby compromising users’ privacy.

The proposed LSEPI cryptosystem successfully eliminates these statistical patterns. As reported in Table 1, the entropy increases from 3.2004 for the plaintext image to 7.9971 after encryption, approaching the theoretical maximum value of 8.0. It is noteworthy that this result is achieved using only a single encryption round. By comparison, Speck-CTR reaches a similar entropy value of 7.9970 after 32 rounds, whereas Speck-ECB achieves a lower entropy of 7.9583. Ascon, on the other hand, achieves an entropy value of 7.9969, which is very close to those of LSEPI and Speck-CTR. Furthermore, the proposed method outperforms other recent works [20,22], which reached entropy values of only 7.18.

The chi-square goodness-of-fit test further confirms the effectiveness of the proposed method. Since values below 308 indicate that the histogram does not significantly deviate from a uniform distribution, the proposed cryptosystem satisfies this criterion. Specifically, it achieves a value of 262.74, whereas Speck-CTR and Ascon obtain 270.97 and 278.73, respectively. These results indicate that LSEPI produces a histogram that more closely approximates the ideal uniform distribution. In contrast, Speck-ECB yields a chi-square statistic greater than 4000, failing the uniformity test. This behavior is also evident from the visible patterns remaining in the Speck-ECB-encrypted image shown in Figure 5d.

The correlation analysis also demonstrates the effectiveness of the proposed cryptosystem. The plaintext image exhibits a relatively high correlation between adjacent pixels, whereas the encrypted images produce correlation coefficients close to zero, indicating the successful removal of spatial dependencies. Among the evaluated methods, Speck-CTR achieves the lowest horizontal correlation coefficient (0.0003), while LSEPI obtains the lowest vertical correlation coefficient ($-0.0064$). The diagonal correlation coefficients are comparable among the three algorithms, with values close to zero (approximately $-0.001$). Furthermore, LSEPI consistently achieves lower correlation coefficients in absolute value than Speck-ECB and Ascon across all three directions.

Finally, the texture analysis based on the GLCM demonstrates that encryption substantially modifies the structural characteristics of the image. The plaintext image exhibits the minimum possible contrast (0) and the maximum homogeneity (1), reflecting its highly regular texture and poor suitability for secure information transmission. After encryption, the proposed LSEPI cryptosystem achieves a contrast value of approximately 10.5 and a homogeneity value close to 0.39, which are comparable to those obtained by Speck-CTR and Ascon, reflecting a more random texture than that of the plaintext image. Although Speck-ECB achieves a slightly higher contrast (10.96) and a lower homogeneity (0.385), these apparently favorable texture metrics are inconsistent with its poor entropy and chi-square results, as well as with the visible patterns observed in Figure 5d. This observation demonstrates that no single statistical metric is sufficient to assess the security of an encryption algorithm and highlights the importance of employing multiple complementary evaluation criteria.

Regarding the results presented in Table 2, all tests are passed, as their corresponding p-values exceed the significance level $\alpha =0.01$. It is worth noting that individual encrypted sensor records are not expected to contain 1,000,000 bits. Instead, this sequence length was used to satisfy the input requirements of the NIST SP 800-22 test suite. The results indicate that the concatenated bits of the encrypted sensor-data records exhibit random-like behavior according to the applied statistical tests.

Furthermore, since the plaintext sensor record $S_s$ contains measurements and computed parameters from the electrical sensors, these values vary in magnitude. Consequently, the character length of each parameter, and thus the total length of $S_s$, is variable. To accommodate this variable-length plaintext, the comma character “,” is included as a delimiter between consecutive parameters. Thus, each parameter can be uniquely identified regardless of the number of characters required for its representation.

Although the comma character appears systematically in the plaintext format, the subsequent encryption operations transform the complete string, including the delimiters, through the XOR, substitution, and permutation stages. As shown by the statistical results reported in Table 1, the encrypted representation does not exhibit evident patterns associated with the original structured sensor format. Additionally, the decrypted string can be parsed using the comma delimiter to recover the individual measurements, regardless of their length.

5.2. Key Strength

Based on a user-entered password, the mobile application executes a decryption process for multiple sensor records. For usability purposes, commercial mobile applications commonly use a minimum password length of eight characters. Therefore, to preserve the usability of the application, an eight-character password is considered in the current implementation.

It is important to distinguish, however, between the password length and the effective entropy of the resulting key. An eight-character password does not necessarily provide 64 bits of effective entropy when it is selected by a human, since human-generated passwords are generally not uniformly distributed and may contain predictable patterns. In contrast, if a 64-bit value is generated uniformly at random and used as the secret key, the corresponding theoretical key space is $2^{64}$. Thus, a brute-force attack against a uniformly generated 64-bit key would require, in the worst case, $2^{64}$ key trials. To illustrate the current implementation, the password used in the experiments is “IpnE2026”. This value is employed solely as an experimental password and should not be interpreted as providing 64 bits of effective entropy. For scenarios requiring stronger security, users can adopt cryptographically secure, system-suggested passwords [38]. Such passwords can provide substantially higher entropy than human-chosen passwords without increasing the user’s cognitive burden [39].

The incorporation of a Key Derivation Function (KDF), such as PBKDF2, is also a relevant consideration for strengthening password-based key derivation. However, the current proposal encrypts individual sensor records on the ESP32 and uses the Android device to decrypt multiple records. Consequently, introducing a computationally intensive KDF on the ESP32 would impose additional computational overhead on the resource-constrained device, which already performs the permutation and substitution operations required by the encryption process. In contrast, the computational cost of a KDF would be considerably less restrictive on the Android device during decryption. Therefore, the implementation prioritizes the ESP32 resource limitations while maintaining efficient batch decryption on the Android application. Future work will explore integrating a standard KDF to mitigate offline brute-force attacks, while evaluating the resulting computational overhead on the ESP32 platform.

5.3. Attack Models

Two threat models are analyzed below according to the information available to the adversary: a ciphertext-only attack and a known-plaintext attack.

5.3.1. Ciphertext-Only Attack

In a ciphertext-only attack, the adversary has access exclusively to one or more ciphertexts and attempts to recover the corresponding plaintexts or infer information about the secret key [40]. In the proposed system, the ciphertext is obtained by combining the sensor data with a sequence derived from the decimal digits of $\pi$ and the key, together with the randomly selected starting position x used for the XOR operation. The resulting string is subsequently processed by the substitution and permutation stages. The use of the decimal expansion of $\pi$ does not provide secrecy by itself, since these digits are publicly known. The proposed construction achieves secrecy by combining this deterministic source with secret-dependent material and a randomly generated starting index x computed by the ESP32 for each encryption instance.

The index x is appended to the intermediate string, before the substitution and permutation stages, using its two-byte representation. This representation was selected instead of appending a delimiter character, such as a comma, to avoid introducing a fixed and recognizable ASCII pattern into the ciphertext. Such a pattern could remain identifiable after subsequent transformations. Furthermore, the permutation stage operates on hexadecimal symbols rather than complete bytes, doubling the number of elements involved in the permutation and increasing the diffusion of the resulting representation.

To further evaluate the ciphertext from the perspective of a ciphertext-only adversary, multiple encrypted sensor strings were concatenated to form an image. The statistical results reported in Table 1 indicate that the resulting ciphertext does not exhibit evident statistical patterns that can directly reveal the structure of the underlying sensor records. In particular, the substitution and permutation stages are intended to introduce nonlinear transformation and diffusion between the original sensor data and its encrypted representation.

5.3.2. Known-Plaintext Attack

In a known-plaintext attack, the adversary is assumed to possess one or more pairs consisting of a plaintext $PT$ and its corresponding ciphertext $ET$ [40]. In practice, an adversary may be able to infer or obtain portions of the plaintext corresponding to a given ciphertext. Consider first a simplified version of the encryption process in which the ciphertext is given by Equation (18):

$$ET=SB\left(PT\oplus \left(S_x[x:x+l]\right)\parallel x\right),$$

(18)

where $SB$ denotes the substitution-box application, $PT$ is the plaintext, $S_x[x:x+l]$ denotes the l-byte segment beginning at position x of the masking sequence $S_x$, and ∥ denotes concatenation with the index x. Since the S-box is public and static, an adversary can compute its inverse $S{B}^{-1}$ and obtain the result of Equation (19):

$$S{B}^{-1}\left(ET\right)=PT\oplus \left(S_x[x:x+l]\right)\parallel x.$$

(19)

After removing the index x from Equation (19) and applying the XOR operation with the known plaintext $PT$, the adversary can recover the corresponding segment of the masking sequence, as shown in Equation (20):

$$S_x[x:x+l]=PT\oplus S{B}^{-1}\left(ET\right).$$

(20)

This observation is important because the masking sequence $S_x$ is generated from the secret key sequence $S_k$ combined with the decimal digits of $\pi$, denoted by $S_{\pi }$. Since the digits of $\pi$ are publicly available, the adversary can obtain $S_{\pi }$ and isolate the segment associated with the secret key as shown in Equation (21):

$$S_k[x:x+l]=S_x[x:x+l]\oplus S_{\pi }[x:x+l].$$

(21)

Consequently, if the recovered segment of $S_k$ is sufficiently long to contain a complete 64-bit rotated key, the adversary may recover a rotated representation of the secret key. This is possible when the starting position x is aligned with the beginning of a rotated key, or when the length l of the recovered segment is sufficient to skip the required number of bytes such that the resulting position is a multiple of 8. Since the key is 64 bits long (8 bytes), the recovered segment must contain at least one complete 8-byte key representation. The original key can then be recovered by testing the possible circular rotations, resulting in at most 64 candidate rotations.

Therefore, the previous steps reveal a known-plaintext key-recovery path. This observation highlights the importance of analyzing the complete encryption structure, rather than focusing only on the pipeline from the substitution box onward. In the proposed algorithm, the actual ciphertext is generated according to Equation (22):

$$ET={\mathrm{\Pi }}_k\left(SB\left(PT\oplus \left(S_x[x:x+l]\right)\parallel x\right)\right),$$

(22)

where ${\mathrm{\Pi }}_k$ denotes the key-dependent permutation applied during the encryption process. Consequently, an adversary must additionally determine or invert the relevant permutation before applying the preceding recovery procedure. Since the permutation is applied to hexadecimal symbols rather than complete bytes, the permutation operates over $2l$ elements for an l-byte input.

Accordingly, the complexity of recovering the segment of the key-dependent sequence from a known plaintext-ciphertext pair is not limited to the XOR operation described above. The adversary must first account for the key-dependent permutation over the corresponding hexadecimal symbols. Thus, the complete known-plaintext key-recovery problem involves both the recovery of the permutation and the subsequent extraction of the key-dependent masking sequence.

5.4. Measured Avalanche Effect

Regarding the avalanche effect, Table 3 indicates that the maximum avalanche effect achieved by the proposed cryptosystem was 62.50%, whereas the minimum was 39.13%. The average avalanche effect was 50.005%, which is close to the ideal value of 50%. These results were obtained from 1600 pairs of encrypted sensor-data strings whose corresponding plaintexts differ by a single bit. Similarly, Table 4 indicates that the maximum avalanche effect was 61.96%, whereas the minimum was 38.04%. The average avalanche effect was 50.08%, based on 1600 pairs of encrypted sensor-data strings whose corresponding secret keys differ by a single bit. These results indicate that, on average, changing a single bit in either the plaintext or the secret key changes approximately half of the ciphertext bits, demonstrating a high degree of diffusion. In addition, as shown in Figure 7, values are mainly concentrated between 45% and 55% for one-bit changes in both the plaintext (Figure 7a) and the secret key (Figure 7b).

The achieved avalanche performance is primarily attributed to the dynamic selection of the XOR mask for each plaintext message. Specifically, the last two bytes of the intermediate encrypted string determine the starting position within the string $S_x$, which is generated from the secret key and the decimal digits of $\pi$. Consequently, modifying a single bit of the secret key changes $S_x$ and, therefore, the resulting XOR mask. In addition, the byte sequence extracted from $S_x$ for the XOR operation varies from one message to another due to the dynamically selected starting position. Therefore, even when two plaintext messages are identical, they are highly likely to be combined with different portions of $S_x$, producing distinct XOR outputs and, consequently, different substitution and permutation results. The probability that two messages use the same starting position is only $1/20,480$, corresponding to the number of available positions in $S_x$. Although this probability could be further reduced by extending the length of $S_x$, doing so would require additional storage resources on the ESP32. The combination of this dynamic XOR operation with the pseudorandom distribution of the digits of $\pi$ significantly enhances the diffusion capability of the proposed cryptosystem.

5.5. Computational Performance

Regarding the computational performance reported in Table 5, the preprocessing stage includes the secret-key processing, the generation of the key array, the retrieval of the first 20 KB of the decimal expansion of $\pi$, the XOR operation between the two strings, and the computation of the permutation offset derived from the secret key. This stage requires 2062 μs on the ESP32-WROOM, which is equipped with a dual-core Tensilica LX6 processor operating at 240 MHz. The same procedure requires only 66 μs on the Android mobile device, which is equipped with an Exynos 2400 processor operating at 2.9 GHz. It is important to note that this preprocessing stage is executed only once during the initialization of the algorithm.

After initialization, each sensor record is encrypted independently. The proposed encryption algorithm requires an average of 135 μs per record on the ESP32. This execution time includes the XOR operation between the plaintext sensor-data string and the dynamically selected segment of $S_x$, the generation of the dynamic index, its concatenation to the string, the AES S-box substitution, and the dynamic permutation of the hexadecimal representation of the ciphertext. In contrast, the corresponding decryption process requires only 4 μs per record on the Android device. These execution times correspond to encryption and decryption throughputs of 167,975 and 5,348,837 bytes/s, respectively. The decryption throughput is substantially higher than the encryption throughput, which is advantageous because the mobile application can decrypt multiple sensor records while the ESP32 is acquiring and encrypting new measurements. In practice, while the ESP32 encrypts a single sensor record, the Android device can decrypt approximately 34 records, compensating for the difference in processing times between the two devices.

Finally, the acquisition and computation of the electrical variables, including voltage, current, power, and energy consumption, require an average of 288,597 μs. Incorporating the proposed security layer increases this execution time by only 2197 μs for the first encrypted record, corresponding to an overhead of approximately 0.7%, and by only 135 μs (0.04%) for each subsequent record. These results demonstrate that the proposed cryptosystem introduces a negligible computational overhead for providing a layer of security for the transmitted data.

For comparison, the encryption time of Speck-CTR on the same ESP32 device was 28 μs for a sensor-data record of the same length. This shorter execution time can be attributed primarily to its ARX-based structure, which relies on modular addition, bitwise rotation, and XOR operations, as discussed previously. In contrast, Ascon required 128 μs to encrypt a sensor-data record of the same length on the same device. This difference reflects the additional computational cost associated with the permutation-based operations employed by Ascon compared with the simpler ARX operations used by Speck. In this context, the proposed cryptosystem maintains a competitive encryption time of 135 μs while incorporating its security mechanisms.

5.6. Modulo Bias in Permutation

The permutation procedure employs the modulo operation in two different stages. The first occurrence is given in Equation (9), where the generated values are mapped to the range $[0,n-1]$, with n denoting the number of elements to be permuted. In the proposed scheme, the permutation is applied to hexadecimal symbols rather than complete bytes. Therefore, for an input of l bytes, the number of elements to be permuted is $n=2l$. The coefficient $a_i$ used to generate each permutation value is represented using two bytes, providing $2^{16}=$ 65,536 possible input values. This range was selected to ensure that, for a maximum of 65,536 hexadecimal elements (32,768 bytes), every possible permutation index in the range $[0,n-1]$ can be generated.

The second modulo operation is used to determine the offset for selecting the coefficients $a_i$ from the secret-dependent sequence $S_x$. Specifically, the 64-bit secret value is reduced modulo 20,480 to obtain a valid starting index in the range [0, 20,479]. Since $2^{64}$ is not an integer multiple of 20,480, this operation introduces a modulo bias. In particular, $2^{64}mod$ 20,480 = 4096.

Consequently, among the 20,480 possible starting positions, 4096 positions occur one additional time in the complete set of $2^{64}$ possible 64-bit values, whereas the remaining 16,384 positions occur once fewer. Therefore, the probability of selecting one of these 4096 positions is ${\displaystyle \frac{⌊2^{64}/20,480⌋+1}{2^{64}}}$, while the probability of selecting any of the remaining positions is ${\displaystyle \frac{⌊2^{64}/20,480⌋}{2^{64}}}$. The resulting relative difference between the two probabilities is approximately $1.11\times {10}^{-13}\%$. Although the modulo operation does introduce a theoretical bias (explicitly acknowledged) in the selection of the starting position, its magnitude is negligible for the present construction.

5.7. Limitations

The current proposal does not include an explicit integrity-verification mechanism, such as a Message Authentication Code (MAC) or an Authenticated Encryption with Associated Data (AEAD) scheme. Therefore, the current construction does not provide cryptographic authentication of the ciphertext and may be susceptible to undetected modifications during transmission. Nevertheless, the effect of modifying the encrypted data is not limited to a simple XOR-based transformation. The received ciphertext is processed through the inverse permutation of the hexadecimal symbols and the inverse substitution box. Consequently, an unauthorized modification is propagated through the subsequent decryption process and may result in corrupted plaintext data. However, these transformations should not be interpreted as an integrity-verification mechanism, since they do not allow the receiver to distinguish between an authentic ciphertext and a deliberately modified one.

The omission of an explicit integrity-protection stage is motivated by the computational constraints of the target ESP32 platform. In this architecture, permutation generation and substitution operations dominate the computational cost, while XOR and ARX-based operations remain lightweight. Introducing an additional MAC or AEAD mechanism would impose further computational and memory overhead, directly impacting processing time and resource efficiency. Therefore, this work focuses primarily on confidentiality and computational efficiency. The absence of explicit integrity protection is a recognized design limitation rather than a security property. Future work will investigate integrating an authentication mechanism, such as a MAC or AEAD approach, to provide simultaneous confidentiality and integrity while evaluating its computational overhead on the ESP32.

6. Conclusions

This work proposed LSEPI, a lightweight cryptosystem for protecting electrical sensor data. The cryptosystem adopts a single-round substitution-permutation design that combines the AES S-box and a key-dependent permutation with a dynamically selected XOR mask derived from the number $\pi$. To further reduce the computational overhead, the first 20 KB of the decimal expansion of $\pi$ are stored on both the ESP32 and the Android device, avoiding the runtime cost of pseudorandom sequence generation. The encryption process is performed on the ESP32 during sensor-data acquisition, whereas the corresponding decryption is carried out on an Android mobile device.

From a security perspective, LSEPI achieves an entropy of 7.9971, which is comparable to the values obtained by Speck-CTR (7.9970) and Ascon (7.9969), despite requiring only a single encryption round. This entropy value is also higher than the values of approximately 7.18 reported for some recent lightweight cryptographic proposals. In addition, the proposed cryptosystem satisfies the chi-square goodness-of-fit criterion, indicating a nearly uniform distribution of the encrypted data, and produces correlation coefficients close to zero in the evaluated directions. The avalanche analysis yields average bit-change rates of 50.005% for one-bit modifications of the plaintext and 50.08% for one-bit changes of the secret key, both of which are close to the ideal value of 50%. Furthermore, the GLCM-based texture metrics are comparable to those obtained with Speck-CTR and Ascon. As a complementary analysis, a 1,000,000-bit sequence generated by concatenating LSEPI-encrypted sensor-data records passed all the evaluated statistical tests of the NIST SP 800-22 at a significance level of $\alpha =0.01$, indicating random-like behavior according to the applied statistical tests. Regarding the attack models considered, the known-plaintext attack analysis indicates that recovering the key-dependent masking sequence from plaintext-ciphertext pairs requires the adversary to additionally determine the inverse of the key-dependent permutation applied during the encryption process. Consequently, the known-plaintext attack is not directly sufficient to recover the secret key solely from the XOR relationships observed between the plaintext and ciphertext.

From a computational perspective, the proposed security layer requires an average of only 135 μs to encrypt each sensor record after initialization, corresponding to an additional overhead of approximately 0.04% with respect to the computation of the electrical variables on the ESP32. Moreover, the significantly higher processing capability of the Android device enables it to decrypt approximately 34 sensor records while the ESP32 encrypts a single record, effectively compensating for the difference in processing times between both devices. The encryption time of LSEPI on the ESP32 is also comparable to that of Ascon, which requires 128 μs for a sensor record of the same length. Nevertheless, Speck-CTR achieves a lower execution time of 28 μs, primarily due to its ARX structure, which relies on modular addition, rotation, and XOR operations. These results indicate that LSEPI provides a lightweight security layer with low computational overhead, making it suitable for protecting electrical sensor data in resource-constrained applications.

Despite these results, some aspects remain for future work. In particular, it will address the incorporation of an integrity and authentication mechanism, as well as a standard key derivation function to strengthen resistance against password-based brute-force attacks. Such improvements must be carefully designed with respect to the computational and memory constraints of the ESP32, while also considering the usability requirements of the Android application, where the corresponding decryption process is performed.