Security levels and algorithm combinations.
Open access peer-reviewed article
This Article is part of Communications and Security Section
Article metrics overview
112 Article Downloads
View Full Metrics
Article Type: Research Paper
Date of acceptance: May 2025
Date of publication: June 2025
DoI: 10.5772/acrt.20250024
copyright: ©2025 The Author(s), Licensee IntechOpen, License: CC BY 4.0
Mobile users in mobile cloud environment necessitate multiple data security levels due to resource constraints, data sensitivity, and cyber threats. This study analyzed multiple security levels while optimizing energy consumption in a mobile cloud setting. This was accomplished through CPU execution time models based on various combinations of compression and encryption algorithms. The integration of encryption algorithms such as AES and ECC-AES, as well as compression algorithms such as RLE and Huffman were considered in this study. Text files ranging from 100 to 999 KB were compressed first and then encrypted to obtain the CPU execution time utilized. C# framework was used for the data profiling and RStudio was used for data analysis. AES-Huffman was determined to be the best combination for apps with faster execution needs, and ECC-AES-Huffman as the best option for apps with higher security needs. Different security levels, compression levels, energy consumption rates and optimized CPU execution time models were identified for each algorithm combinations. The AES variants such as AES128-Huffman, AES192-Huffman, AES256-Huffman combinations consumed CPU execution time of 1.92 ms, 4.08 ms and 6.33 ms, respectively. ECC-AES variants such as ECC-AES128-Huffman, ECC-AES192-Huffman, ECC-AES256-Huffman combinations consumed CPU time of 9.58 ms, 19.75 ms and 29.75 ms, respectively. The results confirmed that the increase in security levels led to increase in CPU execution time. Additionally, this study identified the greater compression efficiency of Huffman compression algorithm, compared to RLE. The results of this study may be used to develop a user-initiated costing option to choose mobile user’s preference of security level, compression level and energy consumption rates.
Compression encryption combination
data security
energy consumption
mathematical modelling
optimization
Author information
Mobile Cloud Computing (MCC) mitigates the issues related to the resource-constrained nature of mobile devices. Presently, there is a high boom in the development of complex and numerous apps running on mobile devices. Additionally, mobile device users demand multiple security levels with optimized energy usage in scenarios like online banking, real-time data streaming, Radio/TV broadcasting [1], and so forth. Users prefer high security for sensitive data transfer, medium security for less sensitive data, and less security for applications such as online newspapers. These varied security levels need to be addressed with optimized energy consumption in the resource-constrained mobile computing scenarios. Offering multiple security levels requires analysis of the mobile device’s energy consumption based on cryptographic algorithms’ execution.
Combining compression and encryption enables an efficient and secure data transfer in MCC [2]. The use of compression results in a reduction of data size without compromising the data quality [3]. Reduction of data size enables reduced energy consumption, while encryption enables data security. Integration of compression and encryption enables increased data security and reduced energy consumption [4]. However, higher data security levels demand increased energy consumption because of the intensive computational nature of the cryptographic algorithms.
In a study [1], a comparative study of CPU execution time modeling based on AES and ECC- AES algorithms to encrypt text files was done. The study concluded that AES encryption was appropriate for faster execution, and the ECC-AES algorithm for high security of MCC applications. Our study extends this study [1]. The authors considered mobile users’ varying security level needs, addressing a balance of the mobile device’s energy consumption. AES encryption algorithm, with different key sizes to implement multiple security levels, was integrated with various compression techniques. Our study addressed the security and energy consumption trade-off [5] by proposing multiple security levels based on the device’s energy consumption usage. We categorized the mobile user’s security needs into high, medium, and low levels. This approach balanced the energy consumption usage based on the chosen security levels.
Our study aimed to determine the optimal energy consumption model to evaluate the CPU time used in the combined data compression and encryption processes. The text files were compressed and then encrypted to obtain the CPU execution time. The resultant CPU execution time was used to examine and optimize the energy consumed by the compression encryption combinations. The proposed model was based on AES (symmetric) and ECC-AES (hybrid) encryption algorithms, along with Huffman encoding and RLE compression algorithms.
Many studies have examined the combination of compression and encryption algorithms to address data security and energy consumption in MCC. One study [3] attempted to minimize the energy consumption in MCC and proposed a compression-based energy consumption model. Their model determined the need to compress or not before performing data offloading from a mobile device to the cloud.
A study [6] examined the impact of symmetric encryption algorithms on power consumption. This study concluded that AES was the best encryption algorithm in terms of power consumption. They considered three AES key sizes – 128, 192, and 256 key sizes to evaluate the effect of changing key sizes on power consumption. This study also concluded that as the key size of the AES algorithm increased, the power and time consumption increased accordingly. Another study [7] proposed a MCC scenario that identified only intensive computation tasks to offload to the cloud from the mobile device. The authors attempted to minimize the overall energy consumption and ensure data security using the AES algorithm. However, this study had not addressed the possible multiple security levels using the AES algorithm.
In a study [2] done to examine the combination of compression and encryption in digital documents, the authors proposed performing compression first and then encryption to achieve better data security. A similar study [4] also proposed the implementation of various encryption and compression algorithms to achieve data security based on text files. The authors concluded that Huffman combination yielded lower processing time and faster execution, compared to other compression and encryption combinations. As a future work, they suggested the integration with various combinations of compression and encryption. The authors, in a study [8] worked on integrating AES encryption and Huffman compression algorithms to improve SMS security and data capacity. The study was conducted based on an SMS messaging system and the authors concluded that AES with Huffman yielded better results.
One study [9] combined AES encryption with LZMA compression, providing a comprehensive security solution with faster processing time. Their study followed a multi- layered security approach with compression for data security and data compression. In a similar study [10], the authors attempted to enhance data security in cloud computing through the integration of fully homomorphic encryption (FHE) and data compression. Even though these studies focus on compression and encryption integration, they do not address multiple security levels to address the trade-off between security and energy consumption.
This study analyzes the trade-off between security and energy consumption using various security levels, such as LOW, MEDIUM, and HIGH, with different key sizes of AES algorithm (128, 192, and 256), both as standalone AES and as a combination of ECC-AES algorithms. This study also considers AES and ECC-AES algorithms with Huffman and RLE integration to offer multiple security levels with optimized CPU time. The authors also considered mobile device users’ demand for varying security levels. A higher number of security levels combined with compression techniques was provided compared to [7]. Modern compression techniques such as LZMA, Brotli, and Zstandard provide a better compression ratio compared to traditional compression algorithms such as Huffman and RLE [11]. However, Huffman and RLE operate with lower computational complexity and resource usage. Our study chose Huffman and RLE due to their aptness with MCC, where devices operate in a resource-constrained environment regarding energy consumption, processing power, and memory.
One study [12] examined the influence of 5G wireless technologies on the Internet of Things (IoT) and cloud computing. 5G wireless technologies pave new opportunities for resource-intensive applications, offering high data transmission rates and lower latency. However, the substantial increase in device connections and data exchange demands significant security and privacy requirements. Practitioners [12] have emphasized the importance of establishing strong security measures to protect sensitive data. Strong security measures demand increased energy consumption due to the computational complexity of cryptographic algorithms. Therefore, the security-energy consumption trade-off within the context of MCC still needs to be addressed. Our study is highly significant, considering the evolving security and energy-efficiency demands in the MCC context.
This section discusses our proposed model. Figure 1 depicts the workflow of the study. The possible algorithm combinations were categorized based on the security levels. For each of the algorithm combinations, the dataset was captured through data profiling. Using these datasets, the optimized energy consumption model for each of the algorithm combinations was identified.
Workflow of the study.
This study incorporated three security levels, various algorithm combinations, and small file categories, as shown in Table 1. The security levels, High, Medium, and Low, utilized AES with key sizes of 256-bit, 192-bit, and 128-bit, respectively. This study employed AES algorithm with CBC mode. The algorithm combinations represent the possible integrations of compression and encryption algorithms. The three compression options were “NoCompression”, Huffman Encoding, and RLE. For each security level, AES was paired with all compression options. The same process was followed for the ECC-AES hybrid algorithm as well. The file categories included small files ranging from 100 to 999 KB.
Security level | Algorithm combination | File types |
---|---|---|
High | AES256 + No compression, AES256 + Huffman, AES256 + RLE. | Small |
Medium | AES192 + No compression, AES192 + Huffman, AES192 + RLE. | Small |
Low | AES128 + No compression, AES128 + Huffman, AES128 + RLE. | Small |
High | ECC-AES256 + No compression, ECC-AES256 + Huffman, ECC-AES256 + RLE. | Small |
Medium | ECC-AES192 + No compression, ECC-AES192 + Huffman, ECC-AES192 + RLE. | Small |
Low | ECC-AES128 + No compression, ECC-AES128 + Huffman, ECC-AES128 + RLE. | Small |
Security levels and algorithm combinations.
The computing environment used for this study included Windows 10 Pro Operating System equipped with an Intel i5 Processor, operating with a clock speed of 2.5 GHz. Visual Studio 2015 was employed to run the C# program, which implemented AES and ECC-AES encryption algorithms alongside Huffman Encoding and RLE compression algorithms, to compress and encrypt the text files. For data analysis, RStudio was used.
A software-based approach [1] was employed to collect the data by running a C# program that compressed the selected text file contents, encrypted the compressed data, and recorded the CPU execution time used by the chosen encryption algorithm. In a similar study [1], the authors used a C# program to collect CPU time data for encryption only. This study uses the same software with added functionality to integrate compression algorithms with encryption algorithms.
The experiment was performed using different text files, shown in Table 2. These files were downloaded from the Canterbury Corpus GitHub Repository [1]. Canterbury Corpus is a collection of text files with varying sizes, used for benchmarking compression methods [13] and has been used in different studies.
File name | Original File size in KB |
---|---|
alice29-149KB | 149 |
bib-109KB | 109 |
book2-597KB | 597 |
news-369KB | 369 |
pi-977KB | 977 |
plrabn12-471KB | 471 |
Icet10_2-834KB | 834 |
book1-751KB | 751 |
news_2-737KB | 737 |
bib_6-652KB | 652 |
asyoulik_2-245KB | 245 |
asyoulik-123KB | 123 |
Text files used in this study.
Pre-experimental requirements, such as ending all start-up applications and machine restart, were performed before starting the experiment. Optimized CPU execution time was calculated through various measures such as caching and nested loop usage. The average CPU time was calculated to address the optimized CPU execution time, like the average power consumption calculation [14] and the average processing time [7]. The usage of nested loops with 1000 iterations addressed the possible CPU execution time fluctuation. The principle of nested loops was employed to maintain the consistency and accuracy of datasets by minimizing possible cache effects [15].
The C# program compressed and encrypted 12 text files (ranging from 100 to 999 KB) and recorded the CPU time used by the algorithm combinations depicted in Table 1, for each of the text files. The dataset was obtained after saving the file sizes as X values and the CPU execution times as Y values for all algorithm combinations.
The best-fit mathematical models [1], linear and quadratic models, were generated using the datasets. Piecewise approximation was employed with these models to enhance optimization. Significant models were identified based on a p-value criterion of less than 0.05. The model with the lowest Root Mean Square Error (RMSE) among the significant ones was selected as the most optimized. An R script is used to develop the best-fit models for each algorithm combination.
Data analysis was performed with RStudio [16]. The dataset (with X value as File Size and Y value as CPU execution time), saved as an Excel file, was provided as input to the R script which automated reading data from Excel files, fitting multiple statistical models, evaluating their performance, selecting the best model, and visualizing the results. It processed linear, quadratic, and their piecewise versions to determine the best fit for each dataset based on RMSE and statistical significance.
The R script executed the following steps for each algorithm combination, which comprised of three datasets. For instance, in the case of “High Security,” the algorithm combinations included AES256+NoCompr (indicated as dataset 1), AES256+RLE (dataset 2), and AES256+Huff (dataset 3).
Read the dataset (with X value as File size and Y value as CPU execution time) from the excel file.
Fit four different types of regression models- linear, linear piecewise, quadratic, and quadratic piecewise.
Calculate the RMSE (Root Mean Square Error) and p-value of each model.
Filter the significant models (p-value < 0.05) and select the best model based on the smallest RMSE value.
Combine all the models and the best model, and display details such as model type (linear or quadratic), equation, RMSE, and p-value.
Plot the results using the ggplot2 function, plotting data points and fitting lines to illustrate the best-fitting models for each dataset.
The R script installed and loaded packages such as segmented, sweep, readxl, and ggplot2 to perform data analysis tasks.
This section presents an experimental analysis of data using linear and quadratic models. This section also discusses the linear model, linear piecewise model, quadratic model, quadratic piecewise model, and the best-fit model for each algorithm combination depicted in Table 1.
Figure 2 illustrates a graph presenting the best-fit models for the AES256 algorithm across three compression combinations: “NoCompression,” RLE, and Huffman encoding. Additionally, Figure 2 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of HIGH security with AES. It also provides the best-fit model with corresponding equations and results for each dataset.
AES256 HIGH security model.
For Dataset 1: AES256_NoCompr, the best-fit model was the linear piecewise model, represented by the equation: y = 8.21 +0.04 ∗ x, with a mean value of 28.17.
For Dataset 2: AES256_RLE, the best-fit model was the linear piecewise model, represented by the equation: y = −4.62 +0.06 ∗ x, with a mean value of 23.
For Dataset 3: AES256_Huff, the best-fit model was the linear piecewise model, represented by the equation: y = −2.38 +0.02 ∗ x, with a mean value of 6.33.
These results indicate that the AES256+Huff combination consumed the least CPU time, followed by AES256+RLE, and finally AES256 without compression.
Figure 3 illustrates a graph presenting the best-fit models for the AES192 algorithm across three compression combinations: “NoCompression,” RLE, and Huffman encoding. Additionally, Figure 3 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of MEDIUM security with AES. It also provides the best-fit model with corresponding equations and results for each dataset.
AES192 MEDIUM security model.
For Dataset 1: AES192_NoCompr, the best-fit model was the linear model, represented by the equation: y = 5.35 +0.03 ∗ x, with a mean value of 19.42.
For Dataset 2: AES192_RLE, the best-fit model was the linear piecewise model, represented by the equation: y = −3.7 +0.04 ∗ x, with a mean value of 14.83.
For Dataset 3: AES192_Huff, the best-fit model was the quadratic model, represented by the equation: y = 0.15612 + −0.00204x 1e −05x2, with a mean value of 4.08.
These results indicate that the AES192+Huff combination consumed the least CPU time, followed by AES192+RLE, and finally AES192 without compression.
Figure 4 illustrates a graph presenting the best-fit models for the AES128 algorithm across three compression combinations: “NoCompression,” RLE, and Huffman encoding. Additionally, Figure 4 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of LOW security with AES. It also provides the best-fit model with corresponding equations and results for each dataset.
AES128 LOW security model.
For Dataset 1: AES128_NoCompr, the best-fit model was the linear model, represented by the equation: y = 2.81 +0.01 ∗ x, with a mean value of 9.67.
For Dataset 2: AES128_RLE, the best-fit model was the linear piecewise model, represented by the equation: y = −1.76 +0.02 ∗ x, with a mean value of 7.17.
For Dataset 3: AES128_Huff, the best-fit model was the quadratic model, represented by the equation: y = 0.25762 + −0.00357x + 1e −05x2, with a mean value of 1.92.
These results indicate that the AES128+Huff combination consumed the least CPU time, followed by AES128+RLE, and finally AES128 without compression.
Figure 5 illustrates a graph presenting the best-fit models for the AES256 algorithm across three compression combinations: “NoCompression,” RLE, and Huffman encoding. Additionally, Figure 5 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of HIGH security with ECC-AES. It also provides the best-fit model with corresponding equations and results for each dataset.
ECC-AES256 HIGH security model.
For Dataset 1: ECC-AES256_NoCompr, the best-fit model was the linear model, represented by the equation: y = 9.12 +0.14 ∗ x, with a mean value of 80.5.
For Dataset 2: ECC-AES256_RLE, the best-fit model was the linear model, represented by the equation: y = 6.27 +0.26 ∗ x, with a mean value of 134.92.
For Dataset 3: ECC-AES256_Huff, the best-fit model was the linear piecewise model, represented by the equation: y = 3.99 +0.05 ∗ x, with a mean value of 29.75.
These results indicate that the ECC-AES256+Huff combination consumed the least CPU time, followed by ECC-AES256 without compression, and finally ECC-AES256+RLE.
Figure 6 illustrates a graph presenting the best-fit models for the AES192 algorithm across three compression combinations: “NoCompression,” RLE, and Huffman encoding. Additionally, Figure 6 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of MEDIUM security with ECC-AES. It also provides the best-fit model with corresponding equations and results for each dataset.
ECC-AES192 MEDIUM security model.
For Dataset 1: ECC-AES192_NoCompr, the best-fit model was the linear model, represented by the equation: y = 2.49 +0.1 ∗ x, with a mean value of 53.83.
For Dataset 2: ECC-AES192_RLE, the best-fit model was the linear model, represented by the equation: y = 4.12 +0.17 ∗ x, with a mean value of 90.08.
For Dataset 3: ECC-AES192_Huff, the best-fit model was the linear piecewise model, represented by the equation: y = 1.59 +0.03 ∗ x, with a mean value of 19.75.
These results indicate that the ECC-AES192+Huff combination consumed the least CPU time, followed by ECC-AES192 without compression, and finally ECC-AES192+RLE.
Figure 7 illustrates a graph presenting the best-fit models for the AES128 algorithm across three compression combinations: “No Compression,” RLE, and Huffman encoding. Additionally, Figure 7 displays RMSE values, p-values, and equations of all mathematical models corresponding to each dataset for the scenario of LOW security with ECC-AES. It also provides the best-fit model with corresponding equations and results for each dataset.
ECC-AES128 LOW security model.
For Dataset 1: ECC-AES128_NoCompr, the best-fit model was the linear piecewise model, represented by the equation: y = 2.34 +0.05 ∗ x, with a mean value of 26.5.
For Dataset 2: ECC-AES128_RLE, the best-fit model was the linear model, represented by the equation: y = 2.49 +0.08 ∗ x, with a mean value of 44.83.
For Dataset 3: ECC-AES128_Huff, the best-fit model was the linear piecewise model, represented by the equation: y = 0.88 +0.02 ∗ x, with a mean value of 9.58.
These results indicate that the ECC-AES128+Huff combination consumed the least CPU time, followed by ECC-AES128 without compression, and finally ECC-AES128+RLE.
Table 3 summarizes the optimized mathematical models, equations, CPU execution time of the algorithm combinations, for High, Medium and Low security levels.
Security level | Algorithm combination | Optimized mathematical model equation | Optimized mathematical model | CPU execution time in milliseconds |
---|---|---|---|---|
High | AES256 + No Compression | y = 8.21 +0.04 ∗ x | Linear piecewise | 28.17 |
AES256 + Huffman | y = −2.38 +0.02 ∗ x | Linear piecewise | 6.33 | |
AES256 + RLE. | y = −4.62 +0.06 ∗ x | Linear piecewise | 23 | |
Medium | AES192 + No Compression | y = 5.35 +0.03 ∗ x | Linear | 19.42 |
AES192 + Huffman | y = 0.15612 + −0.00204x + 1e −05x2 | Quadratic | 4.08 | |
AES192 + RLE. | y = −3.7 +0.04 ∗ x | Linear piecewise | 14.83 | |
Low | AES128 + No Compression | y = 2.81 +0.01 ∗ x | Linear | 9.67 |
AES128 + Huffman | y = 0.25762 + −0.00357x + 1e −05x2 | Quadratic | 1.92 | |
AES128 + RLE. | y = −1.76 +0.02 ∗ x | Linear piecewise | 7.17 | |
High | ECC-AES256 + No Compression | y = 9.12 +0.14 ∗ x | Linear | 80.5 |
ECC-AES256 + Huffman | y = 3.99 +0.05 ∗ x | Linear piecewise | 29.75 | |
ECC-AES256 + RLE. | y = 6.27 +0.26 ∗ x | Linear | 134.92 | |
Medium | ECC-AES192 + No Compression | y = 2.49 +0.1 ∗ x | Linear | 53.83 |
ECC-AES192 + Huffman | y = 1.59 +0.03 ∗ x | Linear piecewise | 19.75 | |
ECC-AES192 + RLE. | y = 4.12 +0.17 ∗ x | Linear | 90.08 | |
Low | ECC-AES128 + No Compression | y = 2.34 +0.05 ∗ x | Linear piecewise | 26.5 |
ECC-AES128 + Huffman | y = 0.88 +0.02 ∗ x | Linear piecewise | 9.58 | |
ECC-AES128 + RLE. | y = 2.49 +0.08 ∗ x | Linear | 44.83 |
Algorithm combination details.
The CPU execution time presented in Table 3 was determined for each algorithm combination by calculating the mean value of the CPU execution time. This study determined the energy consumption level based on the CPU execution time recorded for each algorithm combination.
As shown in Table 4, among the HIGH, MEDIUM, and LOW security levels using AES algorithm, AES-Huffman combination was the most efficient in terms of CPU time consumption. As shown in Table 5, among the HIGH, MEDIUM, and LOW security levels using ECC-AES algorithm, ECC-AES-Huffman combination was the most efficient in terms of CPU time consumption. Thus, Huffman was considered as the most efficient compression algorithm for integration with AES and ECC-AES encryption algorithms, based on CPU execution time consumption.
Security level | AES algorithm combination | CPU execution time in milliseconds |
---|---|---|
High | AES256 + No Compression | 28.17 |
AES256 + Huffman | 6.33 | |
AES256 + RLE. | 23 | |
Medium | AES192 + No Compression | 19.42 |
AES192 + Huffman | 4.08 | |
AES192 + RLE. | 14.83 | |
Low | AES128 + No Compression | 9.67 |
AES128 + Huffman | 1.92 | |
AES128 + RLE. | 7.17 |
Comparison of AES algorithm combinations.
Security level | ECC-AES algorithm combination | CPU execution time in milliseconds |
---|---|---|
High | ECC-AES256 + No Compression | 80.5 |
ECC-AES256 + Huffman | 29.75 | |
ECC-AES256 + RLE. | 134.92 | |
Medium | ECC-AES192 + No Compression | 53.83 |
ECC-AES192 + Huffman | 19.75 | |
ECC-AES192 + RLE. | 90.08 | |
Low | ECC-AES128 + No Compression | 26.5 |
ECC- AES128 + Huffman | 9.58 | |
ECC-AES128 + RLE. | 44.83 |
Comparison of ECC-AES algorithm combinations.
This section lists the optimized models for measuring CPU execution time with the Huffman combination:
For AES with HIGH security, the linear piecewise model is most optimized.
For AES with MEDIUM security, the quadratic model is most optimized.
For AES with LOW security, the quadratic model is most optimized.
For ECC-AES with HIGH security, the linear piecewise model is most optimized.
For ECC-AES with MEDIUM security, the linear piecewise model is most optimized.
For ECC-AES with LOW security, the linear piecewise model is most optimized.
Table 4 clearly indicates that among the AES variants across three security levels, AES- Huffman combination consumed the least CPU time, followed by AES-RLE combination, and AES-NoCompression combination. For ECC-AES variants across three security levels depicted in Table 5, ECC-AES-Huffman combination consumed the least CPU time, followed by ECC-AES-NoCompression, and ECC-AES-RLE combination. It can be inferred that ECC-AES with RLE combination across all security levels demands a very high CPU time consumption, compared to that of ECC-AES with NoCompression option. The efficiency of the compression algorithm has a significant impact on the total encryption time, especially when combined with computationally expensive encryption methods such as ECC. Huffman coding, which reduces data size more efficiently, saves significant time in AES and ECC-AES scenarios. The inefficiency of RLE when implemented on data with high entropy, combined with the computational overhead of ECC increased CPU time consumption. Hence, ECC-AES integrated with RLE compression was not considered suitable for this study.
Comparison of data from Tables 4 and 5 reveals that ECC-AES with the NoCompression option required significantly more CPU time than the AES variants. As a result, ECC- AES with the NoCompression option was excluded from this study. ECC-AES with Huffman encoding did not demand much higher CPU time compared to other AES variants. Therefore, this study considered ECC-AES with Huffman for situations where security is a higher priority than CPU efficiency.
Security levels | Algorithm combination | CPU time in milliseconds |
---|---|---|
LOW | AES128-Huffman | 1.92 |
LOW | ECC-AES128-Huffman | 9.58 |
MEDIUM | AES192-Huffman | 4.08 |
MEDIUM | ECC-AES192-Huffman | 19.75 |
HIGH | AES256-Huffman | 6.33 |
HIGH | ECC-AES256-Huffman | 29.75 |
AES and ECC-AES with Huffman comparison.
Security levels | Algorithm combination | CPU time in milliseconds |
---|---|---|
LOW | AES128-Huffman | 1.92 |
MEDIUM | AES192-Huffman | 4.08 |
HIGH | AES256-Huffman | 6.33 |
LOW | ECC-AES128-Huffman | 9.58 |
MEDIUM | ECC-AES192-Huffman | 19.75 |
HIGH | ECC-AES256-Huffman | 29.75 |
Comparison across security levels.
Table 6 shows that the AES-Huffman combination consumed lower CPU time compared to the ECC-AES-Huffman combination across all security levels. AES-Huffman was observed as the most efficient compression–encryption algorithm combination in terms of CPU time consumption across all security levels. However, the ECC-AES-Huffman combination was preferable when security is prioritized over CPU time.
Table 7 indicates that among the AES variants, AES128-Huffman consumed the least CPU time at 1.92 ms, followed by AES192-Huffman at 4.08 ms, and AES256-Huffman at 6.33 ms. Similarly, for ECC-AES variants depicted in Table 7, ECC-AES128-Huffman consumed the least CPU time at 9.58 ms, followed by ECC-AES192-Huffman at 19.75 ms, and ECC-AES256-Huffman at 29.75 ms. AES and ECC-AES integrated with Huffman consumed the least CPU time at the LOW security level. This study confirms that as the security level increases, the CPU time consumption increases for AES and ECC-AES algorithm combinations.
The original file size and the compressed file size obtained for each compression algorithm was recorded and were used to determine the compression ratio using the following equation.
File name | Original file size in KB | Compression ratio based on Huffman | Compression ratio based on RLE |
---|---|---|---|
alice29-149KB | 149 | 2.8 | 1 |
bib-109KB | 109 | 3.16 | 1 |
book2-597KB | 597 | 2.96 | 1 |
news-369KB | 369 | 2.6 | 1 |
pi-977KB | 977 | 2.13 | 1 |
plrabn12-471KB | 471 | 2.47 | 1 |
Icet10_2-834KB | 834 | 2.96 | 1 |
book1-751KB | 751 | 2.45 | 1 |
news_2-737KB | 737 | 2.61 | 1 |
bib_6-652KB | 652 | 3.3 | 1 |
asyoulik_2-245KB | 245 | 2.59 | 1 |
asyoulik-123KB | 123 | 2.56 | 1 |
Compression ratio based on Huffman and RLE.
Figure 8 depicts the scatter plot of file size vs compression ratio based on the compression algorithms, Huffman encoding and RLE.
File size vs compression ratio.
It was observed that the compression ratio using RLE was 1 for all file sizes, while the compression ratio using Huffman was greater than 1. This indicates that Huffman compression algorithm achieved greater compression efficiency, as evidenced by its higher compression ratio compared to RLE algorithm.
In this study, compression levels were allocated as: 0 for No compression, 1 for lower compression, and 2 for higher compression. Huffman was assigned a compression level of 2, RLE was given a compression level of 1
This study identified the apt algorithm combinations in the mobile cloud context to address the security and energy consumption trade-off. Huffman with AES was observed as the most efficient algorithm combination in terms of CPU execution time consumption. Huffman with ECC-AES was identified as suitable for situations where security is a higher priority than CPU efficiency. It was observed that ECC-AES integrated with RLE compression was not suitable for this study.
Optimized CPU execution time models were created for each algorithm combination. Additionally, the results of this study can be used to define various levels of compression, security, and energy consumption based on the algorithm combinations. This study also paves the way to design a user-initiated costing option using compression, security, and energy consumption levels.
Various additional features, such as the implementation on mobile devices and a large text file category, are under development and are explored as future enhancements to extend the capabilities of the MCC data processing context. An experiment was conducted to validate the use of CPU execution time as a proxy for energy consumption calculation. The initial results did not align with the expected results and thus require further investigation. Therefore, this article does not contain the validation findings. A more detailed examination will be conducted as a future enhancement to ensure the accuracy of the findings.
Thomas, Ambili: Conceptualization, Formal analysis, Investigation, Methodology, Software, Visualization, Writing - original draft; Mapoka, Trust Tshepo: Supervision, Writing - review & editing; Lakshmi Narasimhan, V.: Conceptualization, Writing - review & editing; Thuma, Edwin: Supervision, Writing - review & editing
This research did not receive external funding from any agencies
Not applicable.
Source data is not available for this article.
The authors declare no conflict of interest.
Written by
Article Type: Research Paper
Date of acceptance: May 2025
Date of publication: June 2025
DOI: 10.5772/acrt.20250024
Copyright: The Author(s), Licensee IntechOpen, License: CC BY 4.0
© The Author(s) 2025. Licensee IntechOpen. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted reuse, distribution, and reproduction in any medium, provided the original work is properly cited.
Impact of this article
112
Downloads
118
Views
2
Altmetric Score
Join us today!
Submit your Article