HELO Cryptography: A Lightweight Cryptographic System for Enhancing IoT Security in P2P Data Transmission
Tahsin Ahmed *∗a , Arjita Saha a , Arian Nuhan a , Nafim Ahmed Bin Mohammad Noor a , Md Faisal Ahmed a , and Muhammad Iqbal Hossain a
arXiv:2605.03948v1 [cs.CR] 5 May 2026
a
Computer Science & Engineering, BRAC University, Bangladesh
May 6, 2026
Abstract The recent surge in security concerns for IoT devices highlights the increasing threat of cryptographic vulnerabilities. These weaknesses can lead to unauthorized access, data breaches, and manipulation of device functions, compromising the privacy and security of both the devices and their users. Given the limited computational power of IoT devices, especially when handling large amounts of data, encrypting and transmitting data over insecure networks poses significant challenges. This situation not only heightens security risks and prolongs runtime, but also degrades performance and consumes more resources. To address these issues, a novel cryptographic system named HELO (Hybrid Encryption Lightweight Optimization) is proposed. It is hybridized and gives solid security against cryptographic cyberattacks. However, the research objective is to enhance the security level of IoT devices without decreasing their performance. This system is ideal for resource-constrained gadgets due to its lightweight mechanism. Finally, it offers top-level cryptographic security for IoT gadgets by guaranteeing confidentiality, integrity, and availability while doing P2P data transmission. Keywords Cybersecurity, IoT Security, Cryptography, Lightweight, P2P Data Transmission.
1
Introduction
1.1
Overview
The proliferation of IoT devices in different domains has promoted communication while at the same time raising challenges regarding data privacy and protection. IoT can be described as a network of physical objects embedded with sensors, software, and technologies for connectivity with the Internet to independently collect, share, and act on data, thus forming the basis of various automated systems. Examples of such devices include smartphones, wearable health monitors, smart home appliances, and industrial machinery. Thus, as IoT device integrations become more and more pervasive in day-to-day life, their security will be an important issue for preventing threats not only against things but also against the sensitive data that these devices will generate. As a result, cryptography is one of the very important factors in IoT systems for ensuring the confidentiality, integrity, and authenticity of data. However, these IoT devices are very vulnerable to cryptographic attacks due to their limited resources and difficulties in performing heavy computational tasks. So, lightweight cryptography therefore needs to be used as a countermeasure for these specific security challenges with minimum memory and computational overhead, as identified in [1]. IoT nodes usually operate under highly constrained resources, such as low processing power and limited memory, which further makes them vulnerable to various security threats. Common vulnerabilities include exposure to personal information, data theft, compromised credentials, misconfigurations, broken access control, or even irreparable damage to reputation. Cryptographic failure can also cause heavy lawsuits. To address these challenges, robust cryptographic solutions tailored for IoT environments are essential, particularly in critical sectors such as healthcare, smart cities, industrial automation, and FinTech. Lightweight cryptography opens up prospective options in the areas of reduced computational power and energy consumption, lessened heat generation, and cost efficiency. It enables ∗
Corresponding author: Tahsin Ahmed , Email: [email protected], URL: www.tahsinahmed.com
P REPRINT
HELO Cryptography
data protection against unauthorized access, integrity, and confidentiality for even resource-constrained IoT devices. Lightweight cryptography becomes an essential tool for balancing security with performance and power efficiency when securing IoT systems while attempting to maintain operational efficiency across various applications. 1.2
Problem Statement
Cryptographic algorithms typically demand high processing power to ensure security. While they perform well in resource-rich environments, they face significant challenges in resource-constrained settings like IoT. The key challenges include: • Decreased Security: Traditional algorithms require extensive computational power but do not offer sufficient security in IoT environments, making systems vulnerable to unauthorized access. • Energy Inefficiency: Traditional cryptographic algorithms are energy-intensive, which is a significant drawback for IoT devices reliant on battery life. The high computational and memory demands lead to rapid battery depletion and overheating, which can be catastrophic in certain IoT apps. • Compatibility Issues: Many cryptographic models are incompatible with IoT devices due to their strict hardware and software requirements. They are not easily adaptable to the diverse needs of IoT systems, limiting their usability. • Resource Strain: IoT devices often have limited computational power and memory, making them unsuitable for traditional cryptographic algorithms that require significant resources. This strain on resources reduces the overall efficiency and functionality of IoT devices. • Degraded Performance: Traditional algorithms are complex, leading to slower processing and higher latency. This is especially problematic for IoT devices that require real-time processing. • Cost Intensiveness: The high hardware and resource requirements of traditional algorithms increase the cost of IoT device operation, making them impractical for widespread deployment. • Key Management: Managing cryptographic keys in large-scale IoT environments is a complex and critical task. If keys are compromised, the system becomes vulnerable to data breaches. These challenges emphasize the need for lightweight, efficient cryptographic solutions tailored to the unique requirements of IoT devices. 1.3
Research Objectives
The research aim is to develop a highly secure cryptographic system for IoT users, which includes • Faster and Efficient Processing: Ensuring optimal and faster performance of resource-constrained IoT devices. Also, ensuring the minimization of latency while focusing on efficient P2P data transmission for IoT devices. • Platform Independence: Prioritizing hardware-independent cryptography to get rid of security vulnerabilities like cache-timing attacks, which is a major issue on AES. As a result, it eliminates expensive costs, which is an advantage in large-scale deployments. • Key Size Reduction: Reducing the key size for encryption while maintaining security, addressing the limitations of algorithms like RSA. • Lightweight: Building lightweight cryptography increases efficiency in resource-constrained devices that consume lower power, use minimal CPU and memory. • Enhaching Security: Security is the major concern here. The primary objective is to enhance data security and privacy from multiple attacks without ignoring performance.
2
Thesis Organization
The rest of the thesis is organized as follows: Chapter 3 presents a literature review in which related works are discussed. Chapter 4 details the methodology and implementation of our proposed cryptographic algorithm. Chapter 5 is about the dataset that we used in our research. Chapter 6 shows the results and analysis of the experiment. Finally, Chapter 7 concludes the work, and Chapter 8 suggests a path for future research. 2
P REPRINT
HELO Cryptography
3
Literature Review
3.1
Related Work
This paper discusses various lightweight cryptography techniques to secure IoT. It starts with a brief introduction to the layers of IoT architecture, which consists of application, communication, and physical layers. They are compared in terms of computational speed, storage, safety, and many other factors. The author has also mentioned the challenges of acquiring security in different layers of IoT [2]. This study compares and contrasts three algorithms: AES, SPECK, and SIMON. The study uses the Cooja simulator on the Contiki operating system to test encryption methods in an IoT setting. The outcomes showed the pros and cons of each program in terms of how long it takes to run, how much power it uses, how much memory it takes up, and how fast it works [3]. The study divides lightweight cryptography into three groups: stream ciphers, block ciphers, and hash functions. It looks at how well cryptography algorithms work, their security, cost-effectiveness, and memory usage, as well as things like throughput, latency, memory usage, resistance to known attacks, expected time to break and die, and power consumption. Some important things to remember are how important lightweight cryptography is for protecting IoT devices with limited resources, how different algorithms work, how safe they are, how much they cost, and how the field needs more standardization. Also, energy efficiency is a crucial part of it [4]. There is a full list of cryptographic algorithms that can be compared, such as Trivium, Elliptic Curve Cryptography (ECC), Tiny Encryption Algorithm (TEA), Proxy Re-Encryption, Attribute-Based Encryption (ABE), SM2 Cryptographic Schemes, 6LoWPAN, and IPSec. ECC and TEA are good choices for resource-constrained devices because of their small key sizes. However, Trivium is vulnerable to cubic attacks and necessitates a large hardware resource investment. ECC and TEA are frequently selected because of their effectiveness in resource-limited environments and authenticity [5], [6]. Developing ECC for data key protection improves data integrity, and makes security stronger. The proposed system architecture uses ECC combined with an IoT platform for enhancing security. It won’t affect the size, performance, or energy consumption of devices. Also, the algorithm combines ECC with the Diffie-Hellman key exchange technique and AES for lightweight security. This algorithm uses key sizes of 256-bit and 512-bit and has implemented ECC curves that demonstrate how IoT Edge enhances security and increases processing capability for safe data transfer [7]. Furthermore, ChaCha20, Poly1305, and MAC perform appropriately on various software platforms. The Authenticated Encryption with Associated Data (AEAD) scheme is created by combining the Poly1305 authenticator with the ChaCha20 stream cipher according to the RFC7539. The ChaCha20 stream cipher, Poly1305-ChaCha20 authenticator, and ChaCha20-Poly1305 AEAD scheme for ARM Cortex-M4 processors are all presented in the paper as compact, constant, and quick implementations. It handles 64-byte blocks, uses a secret key and nonce for encryption, has fast software performance, and ensures data encryption, integrity, and authenticity. Techniques for double round, quarter round, and Poly1305 multiplication optimization are discussed. ChaCha20 is optimized by switching the quarter-round order and reducing memory operations [8]. This paper presents a survey regarding lightweight cryptographic solutions for IOT, including a comparison between hardware and the most recent software. In symmetric key cryptography, this survey includes security measures between different types of block ciphers such as AES, 3DES, Blowfish, Twofish, PRESENT, KATAN, TEA, Humming Bird, SIMON, and RECTANGLE. Based on research, AES is considered a good security solution for restricted IoT devices. However, this paper also claims that AES for IOT can attract some hardware security attacks, such as side-channel attacks and correlation analysis attacks by using a false key and Wave Dynamic Differential Logic-based XOR gates. Asymmetric key cryptography includes RSA, DSA, and ECC. A comparative study shows that ECDH performs better than other algorithms in terms of power and area [9]. This paper proposes a hybrid encryption algorithm, HAR (Hybrid AES Rail Fence), for secure data communication among IoT devices. This algorithm ensures confidentiality; the key generation process is carried out by the AES standard implementation, but does not show the way of key management approach. An attack called a biclique attack is faster than brute force by a factor of about four. Not only key-recovery attacks, but also side-channel attacks, padding-oracle attacks, and power-consumption analyses can be performed on AES. This shows that AES has many vulnerabilities. Ciphertexts produced by transposition ciphers are relatively easy to recognize because the frequency 3
P REPRINT
HELO Cryptography
distribution of all ciphertext alphabet letters is the same as in plain messages written in the same language. This is why the Rail Fence Cipher can be broken quite easily by using brute force attacks due to the small number of possible keys. Lastly, compared with the AES algorithm, this hybrid approach resulted in a high avalanche effect, and provides more security in terms of complexity in finding data using diffusion techniques, but not in all methods to ensure strong security [10]. Securing data could have been better in IoT. This is why the Blowfish algorithm has been proposed to enhance the security of IoT devices. It is modified where it depends on the rounds and substitution boxes, which speeds up the process of encryption and decryption. Its use of a 64-bit block size makes it vulnerable to birthday attacks, particularly in contexts like HTTPS. The GnuPG project recommends that Blowfish not be used to encrypt files larger than 4 GB due to its small block size [11]. This paper proposes a hybrid algorithm combined with RSA and Diffie-Hellman. Diffie-Hellman acts as a secure key exchange protocol, and RSA accounts for securing the message. It shows analysis and comparisons between the traditional RSA algorithm and the proposed hybrid algorithm with some parameters like key size, message size, encryption, and decryption time. The encryption and decryption time of the hybrid algorithm is increased compared to the traditional RSA [12].
4
Methodology
4.1
Description of the Model
This cryptographic model consists of seven mechanisms: asymmetric cryptography, symmetric cryptography, digital signature, data partitioning, tokenization, message authentication, and multithreading. These mechanisms enhance the security level even strongly than today’s adopted mechanisms for IoT devices. Now, let’s see how this cryptographic model works and securely handles data transmission. 4.1.1
Chunk Size Initialization
Data can sometimes be memory and CPU-intensive for a simple IoT device while doing cryptographic tasks. So, chunking data into several segments is a solution to this issue. This process allows partial decryption and data recovery without requiring access to the entire encrypted file. Also, it makes the model resilient to data corruption, where only the affected chunk will be lost rather than the entire dataset. This approach minimizes buffer overflow risks and reduces CPU overhead, resulting in faster encryption cycles and lower power consumption. Additionally, chunk-based processing improves transmission latency and fault tolerance, as corrupted or lost packets can be retransmitted independently without re-encrypting the entire dataset. However, a developer can give the size of each chunk (Cs ) according to their perspective. There is no block mode; instead, chunking data according to user preference gives freedom in development. So, this will increase efficiency, performance, and scalability in the constrained architecture of real-world IoT systems. Moreover, it becomes very beneficial for integrity checking and error handling (Algorithm 1). Algorithm 1 Chunk Size Initialization 1. Function Chunk_Size() 2. Input: Cs ← "Enter chunk size" 3. Return Cs as integer 4. End Function 4.1.2
Key Generation
The sender and the receiver generate a private and public key pair using the SECP25R1 elliptic curve. The formula of ECC is y 2 = x3 + ax + b where SECP25R1 has a 256-bit point (x, y), the private key is a 256-bit scalar value a, and it gives a public key point of a.G. Furthermore, G is a base point of the curve, and it is predefined. It is chosen carefully so that the curve has a large cyclic subgroup with a high-order prime number. Here, the sender generates the public key (Qs ) by multiplying its private key (Ps ) and G. In addition, the receiver also generates the public key (Qr ) by multiplying its private key (Pr ) and G (Algorithm 2). However, ECDH (Elliptic-Curve-Diffie-Hellman) is utilized in this model, allowing two parties to securely generate a shared secret key (Sk ) using their respective public and private keys. For verification on the sender’s end, it 4
P REPRINT
HELO Cryptography
takes three arguments: Ps , Qr , and salt. Likewise, the receiver end takes three arguments: Pr , Qs , and salt. This raw shared secret key is processed using the HMAC-based Key Derivation Function with SHA3-256 as the hash algorithm (H256 ) and generates a derived key (Kd ). Also, the length (n) for the key is 32 bytes or 256 bits. Now, both parties will exchange the hashed keys and check whether they match or not. The procedure will halt its execution if the keys are unmatched (Figure 1) (Algorithm 3). Algorithm 2 Generate Key Pair 1. Function Generate_Keypair() 2. privateKey ← generate_private_key(using SECP256R1) 3. publicKey ← generate_public_key(privateKey) 4. Return (privateKey, publicKey) 5. End Function
Algorithm 3 Key Exchange 1. Function Key_Exchange(privateKey, publicKey, salt) 2. Sk ← calculate_shared_secret(privateKey, publicKey) 3. Kd ← derive_key(Sk , H256 , salt, n, info = “handshake data”) 4. Return Kd 5. End Function
IoT
IoT
IoT Device (s)
IoT Device (r)
Private Key (Ps)
Private Key (Pr )
Secret Key Establishment with ECDH Public Key: Q s = Ps x G
Public Key: Q r = Pr x G Qr
Qs
Shared Key: S k = Ps x Q r
Shared Key: S k = Pr x Q s
Derived Secret Key: K d = HKDF(S k , H256 , n, salt)
Derived Secret Key: K d = HKDF(S k , H256 , n, salt)
Matched?
Yes; Execute
No; Key altered
Figure 1: Workflow of Key Exchange
5
P REPRINT
HELO Cryptography
4.1.3
Tokenization
Tokenization is applied when sensitive data needs to be replaced with unique identification symbols. Nonce (Tn ) is used in HELO as a token that will be generated once at a time, and the token will become invalid after that. As a result, its persistence becomes stateless and makes it unique per session. Here, the length (n) of nonce is 16 bytes or 128 bits (Algorithm 4). Algorithm 4 Tokenization 1. Function Generate_Random_Token() 2. Tn ← generate_random_bytes(n) 3. Return Tn 4. End Function 4.1.4
Message Authentication
MAC (Message Authentication Code) is a security code that is employed to provide authentication of the origin of the data. Here, HELO uses Poly1305 algorithm (P1305 ) as a MAC. The Generate_T ag() function takes the sender’s derived shared secret key (Kd ), chunked ciphertext (Ecd ) as inputs, and produces a 16-byte computed tag. The key size for the P1305 is 256 bits. In verification, the provided tag will be verified by the V erif y_T ag() function when the message reaches the receiver end. It will take three arguments: the receiver’s derived shared secret key (Kd ), the chunked ciphertext (Ecd ), and the sender’s provided tag (Mp ). If the receiver’s computed tag (Mr ) does not match with the sender’s provided tag (Mp ), it will generate an error instantly and exit the program (Figure 2) (Algorithm 5). Algorithm 5 Message Authentication 1. Function Generate_Tag(Kd , Ecd ) 2. Mp ← compute_mac(Sk , Ecd , P1305 ) 3. Return Mp 4. End Function 5. Function Verify_Tag(Kd , Ecd , Mp ) 6. Mr ← compute_mac(Kd , Ecd , P1305 ) 7. Return Mr == Mp 8. End Function
Sender Chunked Ciphertext (Ecd )
Network
Receiver Chunked Ciphertext (Ecd )
Chunked Ciphertext (Ecd ) Derived Secret Key (K d )
Ploy1305 Algorithm
Ploy1305 Algorithm
Derived Secret Key (K d )
Sender's Computed Tag (Mp ) Sender's Computed Tag (Mp )
Receiver's Computed Tag (M r )
Sender's Computed Tag (Mp ) == True
Message is authentic
Figure 2: Workflow of Message Authentication
6
False
Message is altered
P REPRINT
HELO Cryptography
4.1.5
Digital Signature
HELO uses ECDSA (Elliptic Curve Digital Signature Algorithm) to ensure the identity of an authentic sender. It digitally signs the plaintext before the encryption and sends it to its receiver through the network. Firstly, the Sign_Data() function takes the sender’s private key (Ps ) and plaintext file (Dd ) as input. Now, a digest is generated by hashing the plaintext file using the SHA3-256 hash algorithm (Hd ). It then generates a signature (Sdigi ) by signing the data using the ECDSA algorithm by taking three parameters, which are the sender’s public key (Qs ), plaintext file, and generated digest (Hd ). In verification, the V erif y_Signature() function validates the integrity and authenticity of the data by verifying the signature against the provided public key (Qs ) and plaintext file using the same ECDSA algorithm. In addition, a digest will be found when the receiver decrypts the digital signature using the sender’s public key. Also, the receiver will again hash the plaintext file, generate a digest using the same SHA3-256 hash algorithm the sender used, and compare the result with the digest he received. It returns true if the verification process becomes successful. Otherwise, InvalidSignature will catch an exception and return false. It will then stop executing forward as it indicates possible tampering and forgery (Figure 3) (Algorithm 6). Algorithm 6 Digital Signature 1. Function Sign_Data(Ps , Dd ) 2. Sdigi ← Sign(Ps , Dd , Hd ) 3. Return Sdigi 4. End Function 5. Function Verify_Signature(Qs , Dd , Sdigi ) 6. Try 7. Validate_Signature(Sdigi , Qs , Dd , Hd ) 8. Return true 9. Catch InvalidSignature 10. Print “Alert: Signature has been tampered.” 11. terminate_execution() 12. End Try 13. End Function
Signing
Verifying aWe25dq 1Aop67...
Plaintext File (D d )
Sender's Private Key (P s )
Plaintext File (D d )
Hash Function SHA-256
Digest (Hd )
Yes
Signature is valid
Matched? Hash Function SHA-256
ECDSA Digital Signature (Sdigi)
Signature is invalid
Digitally Signed
No
aWe25dq 1Aop67...
aWe25dq 1Aop67... Sender's Public Key (Q s )
Digest (Hd )
Figure 3: Workflow of Digital Signature
7
Digest (Hd )
P REPRINT
HELO Cryptography
4.1.6
Encryption
Encryption is responsible for transforming information into an unreadable ciphertext. Firstly, it starts with determining the chunk size using Chunk_Size() function (Algorithm 1), although this variable is not directly used in the encryption, but rather in a chunk-based operation. The plaintext file (Dd ) is converted into a binary mode before the XOR operation. Secondly, ECDSA (Sdigi ) is applied in the plaintext file using the sender’s private key (Ps ), ensuring the authenticity and integrity of the plaintext data. For later verification, it is stored in a separate file with a .sig extension. Afterward, the binary mode of the plaintext file is chunked (Cd ). Furthermore, a nonce (Tn ) is generated using Generate_Random_T oken() function (Algorithm 4) to initialize the ChaCha20 cipher algorithm (Ci ). Here, the cipher is created with a nonce and the sender’s derived secret key (Kd ). The chunked plaintext is then encrypted using the cipher’s encryptor (Encc ) and generates ciphertext. This ciphertext (Ecd ) is now finally finalized and stored. Furthermore, Generate_T ag() function (Algorithm 5) generates a MAC using Poly1305 (P1305 ), which is pipelined with the XOR operation of the ChaCha20 algorithm (Cha20 ) to ensure the integrity of each of the chunked ciphertexts. This encrypted data, along with the sender’s computed tag (Mp ), forms the payload and is transmitted through the network. The encrypted file contains nonce, tag, and ciphertext. However, multithreading plays a vital role in handling the transmission of data more efficiently during encryption (Figure 4) (Algorithm 7). ChaCha20 is a stream cipher that encrypts data byte-by-byte without adding any padding characters, which means the size of the chunked ciphertext (M ) is exactly as same as the size of the chunked plaintext. So, the total size of the encrypted file (Ecd ) is calculated as follow: Total size = size of Tn + size of Ecd + size of Mp = 16 + M + 16 = M + 32 bytes
Algorithm 7 Encrypt Chunked File 1. Function Encrypt_Chunked_File(Dd , Ed , Kd , Ps ) 2. Cd ← Chunk_Size() 3. Open Dd for Reading 4. Sdigi ← Sign_Data(Ps , Dd ) 5. Tn ← Generate_Random_Token() 6. Ci ← initialize_cipher(Cha20 , Kd , Tn ) 7. Encc ← create_encryptor(Ci ) 8. While data_chunk ← read_chunk(Dd , Cd ) do 9. Ecd ← encryptor.encrypt(data_chunk) 10. Fe ← finalize_encryption(Ed , Encc ) 11. Mp ← Generate_Tag(Kd , Fe ) 12. End While 13. Open Ed for Writing 14. Write Ecd to Ed 15. Write Mp to Ed 16. Write Tn to Ed 17. Close Ed 18. Close Dd 19. Open Ed for Writing 20. Write Sdigi to (Ed + .sig) 21. Close Ed 22. End Function 8
P REPRINT
HELO Cryptography
Encryption & Decryption
Plaintext (Dd )
Derived Secret Key (Kd )
Network
Nonce (Tn )
Multi Threading ChaCha20
Encryption: Input Decryption: Output
Multi Threading Digital Signature (Sdigi )
Chunked Data (Cd )
XOR
Encryption: Output Decryption: Input
Pipelined Poly1305
Ciphertext (E d )
Tag (M p )
(P1305 )
Figure 4: Workflow of Encryption and Decryption
4.1.7
Threading
This model utilizes multithreading for improved resource efficiency, as threads are lighter than processes and maximize CPU usage. By running tasks concurrently, threading ensures faster operations for battery-operated IoT devices. Here, multithreading enhances encryption and decryption efficiently, where a single process is divided into multiple threads. Firstly, T hreaded_F ile_Encryption function takes four parameters: a path of the source file (Spath ), a path where the encrypted file will be stored (Epath ), a derived secret key, and the sender’s private key. Secondly, a thread pool executor (Tpool ) has to be initialized. Thirdly, it takes an empty list (Lo ) for appending the objects to keep track of all running tasks for encryption. Afterward, it provides encryption for all files in a specified folder by iterating through them and sending each file to a Tpool for concurrent processing. It creates the total path for the plaintext file and its corresponding encrypted file, adding a .enc extension to point out the encryption. Each file is handled at the point utilizing Encrypt_Chunked_F ile() function (Algorithm 7). It performs encryption using Dd , Ed , sender’s derived secret key (Kd ) and his private key (Ps ). Finally, Tpool .wait_f or_all_threads() function guarantees that all encryption tasks are complete before the function’s exit (Algorithm 8). Likewise, the T hreaded_F ile_Decryption() function is responsible for decrypting all files from the encrypted folder concurrently. Firstly, it takes four arguments: the path of the encrypted file (Epath ), a path where the decrypted file will be stored (Dpath ), receiver’s derived secret key (Kd ), and sender’s public key (Ps ). It also checks for files ending with the .enc extension, which helps the program to remove it and reconstruct the decrypted file. Secondly, the thread pool executor becomes initialized for multithreading, and the decrypted file is then submitted to it. Afterward, T hreaded_F ile_Decryption() function takes an empty list (Lo ) for appending the objects in terms of keeping track of all running tasks for decryption, which is handled by the Decrypt_Chunked_f ile function 9
P REPRINT
HELO Cryptography
(Algorithm 10). Finally, again the function Tpool .wait_f or_all_threads() guarantees that all decryption tasks are complete before the exit of the function (Figure 5) (Algorithm 9).
Main Thread
ThreadPoolExecutor
Thread-1
Thread-2
Thread-N
Encryption Function
Decryption Function
Encryption Process Create ThreadPoolExecutor loop
[For each file in file_path]
Submit encryption task execute Encrypt_Chunked_File( ) Encrypt file chunk Return encrypted data execute Encrypt_Chunked_File( ) Encrypt file chunk Return encrypted data .......... (N number of Threads) execute Encrypt_Chunked_File( ) Encrypt file chunk Return encrypted data Wait for all encryption tasks to complete Decryption Process Create ThreadPoolExecutor loop
[For each encrypted file]
Submit decryption task execute Decrypt_Chunked_File( ) Decrypt file chunk Return decrypted data execute Decrypt_Chunked_File( ) Decrypt file chunk Return decrypted data .......... (N number of Threads) execute Decrypt_Chunked_File( ) Decrypt file chunk Return decrypted data Wait for all decryption tasks to complete
Main Thread
ThreadPoolExecutor
Thread-1
Thread-2
Figure 5: Workflow of Multithreading
10
Thread-N
Encryption Function
Decryption Function
P REPRINT
HELO Cryptography
Algorithm 8 Threading for Encryption 1. Function Threaded_File_Encryption(Spath , Epath , Kd , Ps ) 2. Initialize Tpool for multithreading 3. Lo ← [ ] 4. For file_name in file_path do 5. Dd ← concat Spath and file_name 6. Ed ← concat Epath and file_name + .enc 7. Append(Lo , Tpool .create_thread(call Encrypt_Chunked_File(Dd , Ed , Kd , Ps ))) 8. End For 9. Tpool .wait_for_all_threads() 10. End Function Algorithm 9 Threading for Decryption 1. Function Threaded_File_Decryption(Epath , Dpath , Kd , Qs ) 2. Initialize Tpool for multithreading 3. Lo ← [ ] 4. For file_name in Epath do 5. Ed ← concat Epath and file_name 6. Dd ← concat Dpath and remove .enc from file_name 7. Append(Lo , Tpool .create_thread(call Decrypt_Chunked_File(Ed , Dd , Kd , Qs ))) 8. End For 9. Tpool .wait_for_all_threads() 10. End Function Algorithm 10 Decrypt Chunked File 1. Function Decrypt_Chunked_File(Ed , Dd , Kd , Qs ) 2. Open Ed for Reading 3. Tn ← extract_first_bytes(Ed , 16) 4. Mr ← extract_last_bytes(Ed , 16) 5. Ecd ← extract_remaining_bytes(excluding = Tn and Mr ) 6. If Verify_Tag(Kd , Ecd , Mr ) then 7. cipher ← initialize_cipher(Ci , Kd , Tn ) 8. decryptor ← create_decryptor(Ecd ) 9. Open Dd for Writing 10. While Cd ← decryptor.decrypt(cipher) 11. Write Cd to Dd 12. finalize_and_write(Dd , decryptor) 13. Verify_Signature(Qs , Dd , Ed + .sig) 14. End While 15. Close Dd 16. Else 17. Print “Alert: Tags are mismatch.” 18. terminate_execution() 19. End If 20. Close Ed 21. End Function 11
P REPRINT
HELO Cryptography
4.1.8
Decryption
Decryption is the reverse process of encryption, which converts the encrypted data back to its original form and is also human-readable. Likewise, in our proposed cryptographic system, the decryption phase starts by opening the encrypted file (Ed ) in binary mode and reading the first 16 bytes as nonce (Tn ). The last 16 bytes of the data are extracted as the sender’s provided tag (Mp ). The rest of the data consists of chunked ciphertext (Ecd ). After successfully authenticating the ciphertext with the receiver’s computed tag (Mr ), the ChaCha20 algorithm decrypts the ciphertext file using the nonce, and the receiver’s derived secret key (Kd ) which must be matched with the sender’s derived secret key (Kd ). Finally, decryption proceeds using the ChaCha20 algorithm (Ci ) unless the nonce expires, allowing the receiver to successfully receive the original file. After decryption, the V erif y_Signature() function verifies the sender’s genuineness by checking his digital signature using the ECDSA algorithm. The signature is stored in an isolated record with a .sig extension (Ed + .sig). It is read and validated against plaintext utilizing the sender’s public key (Qs ). If both tag and signature verification pass, decrypted plaintext (Cd ) is been written to a new file (Dd ), ensuring that only an authorized user can access the original content (Figure 4) (Algorithm 10). 4.2
Implementation
Main Program
User
Key Generation
Key Exchange
File Processing
Encryption
Decryption
Digital Signature & MAC
Multi-threading
Run Program Initialize CHUNK_SIZE Generate Key Pairs Return Public & Private Keys Perform Key Exchange Return Shared Keys Process Folder for Encryption Multi-thread Encryption Encrypt Files Chunked Generate Signature & MAC Return Signature & MAC Save Encrypted Files Process Folder for Decryption Multi-thread Decryption Decrypt Files Chunked Verify Signature & MAC Signature Verification Successful Save Decrypted Files Display Success or Error Messages
User
Main Program
Key Generation
Key Exchange
File Processing
Encryption
Decryption
Digital Signature & MAC
Multi-threading
Figure 6: UML Sequence Diagram of Implementing HELO Cryptography 4.2.1
Experimental Setup
All experimental evaluations of the proposed lightweight cryptographic scheme were performed on a personal desktop computer instead of an actual IoT device. The system configuration includes an Intel(R) Core(TM) i5-9600K processor, which has 6 cores and threads, 9 MB cache, and a base frequency of 3.70 GHz. Here, the base frequency is the operating point where the TDP (Thermal Design Power) is defined. Moreover, the TDP value is 95 Watts, referring to the maximum amount of heat a CPU is expected to generate under full load. Also, 16 GB of DDR4-2666 RAM is used, 12
P REPRINT
HELO Cryptography
and the experiment is performed on the Microsoft Windows 11 Pro operating system. Additionally, several Python libraries are used to analyze performance, the avalanche effect, and energy consumption. Also, the Flask framework is employed for the web interface. 4.2.2
Limitations
The mentioned configuration introduces certain limitations. Specifically, the absence of an IoT device, such as a resource-constrained Raspberry Pi Zero, ESP32, or Arduino Nano 33, restricts the generalization of the results to embedded environments. Furthermore, the estimated results were derived from energy consumption rather than hardware-level power measurements. This experiment was conducted on a single machine. Consequently, factors such as scalability, distributed processing, and computational overhead analysis became increasingly difficult in large-scale IoT deployments. As a result, we had to analyze the information hypothetically and quantitatively. 4.2.3
Software Design
A UML diagram is created for the HELO cryptography software application. It is designed to run on a web server and be accessed by users through a web browser. Additionally, it can be described as a web application (Figure 6). Furthermore, the system is designed to facilitate the encryption and decryption of the files we have created. Additionally, the project’s source code has been uploaded to GitHub and is open-source. As a result, this will create opportunities for developers and researchers to work on it. Source Code: https://github.com/tahsinnahmed/HELO-Cryptography.git Web Application: https://helocrypto.pythonanywhere.com
5
Dataset Description
In this section, the experiments were conducted using datasets obtained from Kaggle, which were chosen because they capture diverse data patterns that closely resemble those found in real-world IoT environments. Although the evaluation was performed in a simulated desktop environment, the dataset effectively reflects an IoT-specific network of instructions and resource constraints. The incorporation of HELO Cryptography in the experimental framework further aligns with the computational and energy-efficient characteristics expected in practical IoT deployments. This is done to ensure that the results remain representative and applicable. As a result, the findings provide a valid indication of how the proposed cryptographic system approach would perform in real IoT systems under lightweight cryptographic conditions. Table 1: Dataset Description Size
Dataset Type
File Name
Source
Key Features
TXT
1k Random 3D Shapes TACO Dataset YOLO Format TF 2.16 Requirements English to French Translations Thai Sentiment Analysis Toolkit Hip-Hop Encounters Data Science
15 Bytes 118 Bytes 171 Bytes 1 Kilobyte 10 Kilobytes 22 Kilobytes
[13] [14] [15] [16] [17] [18]
Single line, seeding value README file Python package list Terms conditions Thai Text Sentiment Analysis Song lyrics
CSV
Netflix OTT Revenue and Subscribers Credit Score Classification Dataset FIFA 22 Complete Player Dataset Midjourney 2022 - 250k World’s Top 200,000 Scientists Football Data from Transfermarkt
1 Megabyte 6 Megabytes 10 Megabytes 67 Megabytes 84 Megabytes 124 Megabytes
[19] [20] [21] [22] [23] [24]
Banking transactions Financial records Football player profiles Image generation metadata Scientific contributions Football statistics
Images
Apples or Tomatoes Image Classification Soil Types Cat Dog Images Pokemon Image Dataset Pistachio Image Dataset Weather Image Recognition
368 Kilobytes 600 Kilobytes 740 Kilobytes 5 Megabytes 20 Megabytes 40 Megabytes
[25] [26] [27] [28] [29] [30]
Labeled apple images Peat soil images Cat and dog images Pokémon images Pistachio images Weather images
13
P REPRINT
HELO Cryptography
The collection of data contains three types, which are TXT, CSV, and image files (JPG, PNG). These datasets are primarily used for testing encryption and decryption algorithms in multiple formats. The structure of the data is well organized to keep consistency and fairness in check for comparisons. Below is the dataset information that was used (Table 1).
6
Results and Analysis
6.1
Attack Type
When it comes to transmission, people have significant risks from a variety of cyber threats. The purpose is to identify the most common attack types that occur during data exchange and to provide a full picture of how it works and what the consequences are. These attacks show the importance of cybersecurity for the safety and privacy of transmission. • MITM Attack: An attacker can listen in on or change data during the attack by standing between two people talking to each other [31]. • Spoofing: Pretending to be a real person, group, or source to trick people or get unauthorized access [32]. • Supply Chain Attack: To get into target systems or networks, hackers use flaws in third-party providers or services [33]. • Replay Attack: To get unauthorized access or pretend to be a real user, hackers record and playback valid data transfers [34]. • Brute Force Attack: Try-and-fail way for guessing passwords or encryption keys to get in without permission [35]. • Dictionary Attack: Using a list of common words or sentences as passwords or to get into a system or account without permission [35]. • Rainbow Attack: Hashing methods are used to encrypt passwords and make hash tables that can be used to break them [36]. • Eavesdropping: Illegal communication interceptions carried out to obtain data or information [37]. • Tampering: Data, systems, or messages that have been changed without permission [38]. • Forgery: Creating bogus or forged identities, digital signatures, or documents [39]. • Reverse Engineering: Looking closely at an object or system to learn about its parts, how it works, or how it was designed [40]. • Birthday Attack: Cryptographic hash collisions can be used to make two different inputs that have the same hash result [41]. • Preimage Attack: A cryptographic attack in which the attacker looks for input that hashes to a particular value. Preimage attacks are classified into two types: first, which involves finding any input for a given hash, and second, which involves finding an alternative input that matches the hash of a given input [42]. • Cache-Timing Attack: A kind of side-channel assault in which an attacker takes advantage of differences in the amount of time it takes to access data stored in a computer’s cache. Based on how data is accessed and processed, an attacker can determine sensitive information, including cryptographic keys, by analyzing these temporal disparities [43]. 6.2
Attack Analysis
To figure out which security methods can help stop different kinds of cyberattacks, it’s important to look at the pros and cons of each method in the context of the attacks. Here’s how our model cryptography approaches might mitigate various attacks: 6.2.1
Nonce
The term ‘nonce’ stands for ‘number used once’, and generates a random number using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) for each time or transaction that is difficult to detect, predict, and utilize in a short time. Its randomness, uniqueness, and limited validity enhance security, which can prevent replay attacks [44]. 14
P REPRINT
HELO Cryptography
6.2.2
SHA3-256
SHA3-256 uses a sponge structure based on the Keccak algorithm for establishing a 1600-bit state; it logs input blocks using XOR and Keccak-f permutations. The 256-bit hash value is extracted, making the architecture very resistant to collision attacks and difficult for attackers to break, which are also computationally costly and difficult to detect with present technology. This gives SHA3-256 protection against preimage attacks by requiring a distinct input with the same hash and complexity of 2256 . If an attacker knows the original message hash, they can calculate the extended message hash. Extending length Security is provided via SHA3-256. This method protects against differential cryptanalysis by reflecting changes in the hash output and being highly sophisticated. Also, birthday attack utilizes the probability theory birthday paradox to locate 2 messages with the same hash value faster than brute force where 2256 complications make birthday attacks more difficult [45]. 6.2.3
Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm(ECDSA)
ECDH uses elliptic curves to make key sharing safer and allow two parties to agree via a protected channel where each party produces public and private keys and exchanges the public key. Adding those keys creates a shared secret key for secure communication using symmetric encryption. It protects communication by discussing secret keys without giving personal information. Furthermore, ECDSA generates and verifies digital signatures. Create a private-public key pair, sign a message with the private key, and then confirm with the public key, ensuring message integrity, non-repudiation, and authentication [47]. ECDH and ECDSA combo handles many attacks, with ECDH for verification and ECDSA for key sharing for more secure and trustworthy communication. ECDSA (Elliptic Curve Digital Signature Algorithm) uses digital signatures to prevent spoofing, ensuring that only the holder of the private key can sign a message, which is verified by the corresponding public key. By confirming the legitimacy of the signatures, ECDSA may determine whether a key has been compromised or not. Without the private key, it is nearly impossible to forge signatures. It also reduces the risk of MITM (Man-in-the-Middle) attacks by using secure key exchange protocols like ECDH, preventing tampering, eavesdropping, and cryptanalytic attacks by utilizing forward secrecy. To ensure continued security, a compromised private key can be exchanged with a fresh key pair. ECDSA ensures message integrity and authenticity, making brute-force and supply-chain attacks impractical due to the complexity of elliptic curve cryptography [46]. 6.2.4
ChaCha20 with Poly1305
ChaCha20 is a stream of pseudo-random bits that is XORed with the plaintext to create the ciphertext. A shared secret key, counter, and nonce provide a secure pseudorandom key stream for data privacy and integrity. The protected message, data, nonce, and secret key are turned into a MAC, and an authentication tag using POLY1305 MAC certifies integrity and validity. If the computed and received tags match, the message is not altered. Now, using ChaCha20 and Poly1305 together ensures strong encryption and authentication, preventing hacking and interception of communication paths. Also, cryptography protects sensitive data from unauthorized access. It is difficult to reverse-engineer this mixture. It generates unique verification tags for each message, even with identical plaintexts. This prevents known attacks utilizing plaintext. Hackers cannot access encryption keys or sensitive communication data. Moreover, ChaCha20 with Poly1305 guards against specific plaintext attacks by utilizing Poly1305 for message authentication, guaranteeing that attackers cannot change or construct new ciphertexts without the secret key, even if they select plaintexts and access their ciphertexts. Also, as ChaCha20 is built to be resistant to timing attacks, it can defeat cache-timing attacks because of its data-independent and constant-time procedures; the encryption process takes the same amount of time regardless of input data. In addition, Poly1305’s safe authentication and ChaCha20’s strong encryption and security stem from its ability to withstand cryptographic attacks, such as key recovery attacks [8], [48]. 6.3
Performance Analysis
Performance analysis is structured into three key components: CPU Processing Time, RAM Usage, and Runtime Analysis, across three file types. These are TXT, CSV, and image files. This methodology ensures a consistent evaluation of algorithms and validates their capabilities across various file types, providing confidence in their performance. Also, CPU processing time refers to the time the CPU takes to execute instructions from a program. The total time from the start to the completion of program execution is known as the runtime. Moreover, the amount of Random Access Memory consumed by a program during execution is referred to as RAM usage. Here, analyzing the parameters is crucial for cryptographic algorithms, as they impact efficiency and performance. Optimized CPU time leads to faster operations essential for real-time processing, while minimized runtime ensures scalability under high operational volumes. Also, Efficient RAM usage is vital in resource-constrained 15
P REPRINT
HELO Cryptography
environments like IoT devices. Furthermore, consistent operation times and secure memory management can help mitigate side-channel attacks. However, the following algorithms were selected for comparison: HELO, AES, Blowfish, and Fernet, chosen for their effectiveness in resource-constrained settings (Table 2). Table 2: Parameters
Algorithm
Key Size
Block Size
Mode/Chunk
Padding/MAC
Rounds
HELO AES Blowfish Fernet
256 bits 256 bits 256 bits 256 bits
512 bits 128 bits 64 bits 128 bits
Chunked Data CFB CFB CBC
Poly1305 PKCS7 PKCS7 PKCS7
20 14 16 10
The aspect of parameterization in encryption is essential as far as security, efficiency, and adaptation are concerned, particularly in environments like IoT devices and embedded systems, which are quite constrained. A key size plays an important role in defining the cryptographic strength of an algorithm, such that for brute-force attacks to be more resistant, the keys have to be larger [49]. Furthermore, the bigger block size would improve the throughput, but it also affects the memory usage and latency [50]. A particular encryption mode heavily affects the safety of data on the network because different modes, like Cipher Feedback (CFB) and Cipher Block Chaining (CBC) have different approaches to propagating data. They are vulnerable to replay, bit-flipping, and padding oracle [51]. The use of padding schemes, like PKCS7, is in place to fit the data into a block cipher structure and prevent weaknesses related to such poorly structured data [52]. Furthermore, the most crucial parameter of an algorithm related to security strength is the number of encryption rounds. Most of the time, more rounds mean better protection against any differential and linear cryptanalysis; however, performance may significantly deteriorate as the number of rounds increases, especially in real-time and limited resources applications [50]. Message Authentication Code (MAC), such as Poly1305 can also enhance the data integrity and authenticity of the encrypted form, such that any unauthorized modifications can be detected [52]. Also, these parameters determine the trade-offs between security and efficiency, favoring algorithm selection depending on the application’s needs. Comparative performance evaluations have to take into consideration variations not only in comparison tests but also in the test configurations between successive tests. This is because variances in parameter settings can give rise to enormous potential differences in encryption speed, CPU utilization, memory consumption, and overall system efficiency [49] [53]. Lastly, by analyzing these parameters effectively, researchers and engineers can optimize their encryption solutions to achieve the most favorable balance between them and real-world applicability. 6.3.1
CPU Processing Time Analysis
TXT Files: The CPU processing time was analyzed across various file sizes, starting from small text files (15, 118, 171 bytes) to larger files (1, 10, 22 KB). The algorithms compared include HELO, AES, Blowfish, and Fernet. Our proposed model, HELO, consistently took 0.01 seconds for most file sizes, except for 171 bytes and 10 KB, where it recorded 0.03 seconds. Whereas AES showed varied CPU times between 0.02 to 0.05 seconds, while Blowfish had relatively higher processing times, ranging from 0.05 to 0.09 seconds without a clear pattern. Fernet had similarly inconsistent times, varying between 0.02 and 0.06 seconds. HELO averaged the lowest CPU time for TXT files at 0.016 seconds, followed by AES at 0.032 seconds, Fernet at 0.041 seconds, and Blowfish being the slowest with an average of 0.068 seconds (Figure 7). CSV Files: HELO maintained its fast performance, processing small files (1 MB and 6 MB) in 0.01 seconds. The time increased with larger files, reaching 0.39 seconds for a 124 MB file, but still outperformed the other algorithms. AES exhibited steady growth in processing time, starting at 0.03 seconds for smaller files and increasing to 0.88 seconds for the largest. Blowfish maintained consistent times for smaller files but rose sharply to 1.5 seconds for the 124 MB file. Fernet followed a similar trend to Blowfish, processing smaller files efficiently but slowing down with larger ones. Overall, HELO was the fastest for CSV files, followed by AES and Fernet, while Blowfish took the longest (Figure 8). Image Files: For image files, the results were different. HELO performed best for smaller images (368 KB to 740 KB) with times ranging from 0.01 to 0.03 seconds. However, as file sizes increased to 5 MB, 20 MB, and 40 MB, HELO’s time rose to 0.75 seconds for the 40 MB file, making it slower than AES (0.14 seconds), Blowfish (0.41 seconds), and Fernet (0.22 seconds). HELO’s use of multithreading, while usually beneficial, may have caused overhead when processing larger image files, leading to reduced efficiency. Therefore, HELO was the fastest for smaller image files, but AES was the best for larger ones (Figure 9). 16
P REPRINT
HELO Cryptography
Time (Seconds)
CPU Processing Time for TXT Files 0.13 0.12 0.11 0.1 0.09 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 0
HELO AES Blowfish Fernet
15B
118B 171B 1KB 10KB File Size (B=Bytes, KB=Kilobytes)
22KB
Figure 7: CPU Processing Time for TXT Files
Time (Seconds)
CPU Processing Time for CSV Files 1.6 1.5 1.4 1.3 1.2 1.1 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0
HELO AES Blowfish Fernet
1MB
6MB
10MB 67MB 84MB File Size (MB=Megabytes)
Figure 8: CPU Processing Time for CSV Files
17
124MB
P REPRINT
HELO Cryptography
CPU Processing Time for Image Files 0.8 HELO AES Blowfish Fernet
0.7
Time (Seconds)
0.6 0.5 0.4 0.3 0.2 0.1 0
368KB
600KB 740KB 5MB 20MB File Size (KB=Kilobytes, MB=Megabytes)
40MB
Figure 9: CPU Processing Time for Image Files
6.3.2
RAM Usage Analysis
TXT and CSV Files: The TXT files (Figure 10) and CSV files (Figure 11) showed similar trends across algorithms with HELO, using approximately 4.70 MB of RAM, AES around 6.30 MB, Blowfish at 6.40 MB, and Fernet using 6.23 MB. As a result, it proves that HELO’s lower RAM usage for TXT and CSV files indicates better memory efficiency. This analysis shows that HELO consistently showed lower RAM usage than the other algorithms. RAM Usage for TXT Files 10 9
RAM Usage (Megabytes)
8 7 6 5 4 3 HELO AES Blowfish Fernet
2 1 0
15B
118B 171B 1KB 10KB File Size (B=Bytes, KB=Kilobytes) Figure 10: RAM Usage for TXT Files
18
22KB
P REPRINT
HELO Cryptography
RAM Usage (Megabytes)
RAM Usage for CSV Files 8 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
HELO AES Blowfish Fernet 1MB
6MB
10MB 67MB 84MB File Size (MB=Megabytes)
124MB
Figure 11: RAM Usage for CSV Files
Image Files: For image files, as the file sizes grew, HELO’s RAM usage increased, peaking at 9.17 MB for a 20 MB file, before dropping to 7.93 MB for a 40 MB file. Whereas, the memory usage of the other algorithms like AES, Fernet, and Blowfish has a peak value of 9.8 MB, 9.4 MB, and 8.9 MB respectively. In contrast, AES, Blowfish, and Fernet had more consistent RAM usage for larger files compared to HELO (Figure 12).
RAM Usage (Megabytes)
RAM Usage for Image Files 10 9.5 9 8.5 8 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
HELO AES Blowfish Fernet 368KB
600KB 740KB 5MB 20MB File Size (KB=Kilobytes, MB=Megabytes) Figure 12: RAM Usage for Image Files 19
40MB
P REPRINT
HELO Cryptography
6.3.3
Runtime Analysis
The following figures are generated for Runtime Analysis. These figures will be used to analyze each type of file for different types of algorithms based on the runtime they have had. Runtime is the amount of time a computer program or algorithm takes to execute a program. In this case, runtime represents how long it takes for the encryption or decryption process to complete for a given file size. TXT Files: For TXT files, the runtime analysis revealed that our proposed cryptographic model consistently had the fastest performance. It recorded an average runtime of 0.05 seconds, outperforming the other algorithms by a significant margin. Whereas, Fernet followed closely behind, showing comparable efficiency, but not quite matching HELO’s speed. In addition, AES demonstrated moderate performance with an average runtime of 0.07 seconds, slightly slower than Fernet and HELO. However, Blowfish was the slowest algorithm when processing the TXT files, recording an average runtime of 0.11 seconds, making it almost twice as slow as HELO cryptography. As a result, this analysis suggests that HELO is particularly well-suited for handling smaller, less complex file types like TXT, where the processing demands are relatively low and speed is paramount (Figure 13).
Runtime (Seconds)
Runtime Analysis for TXT Files 0.15 0.14 0.13 0.12 0.11 0.1 0.09 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 0
HELO AES Blowfish Fernet 15B
118B 171B 1KB 10KB File Size (B=Bytes, KB=Kilobytes)
22KB
Figure 13: Runtime Analysis for TXT Files CSV Files: In the case of CSV files, our proposed cryptographic model, HELO again maintained its position as the fastest algorithm. For smaller file sizes, such as the 1 MB CSV file, HELO processed it in just 0.06 seconds, demonstrating its efficiency in handling structured data files. However, as the file sizes grew, the runtime naturally increased, with HELO taking 1.96 seconds to process a 124 MB CSV file. Even with this increase, HELO still outperformed the other algorithms. However, AES and Blowfish exhibited significantly higher runtimes, especially as the file sizes grew. Therefore, this pattern highlights HELO’s ability to manage structured data effectively, making it the most efficient choice for CSV file encryption and decryption tasks. While AES and Blowfish are capable of processing such files, their runtimes increased more sharply with the file size, indicating that they are struggling with large datasets compared to HELO cryptography (Figure 14). Image Files: For image files, the runtime analysis took a different turn. While HELO was still fast for smaller image files, such as those around 368 KB to 740 KB, where it took between 0.01 to 0.03 seconds, its performance began to taper off with larger files. When processing a 40 MB image file, HELO’s runtime rose significantly to 0.75 seconds. This was slower than AES, which recorded a runtime of 0.14 seconds for the same file, making AES the better choice for larger image files. Blowfish, with a runtime of 0.41 seconds, and Fernet, with a runtime of 0.22 seconds, also performed better than HELO for larger images. The results suggest that HELO’s efficiency diminishes as file size increases, especially for more complex files like images. This is likely due to the 20
P REPRINT
HELO Cryptography
overhead created by HELO’s multithreading process, which, while beneficial for smaller and simpler files, may become a bottleneck for larger and more complex file types. Therefore, AES emerged as the most suitable algorithm for handling large image files, demonstrating faster runtimes and more consistent performance (Figure 15).
Runtime (Seconds)
Runtime Analysis for CSV Files 4.5 4.2 3.9 3.6 3.3 3 2.7 2.4 2.1 1.8 1.5 1.2 0.9 0.6 0.3 0
HELO AES Blowfish Fernet
1MB
6MB
10MB 67MB 84MB File Size (MB=Megabytes)
124MB
Figure 14: Runtime Analysis for CSV Files
Runtime (Seconds)
Runtime Analysis for Image Files 8.5 8 7.5 7 6.5 6 5.5 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
HELO AES Blowfish Fernet
368KB
600KB 740KB 5MB 20MB File Size (KB=Kilobytes, MB=Megabytes)
Figure 15: Runtime Analysis for Image Files
21
40MB
P REPRINT
HELO Cryptography
6.4
Energy Consumption Analysis
The results of the CPU processing time from our performance analysis will be used to measure the energy consumption of each cryptographic algorithm. Here, the unit of CPU processing time is seconds, watts for power, and joules for energy. In addition, the formula used to analyze energy consumption is provided below. Energy = P ower × T ime TXT Files: Results from energy consumption for the TXT files vary across several file sizes. Each cryptographic algorithm produces different results based on the time taken and the power used during the process. Firstly, HELO consumed 0.95 Joules of energy for 1 Byte of file, and this remained constant for 118 Bytes, 1 KB, and 22 KB. However, energy consumption slightly increased to 2.85 Joules for 171 KB and 10 KB. In contrast, the other algorithms used more energy to operate efficiently. In this analysis, AES required 3 times more energy than HELO for 1 Byte, 118 Bytes, 1 KB, and 22 KB. It used 1.67 times more energy for 171 Bytes and 33.33% less energy than HELO for 10 KB. Likewise, Blowfish consumed 5 times more energy for 1 Byte and 22 KB, 9 times more for 118 Bytes, 2 times more for 171 Bytes, 8 times more for 1 KB, and 2.67 times more for 10 KB than HELO. Similarly, Fernet utilized 5 times more energy for 1 Byte, 6 times more for 118 Bytes and 1 KB, and 3 times more for 22 Bytes than HELO. However, both HELO and Fernet consumed equal energy for 171 Bytes and 10 KB. After a competitive analysis, it is evident that HELO surpasses other algorithms in terms of consuming less energy to execute efficiently (Table 3). Table 3: Energy Consumption for TXT Files File Size 1 Byte
118 Bytes
171 Bytes
1 KB
10 KB
22 KB
Cryptography HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet
Power (W) 95
95
95
95
95
95
Time (S) 0.01 0.03 0.05 0.05 0.01 0.03 0.09 0.06 0.03 0.05 0.06 0.03 0.01 0.03 0.08 0.06 0.03 0.02 0.08 0.03 0.01 0.03 0.05 0.03
Energy (J) 0.95 2.85 4.75 4.75 0.95 2.85 8.55 5.7 2.85 4.75 5.7 2.85 0.95 2.85 7.6 5.7 2.85 1.9 7.6 2.85 0.95 2.85 4.75 2.85
CSV Files: For CSV files, AES required 10 times more energy than HELO for 1 MB and 6 MB, 1.67 times more for 10 MB, 2.03 times more for 67 MB, 20.25 times more for 84 MB, and 3.85 times more for 124 MB. Additionally, Blowfish consumed 3 times more energy for 1 MB, 5 times more for 6 MB, 1.81 times more for 67 MB, 11.25 times more for 84 MB, and 2.28 times more for 124 MB than HELO. Similarly, Fernet utilized 5 times more energy for 1 MB, 5 times more for 6 MB, 1.27 times more for 67 MB, 23 times more for 84 MB, and 3.33 times more for 124 MB than HELO. Furthermore, Blowfish and Fernet both consumed 5 and 1.2 times more energy than HELO for 6 MB and 10 MB of a CSV file. Finally, this analysis also indicates that HELO consumes significantly less energy compared to the other cryptographic algorithms (Table 4). Image Files: For image files, both AES and Blowfish required 6 times more energy than HELO for 368 KB and 600 KB. They also consumed 1.67 times more energy for a 740 KB file. Additionally, Fernet used 3 times more energy for 368 KB and 2 times more for 600 KB of image files. However, HELO struggled with performance when handling larger files. Consequently, the CPU required significantly more time to operate, which resulted in higher 22
P REPRINT
HELO Cryptography
energy consumption compared to the other algorithms. According to the analysis, AES consumed 52.31% less energy at 20 MB. Furthermore, Blowfish and Fernet used 47.69% and 61.54% less energy, respectively, for the same file size. Similarly, AES and Blowfish utilized 45.33% less energy at 40 MB, while Fernet needed 69.26% less energy than HELO. This analysis indicates that HELO is very effective for smaller image files but degrades its efficiency in energy consumption with larger ones (Table 5). Table 4: Energy Consumption for CSV Files File Size 1 MB
6 MB
10 MB
67 MB
84 MB
124 MB
Cryptography HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet
Power (W) 95
95
95
95
95
95
Time (S) 0.01 0.1 0.03 0.05 0.01 0.1 0.05 0.05 0.06 0.1 0.05 0.05 0.33 0.67 0.39 0.42 0.04 0.81 0.45 0.92 0.39 1.5 0.89 1.3
Energy (J) 0.95 9.5 2.85 4.75 0.95 9.5 4.75 4.75 5.7 9.5 4.75 4.75 31.35 63.65 37.05 39.9 3.8 76.95 42.75 87.4 37.05 142.5 84.55 123.5
Table 5: Energy Consumption for Image Files File Size 368 KB
600 KB
740 KB
5 MB
20 MB
40 MB
Cryptography HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet HELO AES Blowfish Fernet
Power (W) 95
95
95
95
95
95
23
Time (S) 0.01 0.06 0.06 0.03 0.01 0.06 0.06 0.02 0.03 0.05 0.05 0.03 0.15 0.17 0.14 0.12 0.65 0.31 0.34 0.25 0.75 0.41 0.41 0.22
Energy (J) 0.95 5.7 5.7 2.85 0.95 5.7 5.7 1.9 2.85 4.75 4.75 2.85 14.25 16.15 13.3 11.4 61.75 29.45 32.3 23.75 71.25 38.95 38.95 20.9
P REPRINT
HELO Cryptography
6.5
Avalanche Effect Analysis
Cryptography uses multiple methods to protect data. One of the most important ones is the avalanche effect. It promises that even a small change in the input will result in a significant change in the output. Also, this analysis enhances security by making it critical for unauthorized users to decode the original data without the correct decryption key. The formula for calculating the average value of the avalanche effect of HELO corresponding to bit positions is given below. ! n 1 X Average Avalanche Effect (%) = Ci T i=0 Here, T is the total number of bit positions in the ciphertext which is 21, i is the initial index of the flipping bit which is 0, n is the total number of bits flipped which is 20, and Ci is the value of the avalanche effect in each bit position. Consequently, the value of T will be n + 1.
Table 6: Avalanche Effect Analysis of TXT Files Bit position
15 B
118 B
171 B
1 KB
10 KB
22 KB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
59.17 50.00 47.50 46.67 50.83 55.00 45.00 50.00 45.83 45.83 59.17 47.50 53.33 53.33 44.16 57.50 47.50 54.17 45.83 46.67 50.83
52.97 47.88 50.11 50.00 52.01 47.56 49.68 49.89 47.35 50.42 51.69 49.57 49.15 49.15 52.44 52.97 46.19 51.37 50.11 50.58 51.17
50.73 49.64 50.80 46.27 48.46 51.02 49.20 48.31 53.51 50.80 51.38 49.42 51.09 48.17 51.02 49.56 50.44 49.34 50.95 50.88 49.49
50.75 49.10 50.42 50.63 50.05 50.64 50.29 49.00 49.28 49.64 50.01 51.10 49.74 50.83 50.04 50.00 50.34 49.31 49.97 50.07 49.66
50.17 49.72 49.83 49.75 49.94 49.87 49.89 49.94 49.85 49.93 49.84 49.89 50.11 50.01 50.16 50.11 49.93 49.89 50.13 49.83 49.98
50.10 49.45 49.79 49.91 49.44 50.37 50.15 49.88 50.49 49.41 50.08 50.90 49.48 49.99 50.17 49.88 49.80 49.81 50.18 50.09 50.10
Average (%)
55.00
52.07
50.11
50.20
50.08
50.06
This is our first analysis of the Avalanche Effect, where we analyzed several TXT files. We flipped 0 to 20 bit positions for each file to check the avalanche effect. For flipping each bit position, we noted the percentage value of the avalanche effect. The average for all the files that underwent the Avalanche Effect test is above or equal to the ideal avalanche effect of 50%. This phenomenal result ensures that HELO accomplishes the expected benchmark (Table 6). Our second analysis was to put CSV (Comma Separated Value) files on a test. We followed the same process of flipping bit positions and finding out the avalanche effect value for each file. The average is taken by finding the sum of all the bit position values and then dividing by the number of bit positions for each file. Therefore, the result is above 50% for all files taken to test (Table 7). Since the image file needs some rendering and other process capabilities to run and view it, it must check whether the avalanche effect value decreases. Fortunately, after testing, we found that it gives an average value equal to or slightly more than the standard avalanche effect value, which is 50%. This test provides us with an important analysis and evaluates if our algorithm is secure to use or not. Hence, we can conclude that this test has provided us with reliability and security assurance (Table 8). 24
P REPRINT
HELO Cryptography
Table 7: Avalanche Effect Analysis of CSV Files Bit position
1 MB
6 MB
10 MB
67 MB
84 MB
124 MB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
50.40 49.48 49.62 49.36 49.78 49.81 49.72 49.01 50.20 50.45 49.46 49.23 49.41 50.53 49.96 49.66 49.35 50.19 49.49 50.33 49.94
50.60 49.62 50.26 50.60 50.06 51.09 48.84 49.81 50.34 49.46 50.17 50.37 50.28 50.32 50.64 49.89 49.96 49.75 48.93 49.50 50.47
50.00 50.00 50.01 50.00 49.99 50.00 49.99 50.00 49.99 50.00 50.00 50.00 50.00 50.00 50.01 50.00 50.01 50.00 50.00 50.00 50.01
50.18 49.35 51.11 50.90 50.08 49.64 50.49 50.49 49.98 50.07 50.64 50.38 49.78 50.06 50.44 50.09 50.11 50.75 49.99 51.08 50.01
50.27 50.28 49.74 49.17 49.92 51.03 50.62 49.68 49.55 50.69 50.08 49.23 49.50 50.32 50.09 50.11 49.64 50.43 49.79 50.07 51.10
50.41 49.40 49.96 50.04 50.33 49.78 50.71 48.73 49.55 49.87 49.51 49.59 50.76 49.80 49.63 50.20 49.84 51.12 50.60 49.73 49.89
Average (%)
50.17
50.54
50.01
50.09
50.69
50.15
Table 8: Avalanche Effect Analysis of Image Files Bit position
5 MB
20 MB
40 MB
80 MB
95 MB
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
50.13 50.12 49.83 49.85 49.97 50.05 49.96 49.94 49.83 49.75 49.91 49.79 50.09 50.23 50.31 50.06 49.60 50.26 49.87 49.77 50.20
50.15 50.03 49.96 50.06 50.05 50.13 49.98 49.91 49.89 50.22 50.04 50.02 50.04 50.07 49.91 49.82 50.08 50.05 49.99 50.00 50.21
50.05 49.97 50.01 49.96 50.02 49.98 50.04 49.98 49.94 49.90 49.87 50.00 49.95 49.98 50.01 49.97 50.15 49.96 50.04 49.95 50.04
50.22 50.10 49.87 49.89 49.94 49.93 50.02 49.87 50.17 49.79 50.21 49.68 49.97 50.02 50.11 50.14 50.12 50.10 49.73 49.83 50.18
50.10 50.04 49.98 49.95 50.04 49.93 50.02 49.99 49.98 50.07 49.98 50.10 49.96 49.92 49.90 50.12 49.87 49.83 49.96 49.88 50.06
Average (%)
50.16
50.18
50.04
50.20
50.08
25
P REPRINT
HELO Cryptography
6.6
Justification for Choosing Specific Components in HELO
Table 9 summarizes the performance evaluation and justification for the cryptographic components selected in our algorithm. It outlines each component against established alternatives based on the analyses conducted, focusing on efficiency, resource consumption, and security benefits. Table 9: Justification of Selected Components Compared to Common Alternatives
7
Component Symmetric Encryption and Encryption Integrity
Selected Algorithm ChaCha20-Poly1305
Alternative AES, Blowfish, Fernet
Hash Function
SHA3-256
SHA2-256, SHA-1
Key Exchange
ECDH
RSA, DH
Digital Signature
ECDSA
RSA
Nonce
Unique per counter-based
session,
Random Nonce
Justification ChaCha20-Poly1305 were chosen over AES and Fernet due to their superior performance in software-based environments, requiring fewer CPU cycles and memory resources. Its constanttime execution model provides strong resistance to timing attacks, a critical consideration for IoT security. Additionally, its AEAD construction allows simultaneous encryption and authentication in a single pass, reducing runtime and energy consumption compared to dual-pass schemes like Fernet, which is discussed in CPU processing ( 6.3.1) as well as in the runtime analysis ( 6.3.3). Sponge-based design offers better resistance to length extension and collision attacks; suitable for future post-quantum considerations [57]. Smaller key sizes, lower computational cost, and better efficiency in low-power embedded systems that provide forward secrecy [47]. Shorter keys and signatures reduce transmission and storage overhead, and faster signature generation/verification is better suited for IoT and P2P communication [46]. Ensures cryptographic freshness; prevents nonce reuse vulnerabilities in stream cipher modes; lightweight implementation for deterministic nonce generation.
Conclusion
The HELO cryptographic system addresses numerous security issues identified during the investigation by implementing a comprehensive and secure system that ensures that no vulnerabilities are found in many existing models. The system can handle security issues related to authorization, authentication, or even data access very effectively. Furthermore, this system goes about a unique way of introducing a new key exchange algorithm to ensure that the data and system itself are fully secured. The research demonstrates a multi-layered security approach that provides detailed data and access control layer security, which can protect data against several types of breaches and cyberattacks. These security measures reduce the risk of several types of attacks, which ensures that precious data is secured and also prevents hackers from exploiting the weakness in the system or compromised end-user credentials. However, the algorithm didn’t reduce its performance while ensuring strong protection. It performs faster than the existing algorithms in many cases. Hence, this HELO cryptographic system has been proven to be one of the best approaches for data security as lightweight cryptography in IoT devices.
8
Future Work
In the rapidly evolving landscape of computerized security, the planning and ongoing upgrades of cryptographic frameworks play an urgent role in defending sensitive data and guaranteeing secure communication over different technological domains. Here, HELO is a modern cryptographic approach that offers robust security against a wide range of threats. Therefore, ongoing research and development are crucial to address emerging vulnerabilities and opportunities to identify for system enhancement. One of the key focuses of future HELO studies is improving resilience against critical cyberattacks, which involves empowering detection and response capabilities. With that, 26
P REPRINT
HELO Cryptography
strengthening encryption mechanisms and introducing adaptive defenses can enhance the dynamic response to new threat models. In addition, the focus on the future study of blockchain and distributed laser technologies in IoT security is important to us as it offers transparency, irreversibility, and decentralized trust [54]. Another important area of our future study is the examination of homomorphic encryption, which allows calculations on encrypted data without revealing the underlying information. Parallel to technological development, we will discover regulatory, legal ideas, and security protocols in our future work to follow the International Data Protection Act and cybersecurity policy so that the cryptographic applications are safe, valid, and trustworthy [55], [56]. However, the current configuration of the system introduces some limitations. Particularly, the absence of real IoT hardware limits the actual generality of the results in the embedded environment. To overcome this, our future work will involve deploying the system on real IoT devices and evaluating performance, energy consumption, scalability, and computational overhead under more realistic conditions. By addressing both existing obstacles and future possibilities, our comprehensive goal is to strengthen digital trust and fundamental pillars of privacy in the era of the Internet.
References [1] Dhanda, S.S., Singh, B., & Jindal, P., Lightweight Cryptography: A Solution to Secure IoT, Wireless Personal Communications, 112: 2001–2015, 2020. doi: 10.1007/s11277-020-07134-3 [2] Naru, E.R., Saini, H., & Sharma, M., A Recent Review on Lightweight Cryptography in IoT, I-SMAC 2017. doi: 10.1109/I-SMAC.2017.8058307 [3] Alassaf, N. & Gutub, A., Simulating Light-weight Cryptography Implementation for IoT Healthcare Data Security Applications, International Journal of E-Health and Medical Communications, 10, 1–15, 2019. Available: https://doi.org/10.4018/IJEHMC.2019100101 [4] Thakor, V.A., Razzaque, M.A., & Khandaker, M.R.A., Lightweight Cryptography Algorithms for ResourceConstrained IoT Devices, IEEE Access, 9, 28177–28193, 2021. doi: 10.1109/ACCESS.2021.3052867 [5] Khan, M.N., Rao, A., & Camtepe, S., Lightweight Cryptographic Protocols for IoT-Constrained Devices: A Survey, IEEE IoT Journal, 8(6), 4132–4156, 2021. doi: 10.1109/JIOT.2020.3026493 [6] Mhaibes, H.I., Abood, M.H., & Farhan, A.K., Simple Lightweight Cryptographic Algorithm to Secure Embedded IoT Devices, iJIM, 16(20), 2022. [7] Gyamfi, E., Ansere, J.A., & Xu, L., ECC Based Lightweight Cybersecurity Solution for IoT Using MEC, FMEC 2019. doi: 10.1109/FMEC.2019.8795315 [8] Santis, F.D., Schauer, A., & Sigl, G., ChaCha20-Poly1305 Authenticated Encryption for High-Speed Embedded IoT, DATE 2017. doi: 10.23919/DATE.2017.7927078 [9] Dutta, I.K., Ghosh, B., & Bayoumi, M., Lightweight Cryptography for Internet of Insecure Things: A Survey, IEEE CCWC 2019. doi: 10.1109/CCWC.2019.8666557 [10] Kumar, M.T., Katragadda, R.K., Kolli, V.S., & Rahiman, S.L., A Hybrid Approach for Enhancing Security in IoT, ICISS 2019. doi: 10.1109/ISS1.2019.8907974 [11] Alotaibi, M., Improved Blowfish Algorithm-Based Secure Routing Technique in IoT-based WSN, IEEE Access, 9, 159187–159197, 2021. doi: 10.1109/ACCESS.2021.3130005 [12] Ghosh, S.K., Rana, S., Pansari, A., Hazra, J., & Biswas, S., Hybrid Cryptography Algorithm for Secure and Low Cost Communication, ICCSEA 2020. doi: 10.1109/ICCSEA49143.2020.9132862 [13] Marka, 1K Random 3D Shapes, Kaggle Dataset, 2023. Available: https://www.kaggle.com/datasets/ makra2077/1000-random-3d-shapes [14] MARIONETTE, TACO Dataset YOLO Format, Kaggle Dataset, 2023. Available: https://www.kaggle.com/ datasets/vencerlanz09/taco-dataset-yolo-format [15] Susol, M., TF2.16 Requirements.txt, Kaggle Dataset, 2024. Available: https://www.kaggle.com/datasets/ gdataranger/tf2-16-requirements-txt [16] Yadav, D. & Murilão, M.R., English to French Translations Dataset, Kaggle Dataset, 2020. Available: https: //www.kaggle.com/datasets/digvijayyadav/frenchenglish [17] Tatman, R., Thai Sentiment Analysis Toolkit, Kaggle Dataset, 2017. Available: https://www.kaggle.com/ datasets/rtatman/thai-sentiment-analysis-toolkit [18] SEANNY, Hip-hop Encounters Data Science, Kaggle Dataset, 2021. Available: https://www.kaggle.com/ datasets/rikdifos/rap-lyrics 27
P REPRINT
HELO Cryptography
[19] Sharma, A., Sample Superstore Dataset, Kaggle Dataset, 2020. Available: https://www.kaggle.com/ datasets/bravehart101/sample-supermarket-dataset [20] Mandala, S.K., Credit Score Classification Dataset, Kaggle Dataset, 2023. Available: https://www.kaggle. com/datasets/sujithmandala/credit-score-classification-dataset [21] Leone, S., FIFA 22 Complete Player Dataset, Kaggle Dataset, 2021. Available: https://www.kaggle.com/ datasets/stefanoleone992/fifa-22-complete-player-dataset [22] LDMTWO & AI, S., Midjourney 2022 - 250k, Kaggle Dataset, 2022. Available: https://www.kaggle.com/ datasets/ldmtwo/midjourney-250k-csv [23] Ellis, C.M., World’s Top 200000 Scientists, Kaggle Dataset, 2023. Available: https://www.kaggle.com/ datasets/carlmcbrideellis/worlds-100000-top-scientists [24] Cariboo, D., Football Data from Transfermarkt, Kaggle Dataset, 2024. Available: https://www.kaggle.com/ datasets/davidcariboo/player-scores?select=appearances.csv [25] Cortinhas, S., Apples or Tomatoes – Image Classification, Kaggle Dataset, 2022. Available: https://www. kaggle.com/datasets/samuelcortinhas/apples-or-tomatoes-image-classification [26] Satpathy, P., Soil Types Dataset, Kaggle Dataset, 2021. Available: https://www.kaggle.com/datasets/ prasanshasatpathy/soil-types [27] Anwar, A., Cats & Dogs, Kaggle Dataset, 2021. Available: d4rklucif3r/cat-and-dogs
https://www.kaggle.com/datasets/
[28] Subbiah, V., Pokemon Image Dataset, Kaggle Dataset, 2024. Available: https://www.kaggle.com/datasets/ vishalsubbiah/pokemon-images-and-types [29] Koklu, M., Pistachio Image Dataset, Kaggle Dataset, 2022. Available: https://www.kaggle.com/datasets/ muratkokludataset/pistachio-image-dataset [30] Bhathena, J., Weather Image Recognition, Kaggle Dataset, 2021. Available: https://www.kaggle.com/ datasets/jehanbhathena/weather-dataset/data [31] Nath Nayak, G. & Ghosh Samaddar, S., Different Flavours of Man-In-The-Middle Attack: Consequences and Solutions, ICCSIT 2010. doi: https://doi.org/10.1109/ICCSIT.2010.5563900 [32] Babu, P.R., Bhaskari, D.L., & Satyanarayana, C.H., A Comprehensive Analysis of Spoofing, IJACSA, 1(6), 2010. [33] Herr, T., Lee, J., Loomis, W., & Scott, S., Breaking Trust: Shades of Crisis Across an Insecure Software Supply Chain, Atlantic Council, 2020. [34] Albinali, H. & Azzedin, F., Replay Attacks in RPL-based IoT: Empirical Study, Computer Networks, 257, 110996, 2025. [35] Alkhwaja, I. et al., Password Cracking with Brute Force and Dictionary Attack Using Parallel Programming, Applied Sciences, 13(10), 5979, 2023. [36] Khoo, K., Gong, G., & Lee, H.K., The Rainbow Attack on Stream Ciphers Based on Maiorana–McFarland Functions, ACNS, Springer, 2006. [37] Kim, M. & Suh, T., Eavesdropping Vulnerability in Infrared IoT Communication, Sensors, 21(24), 8207, 2021. [38] Shrivastava, R.K., Mishra, S., Archana, V.E., & Hota, C., Preventing Data Tampering in IoT Networks, ANTS 2019. [39] Shim, K.-A., Universal Forgery Attacks on WBAN Authentication Schemes, IEEE IoT Journal, 6(5), 9211–9212, 2019. [40] Shwartz, O. et al., Reverse Engineering IoT Devices: Effective Techniques, IEEE IoT Journal, 5(6), 4965–4976, 2018. [41] Chavan, G.T. et al., Investigating the Effectiveness of Birthday Attack Strategies in Cryptography, SMART GENCON 2023. [42] Aoki, K. & Sasaki, Y., Preimage Attacks on MD4, MD5 and More, SAC 2008. [43] Weiß, M., Heinz, B., & Stumpf, F., A Cache Timing Attack on AES in Virtualized Environments, Financial Cryptography Conference, 2012. [44] Pandiya, C., Singh, S., & Chandavarkar, B.R., Mitigating Masquerade Using Nonce in Symmetric Key Distribution, ICPS 2020. doi: 10.1109/ICPS51508.2020.00014 28
P REPRINT
HELO Cryptography
[45] Luo, P., Fei, Y., Zhang, L., & Ding, A.A., Differential Fault Analysis of SHA3-224 and SHA3-256, FDTC 2016. doi: 10.1109/FDTC.2016.17 [46] Farooq, S.M., Hussain, S.S., & Ustun, T.S., Elliptic Curve Digital Signature Algorithm (ECDSA) CertificateBased Authentication Scheme for AMI, 2019 Innovations in Power and Advanced Computing Technologies. doi: 10.1109/i-PACT44901.2019.8959967 [47] Adarbah, H.Y., Moghadam, M.F., Maata, R.L.R., Mohajerzadeh, A., & Al-Badi, A.H., Security challenges of selective forwarding attack and design a secure ECDH-based authentication protocol to improve RPL security, IEEE Access, 11, 11268–11280, 2023. doi: 10.1109/ACCESS.2022.3221434 [48] Jassim, S.A. & Farhan, A.K., A Survey on Stream Ciphers for Constrained Environments, BICITS 2021. doi: https://doi.org/10.1109/BICITS51482.2021.9509883 [49] Kuwelkar, S. & Haldankar, C., Implementation of AES and Blowfish Algorithm, IJRET, 3, 143–146, 2014. doi: 10.15623/ijret.2014.0315026 [50] Parihar, V. & Kulshrestha, M., Blowfish Algorithm: A Detailed Study, IJBRE, 3, 2016. [51] Lu, Z. & Mohamed, H., A Complex Encryption System Design Implemented by AES, Journal of Information Security, 12, 159–174, 2021. doi: 10.4236/jis.2021.122009 [52] P., D., Babu, S.S., & Vijayalakshmi, Y., Enhancement of E-commerce Security Through Asymmetric Key Algorithm, Computer Communications, 153, 2020. doi: 10.1016/j.comcom.2020.01.033 [53] Pronika, Panda, S.P., & Tyagi, S.S., Performance of Fernet and AES Algorithms, IJERA, 12, 2022. Available: https://www.ijera.com/papers/vol12no12/O1212105111.pdf [54] Madhi, M.H., Al-Bakry, A.M., & Farhan, A.K., IoT Conception Based on Blockchain Technology: A Review, Al-Mansour Journal, 1(1), 2023. [55] Farhan, A.K., Security Protocol for Mobile Data, PhD Thesis, University of Technology, 2009. [56] Ali, R.S. & Farhan, A.K., Security Protocol of Keys Management System for Transmission Encrypted Data, IJCNIS, 2018. [57] Bertoni, G., Daemen, J., Peeters, M., & Van Assche, G., Sponge-Based Pseudo-Random Number Generators, In CHES 2010, Springer, pp. 33–47.
29