Implementation of a Data-Parallel Approach on a Lightweight Hash Function for IoT Devices

Abstract

The Internet of Things is used in many application areas in our daily lives. Ensuring the security of valuable data transmitted over the Internet is a crucial challenge. Hash functions are used in cryptographic applications such as integrity, authentication and digital signatures. Existing lightweight hash functions leverage task parallelism but provide limited scalability. There is a need for lightweight algorithms that can efficiently utilize multi-core platforms or distributed computing environments with high degrees of parallelization. For this purpose, a data-parallel approach is applied to a lightweight hash function to achieve massively parallel software. A novel structure suitable for data-parallel architectures, inspired by basic tree construction, is designed. Furthermore, the proposed hash function is based on a lightweight block cipher and seamlessly integrated into the designed framework. The proposed hash function satisfies security requirements, exhibits high efficiency and achieves significant parallelism. Experimental results indicate that the proposed hash function performs comparably to the BLAKE implementation, with slightly slower execution for large message sizes but marginally better performance for smaller ones. Notably, it surpasses all other evaluated algorithms by at least 20%, maintaining a consistent 20% advantage over Grostl across all data sizes. Regarding parallelism, the proposed PLWHF achieves a speedup of approximately 40% when scaling from one to two threads and 55% when increasing to three threads. Raspberry Pi 4-based tests for IoT applications have also been conducted, demonstrating the hash function’s effectiveness in memory-constrained IoT environments. Statistical tests demonstrate a precision of ±0.004, validate the hypothesis in distribution tests and indicate a deviation of ±0.05 in collision tests, confirming the robustness of the proposed design.

1. Introduction

The Internet of Things (IoT) refers to a global network of interconnected devices equipped with sensors, computing capabilities, software and various communication technologies. As everyday objects become intelligent, they not only collect data from their environment but also exchange information over the Internet [1]. A vast number of physical devices embedded with various sensors and controllers are expected to connect to the Internet via different access networks. Heterogeneous access networks include RFID, WiMAX, Wi-Fi and cellular networks, among others.

Currently, over 12 billion connected devices generate vast data streams while exchanging information through the Internet. Efficiently collecting, processing and analyzing data is crucial for transforming them into valuable insights within IoT applications [2]. The IoT ecosystem involves multiple stages, including raw data collection, processing, analysis and communication with other connected devices via the Internet. The IoT reference model developed by Cisco delineates the conceptual layers that comprise physical devices and controllers, connectivity, edge computing, storage, data abstraction, applications (including analytics, management and reporting), and user and business processes.

IoT systems must consider performance criteria such as throughput, latency and energy consumption due to hardware limitations. Moreover, security and privacy requirements must be addressed due to the critical nature of the information transmitted by IoT devices, particularly in blockchain-based IoT applications [3]. Confidentiality, authentication and integrity are fundamental security challenges in IoT. Confidentiality ensures that only authorized entities can access data, preventing eavesdropping. Authentication verifies that both transmitting and receiving nodes are legitimate. Integrity ensures that data remains unaltered during transmission [4].

Hash functions are widely utilized in various security applications, including authentication [5,6], message authentication codes and digital signatures [7,8]. Moreover, hash functions provide an effective means of verifying data integrity (Figure 1).

Many conventional cryptographic hash functions have been developed for traditional computing environments such as PCs, laptops, servers, clients, network nodes, etc. Most conventional cryptographic hash functions are based on sequential constructions such as MD-5, SHA-1 and SHA-2. The sequential hash functions have some limitations, such as not benefiting from parallelism exactly [9]. However, parallelism offers a significant advantage for hardware or software implementations. Data-parallel and task-parallel approaches are widely used in traditional computing environments. Therefore, some methods have been developed for the data-parallel approach for classical hash functions, such as chaotic-based and lattice-based parallel hash functions. These hash functions usually utilize a tree structure suitable for data-parallel computing and take many advantages of multi-thread architecture. Task parallelism can be used in any construction by partitioning the tasks.

With the spread of embedded systems and IoT devices, lightweight hash functions that require fewer resources have been proposed. The lightweight hash functions that consider hardware limitations are preferred in IoT instead of conventional cryptographic hash functions. IoT is implemented on many hardware platforms out of FPGA [10,11,12] or specific hardware [13,14,15], such as microcontrollers (MCUs) [16,17]. Increasing processing demand and many advantages of multi-threading technology have triggered an increase in the number of cores in CPUs used by the microcontrollers for IoT devices. Today, IoT devices equipped with multi-core CPUs are being developed for various applications, including industrial automation [18] and blockchain-based systems [19], among others. For instance, the i.MX series with ARM Cortex-Mx cores by NXP and similar platforms are being widely used in these applications. The increasing number of cores in CPUs is becoming inevitable in both traditional and emerging platforms. Many cryptographic primitives must be developed to exploit the multi-threaded architecture on multi-core platforms or distributed systems for resource-constrained devices.

Consequently, resource-constrained devices such as IoT require lightweight cryptographic primitives; however, performance efficiency can be enhanced if these algorithms are implemented with parallel approaches. Some calculations in the lightweight hash functions can be performed in a task parallelism approach. However, the chaining mechanism of sequential constructions links each message block’s compression functions and must be processed sequentially. This sequential structure reduces the effect of parallelism, and the limited number of tasks allows restricted parallelization degrees. Suppose data parallelism is applied to lightweight hash functions. In that case, a high parallelization degree can be performed as much as the number of blocks of the input message, and massively parallel software can be provided. Therefore, a new hash function is proposed for IoT devices that operates in a data-parallel approach and is based on lightweight cryptography.

1.1. Related Works

Many types of research have focused on parallel and lightweight hash functions. The studies in the literature were designed according to different security requirements and different application areas. Most of the data-parallel studies used chaos-based and lattice-based techniques. Yang et al. [20] used lattice-based cryptography for collision resistance and parallel iterative hash structure. A similar study was carried out using coupled map lattices by Wang et al. [21]. Also, Li and Ge [22] used cross-coupled map lattices for a parallel hash function applied for multimedia communication security. Zhang et al. [23] presented a parallel hash function with initial values of chaining variables used on each round for different rotation values. Akhavan et al. [24] proposed a hash function based on three-dimensional trigonometric chaotic maps. A piecewise linear map and chaotic asymmetric tent map were utilized by Li et al. [25] for iterations with changeable parameters. Teh et al. [26] used multiple chaotic maps for hashing speed and a baseline network with a new shuffling mechanism. Additionally, Abdelfatah et al. [27] utilized multiple chaotic maps, including the tent map, logistic map and sine function, while introducing a new structure based on a diamond lattice. Slightly different from these chaotic map-based hash functions, Xiao et al. [28] used a chaotic neural network in their study.

Nouri et al. [29] presented a parallel hash function based on Chebyshev–Halley type methods with variable parameters from the location of the message blocks. The message was adapted into the chaotic repetition orbit, and the coarse-graining path was used for generating a hash value by Xiao et al. [30]. Kishore et al. [31] proposed a scheme to parallelize and improve the execution time of conventional hash functions named Enveloped Inverted Tree Recursive Hashing (EITRH). The proposed method consisted of three stages: message extension, parallel reduction and performing the hash value. Han et al. [32] presented an authenticated encryption and hash function on Graphics Processing Units (GPUs) for IoT applications called cuGimli, a parallel implementation of the Gimli-Cipher family for high throughput. Liu et al. [33] presented a parallel version of the HAIFA iterative structure based on the Lorenz chaotic system.

Additionally, many lightweight hash functions have been proposed for IoT devices in the literature, such as ARMADILLO [34], DM-PRESENT and H-PRESENT [35], GLUON [36], SPN-Hash [37], Lesamnta [38], SPONGENT [39], Photon [40], Quark [41], SipHash [42] and Neeva [43]. IoT devices can use a lightweight implementation of the SHA-3 winner Keccak [44], and the SHA-3 candidate BLAKE [45] also described itself as suitable for lightweight environments. Also, Bhoyar et al. [46] suggested a hardware implementation (FPGA and ASIC) of the Simeck encryption algorithm as a lightweight hash function. Another hardware implementation for embedded devices was proposed by El-Hadedy et al. [47] called PRO-GAGE, a processor that uses the GAGE hash function. Windarta et al. [48] proposed a hash function based on the Saturnin lightweight block cipher, utilizing a sponge-based mode of operation known as Beetle. Mahmoud et al. [49] proposed a fine-grained lightweight access control scheme incorporating hash function properties. Their approach employed attribute-based encryption (ABE) enhanced with residue number system (RNS) properties (RNS-ABE) for fog computing environments. Achar et al. [50] introduced four LiteHash functions inspired by SHA-512. These functions reduced computational costs using approximation techniques while preserving cryptographic security in their 2024 study. Validated using the NIST PRNG Test Suite, the design demonstrated improvements in area, power and throughput. It achieved up to 2 Gbps throughput while reducing area by 16.86% and power consumption by 32.48%, supporting the entire SHA-2 family with minimal modifications.

In addition to the aforementioned studies, various works have also been conducted on blockchain security protocols [51,52,53], hash algorithms for image processing [54,55], industrial security applications [56] and new hash functions [57].

A review of the literature (Table 1) indicates that numerous lightweight hash functions have been developed for various IoT devices. Existing lightweight hash functions are either designed with a serial architecture or implemented using task parallelism, which offers limited parallel execution. Additionally, existing data-parallel traditional hash functions are primarily based on chaotic and lattice-based architectures. While these algorithms can leverage data parallelism, their computational complexity and hardware requirements make them unsuitable for IoT devices with limited resources. Therefore, there is a need for a new hash function that combines lightweight properties with compatibility for data-parallel architectures.

In our previous study [58] and other works [59,60], we analyzed block cipher algorithms and evaluated high-performance block ciphers that could be suitable for hash algorithms for IoT devices. Subsequently, we implemented a lightweight hash function based on the SPECK cipher [61], followed by the design of another hash function based on the LEA cipher for blockchain applications [62]. In this work, a new hash function based on the SIMON cipher is designed and optimized for parallel processing architectures.

Existing conventional hash functions designed for data parallelism are unsuitable for IoT devices. Additionally, most current lightweight hash functions primarily use task parallelism. To address these limitations, this study presents a new data-parallel lightweight hash function (PLWHF) designed for IoT devices, ensuring massively parallel software execution and improved performance efficiency. The main contributions of this paper are as follows:

• A novel data-parallel lightweight hash function is developed, optimized for efficient execution on multi-core IoT devices and distributed systems.

• Differing from existing hash function designs, a new construction tailored for data-parallel processing is introduced.

• The proposed hash function significantly enhances hashing speed by integrating an optimized construction with an appropriate lightweight block cipher, even on a single core.

• The data-parallel approach achieves higher parallel efficiency and scalability compared to task-parallel methods, making it more suitable for IoT devices.

• The proposed hash function meets security requirements at least as effectively as other existing hash functions, and this has been validated through various tests.

1.2. Paper Organization

The rest of the paper is arranged as follows. Section 2 gives background on hash functions and their properties, including lightweight hash functions. Section 3 introduces the detailed structure of the proposed hash function. Security analysis and performance evaluations are presented in Section 4. The conclusions and future works are discussed in Section 5.

2. Background

2.1. Hash Functions

A hash function converts any message of arbitrary size from an entire set of binary sequences to some fixed-length set of binary sequences for mapping data [63]. Hash functions are basically many-to-one and one-way functions. One of the critical features that hash functions must consider is the collisions, which means different messages generate the same hash output. However, collisions in hash functions are inevitable because of the pigeonhole principle. But the collisions should be as difficult as possible. Techniques such as the birthday paradox and Wong’s method [64] have been proposed to determine collision resistance terms, which was officially described by Damgard [65] in 1987. Two other important features are as follows: pre-image resistance is the irreversibility of a hash function and second pre-image resistance is finding a different input message that returns the same hash value as a given message [66]. These resistances are the three basic hash function properties shown in Figure 2.

The security features of a hash function can be described as follows [67]:

• Compression: Hash function $h\left(x\right)$ should compress any message of an arbitrary size into fixed-length messages called a message digest.

• Ease of computation: Hash function $h\left(x\right)$ can efficiently perform the hash value of any input message in software and hardware platforms.

• Pre-image resistance: It should not have been possible to obtain the input message $m^{\prime }$ (pre-image) from a given hash value (s) such that $h\left(m^{\prime }\right)=s$, which is the irreversibility feature of a one-way function.

• Second pre-image resistance: It should not have been possible to obtain a second input message $m^{″}$ from a given input message $m^{\prime }$ such that $h\left(m^{\prime }\right)=h\left(m^{″}\right)$.

• Collision resistance: It should not have been possible to find two different given messages generating the same hash value such that $h\left(m^{\prime }\right)=h\left(m^{″}\right)$.

• Non-correlation: The input message and the corresponding hash value are not related in any way, which means every input message bit affects every hash value bit.

• Near-collision resistance: It should be challenging to find two different input messages whose hash values $h\left(m^{\prime }\right)$ and $h\left(m^{″}\right)$ hardly differ.

• Partial-pre-image resistance: It is necessary that any substring of the input message cannot be found from any given hash value or even for any given different substring of the input message.

The most appropriate way to generate a hash value from the input message is to split the message into several blocks and process them iteratively. This sequential hashing mode is still the most generally utilized despite the development of parallel architecture. Popular iterative hash functions use Merkle–Damgard [68,69], sponge [70], Davies–Meyer [71], wide/double pipe [72], HAIFA [73], tree-based [74], streaming, etc., constructions to ensure hash function requirements such as pre-image resistance, second pre-image resistance, collision resistance and the avalanche effect. Also, the hash functions can be categorized as keyless or keyed. Cryptographic keyless hash functions such as the SHA-2 or SHA-3 families do not need a key for compression. Cryptographic keyed hash functions require a fixed-length key to generate a fixed-length hash value that can be shared publicly or privately.

2.2. Lightweight Hash Functions

Machine-to-machine communication consists of many transmission types in IoT devices, such as server-to-device, server-to-server and device-to-device. Resource-constrained devices have limited energy capacity, decreased computation cycles, small memory sizes and a low number of gates. Traditional cryptographic primitives are not suitable for limited-resourced devices. Therefore, the scope of cryptographic primitives is improved with lightweight cryptography for resource-constrained devices. Lightweight block and stream ciphers were developed for encryption, and also lightweight hash functions, message authentication codes and authenticated encryption schemes have been introduced in the last few years [75].

Lightweight hash functions can have a decreased digest size and internal state to reduce computation operations. Also, most applications, such as tag-based applications, need the hashing of small messages. A tiny hardware implementation and fast execution time for small messages, etc., are expected for lightweight hash functions [76]. The lightweight hash functions can be categorized as follows [75]:

• Hash functions developed for resource-constrained nodes such as IoT devices and using existing constructions (SPONGENT, Quark, Photon, etc.).

• Lightweight implementation of traditional hash functions (lightweight implementation of Keccak or BLAKE).

• Lightweight hash functions converted from block or stream ciphers (DM-PRESENT and H-PRESENT).

The hardware implementations of these hash functions can be in parallel and serial architecture. However, the hash functions designed for specific hardware in parallel architecture cannot show the advantages of parallelism in general-purpose MCU-based devices. From a software and multi-threading technology perspective, the performance of lightweight hash functions operating on general-purpose devices or distributed systems should be considered. Data parallelism can provide more efficiency and parallelization degrees than task parallelism on lightweight hash functions for IoT devices.

3. The Proposed PLWHF Scheme

A new data-parallel hash function based on a lightweight block cipher is proposed, as shown in Figure 3. A new construction similar to the basic tree construction is built. The lightweight block cipher utilized operates in counter mode (CTR). Other operation modes, such as Cipher Block Chaining (CBC), Propagating CBC, Cipher Feedback (CFB), or Output Feedback (OFB), can not be parallelized. Some operation modes, such as electronic codebook (ECB), can be parallelized, but they are not suitable for lack of diffusion. Initially, the message padding is implemented on the input message to generate fixed-length blocks the same as the digest size of 512 bits and prevent length extension attacks. The padded message is divided into sub-blocks of 64 bits ($m_0$, $m_1$, $m_2$, to $m_n$) because of the block size of the block cipher. Every sub-block is encrypted with the SIMON lightweight block cipher with CTR operation mode in a data-parallel approach. The ciphered sub-blocks (${}^{c}m_i$) are XORed to find the variations that may occur in message blocks. The XORed message is also ciphered to create an intermediate-hash block for diffusion and confusion of any changes in the i-th message block. The intermediate-hash block is XORed with each ciphered sub-block to apply the diffusion and confusion to the entire block. These blocks can be used as a hash value if the message consists of one block. If the message consists of more than one block, the addition operation is applied between these ciphered blocks sequentially for mixing and compression, which must be in serial processing. In this way, the hash value is obtained as a result of parallel and a few serial operations.

The mixing and compression process in the proposed hash function incorporates a sequential addition step to ensure cryptographic integrity and collision resistance. While parallelism is effectively utilized in the encryption and XOR steps to enhance performance, a fully parallel addition step could compromise the proper diffusion of bits and the avalanche effect, which are critical for a secure hash function. The final sequential step plays a crucial role in securely combining intermediate results, ensuring that even small changes in the input propagate effectively throughout the hash computation. This hybrid approach balances parallel processing efficiency with secure cryptographic operations, maintaining both performance scalability and strong security properties.

According to Amdahl’s Law, the scalability of the proposed system is inherently limited by its sequential components. While the final addition step is performed sequentially, the primary computational workload—encryption and XOR operations—is efficiently parallelized, providing a significant speedup in multi-threaded execution. Experimental results indicate that using two threads improves performance by approximately 40% for laptop and 50% for Raspberry Pi 4, while the efficiency gain diminishes with additional threads due to the increasing impact of the parallel overhead. This trend continues for four or more threads, where parallelization benefits gradually plateau. The impact of parallelization on system performance is further illustrated and discussed in Section 4.

In the parallel implementation of the hash function, the following OpenMP directive is used to manage the parallel execution of XOR operations on blocks of data: #pragma omp parallel for shared(blocks_ciphertext, blocks_plaintext, k, Nonce) private(i) schedule(dynamic, NUM_BLOCK/NUM_THREADS). To manage shared variables such as intermediate hash blocks during parallel XOR steps, the following approach is applied.

Shared variables such as blocks_ciphertext, blocks_plaintext, k and Nonce are shared among all threads. These variables are constant across threads, ensuring that all threads can access and modify them during the parallel execution. Sharing allows the threads to operate on the same dataset simultaneously without unnecessary data duplication. The loop index i is private to each thread. This means that each thread has its own copy of the index i, preventing conflicts and ensuring proper loop execution without data contention across threads. The schedule(dynamic, NUM_BLOCK/NUM_THREADS) directive dynamically assigns chunks of blocks to threads. This ensures an approximately equal distribution of blocks among threads, helping to balance the workload. Threads with less work can be assigned additional blocks, while threads with heavier tasks can handle fewer blocks. This dynamic load balancing improves efficiency, particularly when there is variability in the work done by each thread.

Figure 4 shows the block cipher scheme, which operates in CTR mode. An increment-by-one counter is usually used in CTR mode to produce different values with the same data. However, it is not suitable for parallel processing. The nonce value is calculated by multiplying the block index by ten and adding the sub-block index for parallel processing. The nonce value is ciphered instead of plaintext, and the nonce value is recalculated for the next operation. The ciphered message is XORed with plaintext to create the ciphertext. The round function of the SIMON cipher consists of AND, circular shift and XOR operations, which is the two-stage Feistel map. The message is partitioned into two words of subcipher ($X_{i+1}$ and $X_i$), and different processes are applied to the branches and affect each other. The left subcipher is circularly shifted by 1 bit and 8 bits before the AND operation. The result of the AND operation and 2-bit shifted left word of subcipher is XORed with the right word of subcipher. Then, the round keys are XORed with the right branch. The obtained right and left words of subciphers are swapped.

The nonce is incremented based on the block index with sub-block, encrypted and then used in the hashing process. This approach ensures that repeated blocks produce distinct intermediate ciphertexts due to the varying nonce values. However, when the same input message is processed multiple times, the resulting hash remains unchanged because the overall encryption sequence is deterministic. Consequently, while block-level uniqueness is achieved, the hash output remains consistent at the message level. Additionally, the nonce acts similarly to a salt, as it is combined with the message itself using an XOR operation before being fed into the hash function. This ensures that even if two different messages contain blocks with the same encrypted nonce value, the final outputs remain distinct due to their unique message-dependent transformations. It is computationally infeasible to reverse-engineer the original blocks from the 512-bit hash output due to the nature of the operations involved. The design ensures that, even with a potential collision in nonce values, the resulting hash values for different messages remain distinct. The proposed method provides an efficient structure suitable for parallel computation while minimizing inter-block dependencies. To prevent synchronization issues between blocks in parallel execution, the nonce value is securely incremented using the #pragma omp critical directive. This ensures that race conditions in multi-core systems are avoided, maintaining correct nonce values across all threads.

The PLWHF structure is depicted in Algorithm 1. The input message is partitioned into a 512-bit fixed size, and each message block is divided into eight sub-blocks of 64 bits. The 64-bit sub-blocks are stored in a two-dimensional array with 32-bit words, which states the plaintext. Each sub-block is encrypted with the SIMON block cipher with CTR mode in a data-parallel approach. The nonce value is calculated in a critical section to prevent race conditions, and the encryption process can be parallel. The i-th intermediate-hash block is created by XORing these encrypted messages and also encrypted with the SIMON block cipher in parallel. Also, assignment operations for shared variables must be performed atomically to avoid race conditions in parallel loops. The obtained intermediate-hash block is XORed with encrypted message sub-blocks in parallel. The values generated through this process are subsequently combined through addition to produce the hash value, which is performed sequentially.

To evaluate the impact of sub-block size on performance, some tests are conducted by using 64-bit and 32-bit sub-block configurations. The results demonstrate that while security and memory usage remain nearly identical due to the 512-bit general block structure, processing speed differs significantly. The 32-bit sub-block processing time is approximately 1.8 to 2 times slower than the 64-bit sub-block processing across different input sizes. For instance, as the input size increases, the processing time for the 32-bit configuration is consistently around twice that of the 64-bit configuration. This slowdown results from the increased number of iterations required when using smaller sub-blocks, leading to higher computational overhead. Given that security and memory consumption remain unchanged, while the 64-bit sub-block structure offers significantly better processing efficiency, it is the preferred approach for IoT environments where computational efficiency is critical.

Algorithm 1 Hash Function

$\mathbf{Input}:M_1,M_2,\dots ,M_t;$ $M_i=(m_0^{64}\left|\right|m_1^{64}\left|\right|\dots \left|\right|m_r^{64});$ $r=0,1,\dots ,(digest/64)$ $\mathbf{Parallel}\mathbf{for}i=0totdo$ $\mathbf{for}j=0tordo$ ${}^{E}m_i^j\leftarrow SIMONcipher(Nonce,Key)\oplus m_i^j$ $Nonce=(i\ast 10)+j$ $\mathbf{end}$ $\mathbf{end}$ $\mathbf{Parallel}\mathbf{for}i=0totdo$ $\mathbf{for}j=0tordo$ $IntermediatehashBloc{k}_i\leftarrow IntermediatehashBloc{k}_i\oplus {}^{E}m_i^j$ $\mathbf{end}$ ${}^{C}IntermediatehashBloc{k}_i\leftarrow SIMONcipher(IntermediatehashBloc{k}_i,Key)$ $\mathbf{end}$ $\mathbf{Parallel}\mathbf{for}i=0totdo$ $\mathbf{for}j=0tordo$ ${}^{C}m_i^j\leftarrow {}^{C}IntermediatehashBloc{k}_i\oplus {}^{C}m_i^j$ $\mathbf{end}$ $\mathbf{end}$ $\mathbf{for}i=0totdo$ $\mathbf{for}j=0tordo$ $Has{h}_i\leftarrow Has{h}_i+{}^{C}m_i^j$ $\mathbf{end}$ $\mathbf{end}$

The description of the SIMON round function is shown in Equations (1) and (2), which is based on the Feistel structure. The x and y are 32-bit words of subcipher that state the message sub-blocks. A circular left shift ($S^i$) by i bits is used in the f function. The f function describes that shifted 1-bit and 8-bit x processed AND operation and is XORed with 2-bit shifted x. The y word, f function and round key (k) are XORed, and a swap is applied on subcipher words. The round key ($k_i$) generation is described in Equation (3), which defines four-word key expansions. The key expansion function consists of 44 rounds and uses a constant sequence ($z_j$) for $m=4$. The round count and constants $z_j$ play an important role in the cryptographic strength of the SIMON cipher. The constants $z_j$ are introduced to provide additional non-linearity to the key schedule, helping to resist cryptanalysis and ensuring the security of the cipher. The key expansion function is designed to provide a high degree of diffusion and non-linearity. It consists of 44 rounds, and the key is expanded using XOR operations, bit shifts and bitwise complements. This guarantees that each round key is sufficiently independent, contributing to the cipher’s resistance against cryptanalytic attacks.

(1)$R_k(x,y)=\left(y\oplus f\left(x\right)\oplus k,x\right)$

(2)$f\left(x\right)=\left(S^{1}x\&S^{8}x\right)\oplus S^{2}x$

(3)$k_{i+m}=c\oplus {\left(z_j\right)}_i\oplus k_i\oplus \left(I\oplus S^{-1}\right)\left(S^{-3}{k}_{i+3}\oplus k_{i+1}\right)$

The message padding procedure is shown in Algorithm 2, namely Merkle’s padding rule. The size of the message needs to be a multiple of block size, which is 512 bits for our hash function. The padding bits are added to the message text when a smaller size of a message is given. A single bit 1 is added at the beginning of padding, and a binary representation of message size is added to the end. The remaining space is filled with zero values.

Algorithm 2 Padding Technique

$\mathbf{Input}:Message\left(M\right),BlockSize\left(B\right)$ $\mathbf{Output}:sizeof\left(\mathbf{pad}\left(M\right)\right)ismultipleofB$ $le{n}_s\left(M\right)isthesbitbinaryexpressionofthemessagelength$ $P=modB$ $\ast =P-1-sizeof\left(le{n}_s\left(M\right)\right)$ $\mathbf{pad}\left(M\right)=M\left|\right|1\left|\right|0^{*}\left|\right|le{n}_s\left(M\right)$

4. Security and Performance Analysis

The characteristics of the proposed hash function PLWHF have been evaluated based on six criteria: sensitivity and distribution of hash value, collision resistance, confusion and diffusion analysis, and efficiency analysis. The C++ programming language was used in Microsoft Visual Studio for coding PLWHF, and it was implemented on a 64-bit Intel i7-7700HQ 2800MHz with 16 GB of RAM hardware on the Windows 10 Pro platform. Additionally, the hash function was tested on a Raspberry Pi 4, with an ARM Cortex-A72 quad-core processor, for IoT applications. The proposed hash function was evaluated against other lightweight hash functions in terms of execution time for different message sizes, including results from both the laptop and Raspberry Pi platforms.

4.1. Sensitivity of Hash Value

A hash function should be sensitive to minor changes in the message text. The sensitivity of the PLWHF output is simulated under six conditions to observe the changes in the hash value generated due to minor changes in the original text message. The sensitivity test is performed with a 512-bit digest size for the proposed hash function on an original text message given in condition one from reference [77].

Condition 1: The original message is, “A fine, well-ordered, well-crafted work like a palace self-evidently points to a well-ordered act. And a fine, well-ordered act necessarily points to a proficient agent, a skillful master, a builder”.

Condition 2: The first letter of the original message has been changed from “A” to “E”.

Condition 3: The word “work” is replaced with “fork”.

Condition 4: In the second sentence, the character f in “fine” is written with a capital letter as “Fine”.

Condition 5: The additional number “3” is attached to the end of the original message.

Condition 6: The dot “.” at the end of the original message is changed to an exclamation mark “!”

The corresponding hash values in the hexadecimal format are given to observe the sensitivity of the proposed PLWHF with a digest size of 512 bits:

• Condition 1: DDC79747211E4F15AD0E353C1F93DCBBB989F0047053F6782F6EBB189AFA21BA6A6DA56882BCB306DE7ED513E9B7ACF676B9DBC872535916F3829A2D3FA98920

• Condition 2: 49082166C5E3D586FD4EA31BFB0D2F28E8CA9E2564FD62E7DEAF00F7204F7D4D39AF4F87F7EE4E93CEC07F3464F6086786F961A9B734D3A7A2C1400E9C7705B3

• Condition 3: 3C65C1ACFB73037E0E6C0365447EA110D62BBD6B976EB10FCFD062C175E16F2548CFEEBEAE5F805BBFDD1DFA1364FA4F985B7FDF89A6A56F942461C46706D38B

• Condition 4: 07D9A6494D54E0F5C2F826360B5A76DB7BABFEFE8C9A74580534EA1A7F41BBDA387B7462AF032526AC68E60DD57042D658B7EACE5E0CE2F621A0C92F23710700

• Condition 5: EB00B346F7CD44D60847593F85C2EAFEC6C2D407C825103540A7DF17C3C92B797FB4C167EC8BF0C9D537B112FFE88EA98072FFCB0A248ED3E24B763017D87F63

• Condition 6: D6E00CF5D684263CB3E79F8EAC7E055522E38DF605BE2EDE24C754A6E64FC9E0A394175619E68B2079585AE13A9175102C9259DAC3B9B07C8E2C105FEE536202

The 512-bit binary representations of the hash values under six different conditions are illustrated as a heatmap in Figure 5. The heatmap clearly shows that the proposed PLWHF exhibits high sensitivity to any modifications in the original text message, with significant bit changes observed across different input variations.

4.2. Statistic Analysis

A cryptosystem should have confusion and diffusion properties to obstruct statistical attacks, as described by Claude Shannon [78]. The definition of diffusion is minor changes in plaintext that should change most of the ciphertext, and this change should spread over the entire data randomly. The description of confusion covers up the relation between the ciphered message and the key used. In a good hash function, variation in the hash value due to any bit changes in the input message or the assigned key should be $50\%$ probability. Usually, the evaluation of confusion and diffusion is performed according to the following four statistical metrics:

Number of average bit change:

$B_{\mathrm{c}}={\displaystyle \frac{1}{N}}\sum _{i=1}^N{H}_i$

Percentage of bit change:

$R_{\mathrm{c}}={\displaystyle \frac{B_{\mathrm{c}}}{n}}\times 100\%$

Standard deviation of bit change:

$\mathsf{\Delta }{B}_{\mathrm{c}}=\sqrt{{\displaystyle \frac{1}{N-1}}\sum _{i=1}^N{\left(H_i-B_{\mathrm{c}}\right)}^2}$

Standard deviation of $R_{\mathrm{c}}$:

$\mathsf{\Delta }{R}_{\mathrm{c}}=\sqrt{{\displaystyle \frac{1}{N-1}}\sum _{i=1}^N{\left({\displaystyle \frac{H_i}{n}}-R_{\mathrm{c}}\right)}^2}\times 100\%$

Initially, 1000 random text messages are generated with a pseudorandom number generator known as Mersenne Twister (MT19937) and produce the resultant hash values. Subsequently, a random bit on the original message is changed, and the hash value of the resulting new message is generated. Table 2 shows the variation in the generated hash values, and additional parallel hash functions are attached for benchmarking. The average number of bit changes and the probability of bit change characteristics are achieved by the optimum value of $50\%$ for PLWHF. It is good to have a small standard deviation to hold the bit changes in the intended scale. The proposed PLWHF has a lower standard deviation than other 512-bit similar hash functions and has a good proportional value concerning digest size compared to other hash functions. The average of changed bits and percentage of bit change performance provide the desired values.

Figure 6 illustrates the distribution of changed bit numbers of the proposed hash function. The distribution of changed bit numbers has emerged as a result of the 1000 samples’ average. The number of bit changes varies in a range close to 256, which is the optimum value for the 512-bit digest size. The i-th changed bit or the count of samples does not affect the change in bit count. Figure 7 shows the statistical histogram of changed bit numbers, and it is similar to the normal distribution, which is the desired data distribution. The frequency of values near the mean increases, but the frequency of values far from the mean decreases symmetrically.

4.3. Distribution of Hash Values

The distribution of characters in the hash value is expected to be equal. If it is not distributed uniformly, it can create a weakness against pre-image or second pre-image attacks. The first pre-image or second pre-image of the hash value can be obtained with a simple method: brute-force attack or some other faster pre-image attack specific to the hash functions as a consequence of cryptanalysis. Figure 8 illustrates the frequency distribution of the hash value as a result of 1000 randomly generated messages. Hash values corresponding to random messages are represented in hexadecimal format, and the frequency distribution of characters (0 to F) is obtained. The created 128,000 characters need to be distributed in equal numbers. Pearson’s chi-squared test (Equation (4)) is used to determine the distribution of the PLWHF value. To evaluate the uniformity of the hash values, 1000 input messages are generated randomly and, if the hash values have a uniform distribution, it is expected that each hexadecimal character amount ($E_i$) will equal 8000, which is one-sixteenth of the total value. The observed values vary between 7829 and 8140 ($O_i$) according to the results of the performed test. Pearson’s cumulative test statistic ($X^2$) is obtained as 19.89, which means the probability is less than the critical value at 90% or higher significance levels. As a result of the test, it is seen that the null hypothesis ($H_0$) is true, which means the suggested PLWHF value has a uniform distribution.

(4)$X^2=\sum _{i=1}^{16}{\displaystyle \frac{{(O_i-E_i)}^2}{E_i}}$

The change in the hash value resulting from any bit change is required to be 50% probability. Also, it is desired that the distribution of changing bits at each location index needs to be uniform. Figure 9 plots the distribution of bit changes at a particular location index of the 512-bit hash value. The distribution of toggled bit numbers in a location index is correlated to the avalanche effect of the proposed PLWHF. One thousand random messages have been generated, and the resultant hash values are produced. Bit changes in the location index of the hash space have been observed. The toggled bit number at each location varies from 435 to 545, and the average value is 499.93, which requires 500 changes at each location. Pearson’s chi-squared test is used to determine the distribution of changing bits at each location index. Pearson’s cumulative test statistic is calculated as 236.95, which means the probability is less than any critical value for an alpha level. The suggested PLWHF has achieved the variance test, and the distribution of changing bits at each location index has a uniform distribution as a consequence.

4.4. Collision Resistance

Collision means that two different messages generate the same hash value. Collision resistance is one of the primary attributes of hash functions. It is supposed that collisions are unavoidable in probabilities with huge sample spaces, but this collision should be as difficult as possible. Due to the enormous sample size, which is $2^{512}$, testing all possible hash values is practically impossible. Wong [64] suggested a more applicable method for measuring the collision resistance of hash functions rather than testing all possibilities. This method tries to find the same values at the same location in the two hash outputs resulting from the bit changes, thus allowing us to predict the probability of completely producing the same hash. Also, 2000 random input messages and the resultant hash values are created, which are represented in ASCII format. The bit at an arbitrary position in the input message is changed, and the corresponding hash value is also generated. According to Wong’s method, the number of the same two hexadecimal characters is counted at the same location ($N_s$), which is desired to be as small as possible. Table 3 shows the number of equal entries that are acceptable when compared to other conventional parallel hash functions. It should be taken into account that, if the digest size increases, the probability of finding an equal entry should also increase.

Furthermore, the absolute difference in the generated hash values is calculated according to Equation (5), which refers to the distance between two ASCII characters ($d_{hash}$) in the same location resulting from the change. The comparison for the parameters of the absolute difference is given in Table 4. The maximum, minimum and mean values of $d_{hash}$ are listed from the set of absolute difference values. The average of the absolute difference ($d_{avr}$) is calculated as dividing the mean value by the same two hexadecimal characters. It is desired that the variation value of the absolute difference is small and the average of the absolute difference is close to 85.33. The 512-bit variant of PLWHF outperforms the other hash function and shows better results than most hash functions with smaller digest sizes, such as 256-bit and 128-bit, demonstrating enhanced stability and robust collision resistance.

(5)$d_{hash}=\sum _{i=1}^{64}\left|dec\left(z_i\right)-dec\left({\tilde{z}}_i\right)\right|$

4.5. Software Efficiency Analysis

A lightweight cryptographic hash function should not have too much processing load and thus have a low operating time while providing the necessary security requirements. A comprehensive performance efficiency test is conducted by comparing the running time of PLWHF with other lightweight hash functions, including Photon-256, Quark-256, Lesamnta-256, SPONGENT-256, SipHash-64, Keccak-512, and BLAKE-512, using a single-threaded configuration. The execution time required to generate the hash value of given messages with various sizes (1 KB to 1 MB) is calculated by the average of 1000 samples. Hardware-oriented hash functions such as SPONGENT, Quark, Lesamnta and Photon have long running times. Sponge-based algorithms, such as SPONGENT and Photon, exhibit long execution times primarily due to the high computational cost of their inner loops. The SPONGENT, Quark and Photon lightweight cryptographic hash functions use sponge construction, and Lesamnta is based on the Merkle–Damgard structure. SipHash has a median running time, which is based on JH-style T-Sponge construction. The software implementation of reduced Keccak, also based on sponge construction, is close to the average running time. The BLAKE implementation has almost the same running time as the proposed hash function, slower for small message sizes and a bit faster for large message sizes, as shown in Figure 10.

PLWHF uses the SIMON block cipher, which is designed to maintain high software performance and is well suited to data-parallel operations. Consequently, PLWHF outperforms nearly all the evaluated lightweight hash functions when using a single thread. Experimental results show that PLWHF outperforms BLAKE for smaller data sizes (under 50 KB), while BLAKE demonstrates superior performance for larger data sizes due to its use of the ChaCha permutation, which is optimized for high throughput on large data. In contrast, PLWHF, based on block cipher encryption, experiences slower performance as message sizes increase. However, BLAKE has a more complex internal structure and higher memory consumption. Nevertheless, PLWHF consistently outperforms all other tested algorithms, achieving at least 20% better performance across all data sizes. This emphasizes the trade-off between BLAKE’s higher memory usage and PLWHF’s lightweight design, which is better suited to memory-constrained IoT environments. PLWHF’s design, optimized for smaller devices, ensures lower memory consumption while maintaining competitive performance for smaller data sizes.

Figure 11 shows the effect of the parallelization technique on performance efficiency, which is the comparison of speed values for different numbers of threads. The Open Multi-Processing (OpenMP) [84] application programming interface (API), a parallel programming framework for C, C++ and Fortran, is used. The parallelization of the proposed hash function ensures a speedup of approximately 40% for two threads and roughly 50% for three threads. Parallel efficiency depends on the ratio of the parallel and sequential sections of the software implementation. Combining intermediate hashes should be performed in sequential mode, and all other steps can be computed in parallel. It should be noted that access to shared variables must be performed atomically. Atomic assignments and sequential sections are the factors that determine parallel performance. Also, the chunk size of the scheduling mechanism is calculated as the number of blocks divided by thread count, and iterations perform dynamically. Compared to other lightweight hash functions, it can be seen from Figure 11 that the PLWHF will have higher performance efficiency when the degree of parallelization increases. In addition, the suggested PLWHF can reach much higher parallelization degrees.

The performance improvement of approximately 40% with two threads and 50% with three threads can be attributed to the efficient distribution of computational tasks across multiple threads. In the provided OpenMP code, the #pragma omp parallel for directive ensures that loop iterations are distributed dynamically across threads. The schedule(dynamic, $NUM\_BLOCK$/$NUM\_THREADS$) clause allows work to be divided into chunks, and each thread dynamically picks up a chunk of work. This dynamic scheduling helps balance the workload among threads, even though the processing time for each block is generally uniform.

As for the performance impact of adding more threads, the theoretical scaling benefits decrease as the number of threads increases due to several factors. First, there is increased synchronization overhead. With more threads, the need for synchronization, especially for accessing shared variables such as $blocks\_ciphertext$, $blocks\_plaintext$ and $Nonce$, becomes more significant. Each thread must ensure that data is updated correctly, which introduces delays and reduces the potential benefits of parallelism. Second, contention for shared resources also increases as the number of threads grows. This higher contention for memory or caches can lead to inefficient memory accesses and increased cache misses, further reducing performance. Additionally, with more threads, there is a risk of load imbalance. While dynamic scheduling helps distribute tasks, a higher number of threads could lead to situations where certain chunks take significantly more time to process, reducing the overall efficiency of parallel execution.

Therefore, beyond a certain threshold, adding more threads results in diminishing returns due to the increased cost of synchronization, resource contention and potential load imbalances. This is why performance improvement tends to plateau or even decline with the use of many threads.

The performance of the developed PLWHF algorithm is evaluated on a Raspberry Pi 4 (ARM Cortex-A72, 64-bit, quad-core), with varying input sizes and numbers of threads. The results shown in Figure 12 represent the average processing time from 1000 tests conducted for each configuration. The Raspberry Pi 4, with an ARM Cortex-A72 quad-core processor, more accurately reflects the type of hardware typically used in IoT applications, thus strengthening the relevance of the results for IoT applicability. The tests reveal that processing time decreases as the number of threads increases, demonstrating the effectiveness of parallel processing. For smaller input sizes (1 KB and 10 KB), the performance improvement is moderate. For instance, when transitioning from a single thread to two threads, the processing time decreases by approximately 40% for 1 KB (from 0.125 ms to 0.075 ms) and by 44% for 10 KB (from 1.210 ms to 0.680 ms). As the input size increases, the improvement becomes more pronounced. For 500 KB, the processing time is reduced by approximately 45% when going from one thread (60.780 ms) to two threads (33.580 ms), and by nearly 63% when moving from one thread to four threads (17.660 ms).

In addition to the reported results, it is crucial to account for the parallel overhead associated with multi-threading. While the parallelizable components of the algorithm benefit from increased thread utilization, factors such as thread creation, atomic operation latency and thread synchronization introduce inefficiencies that directly impact the overall performance. As the number of threads increases, the efficiency gains diminish. For instance, moving from one thread to two threads results in a performance improvement of approximately 45%, but the improvements decrease to around 25% when increasing from two threads to four threads. Beyond four threads, the performance improvement plateaus or even decreases, as the Raspberry Pi 4’s quad-core CPU reaches its capacity for parallel processing, limiting the effectiveness of adding more threads. Furthermore, the choice of chunk scheduling strategy in the OpenMP implementation (static vs. dynamic) directly impacts performance, particularly with varying input sizes. In this experiment, dynamic chunk scheduling was used, which effectively reduced idle times and ensured a balanced workload distribution across threads, especially when processing larger input sizes.

These results indicate that the PLWHF algorithm benefits greatly from the multi-threading capabilities of the Raspberry Pi 4, with substantial performance gains for larger input sizes. The scalability of the algorithm is influenced by the balance between its parallel and sequential components. While parallel sections show significant improvements with more threads, the sequential parts of the algorithm limit the overall scalability, particularly for smaller input sizes where the sequential portion takes up a larger proportion of the total processing time. This trade-off is typical in many algorithms, and future optimizations will focus on improving both the parallel and sequential sections to maximize performance on multi-core systems such as the Raspberry Pi 4.

5. Conclusions

In this study, a data-parallel hash function based on a lightweight block cipher is developed for IoT devices. The proposed hash function, PLWHF, is designed with lightweight features to accommodate the resource constraints typical of IoT devices. Additionally, PLWHF utilizes a data-parallel architecture to provide higher parallelization and to fully exploit the potential of multi-core processors or distributed systems, leading to minimized resource usage and improved throughput. The hash function employs the SIMON block cipher, which allows for the efficient implementation of data parallelism on input messages.

The PLWHF meets the same security requirements as other widely accepted hash functions, including sensitivity, distribution of hash values, statistical analysis and collision resistance. Its software implementation outperforms other hash functions in terms of speed, even with a single thread. The parallelization of PLWHF results in a performance improvement of 38–41% with two threads and 49–53% with three threads on the laptop. In the IoT application tests performed on Raspberry Pi 4, the parallelization of PLWHF demonstrated varying degrees of performance improvement across different data sizes. For instance, with a single thread, the execution time for smaller data sizes, such as 1 KB and 10 KB, is 0.125 ms and 1.21 ms, respectively. For two threads, performance improved with execution times of 0.075 ms for 1 KB and 0.68 ms for 10 KB. With three threads, the performance boost became more significant, with execution times of 0.059 ms for 1 KB and 0.47 ms for 10 KB. The trend continued with larger data sizes (e.g., 200 KB and 500 KB), where the speedup was evident, but the improvement plateaued as the number of threads increased, showing diminishing returns beyond four threads. These results confirm that the PLWHF is well suited to IoT devices, where resource constraints are critical, and its performance scales well with the number of threads in multi-core environments, showing particularly noticeable improvements for larger message sizes.

The lightweight hash functions proposed in this study not only offer significant advantages for IoT devices but also have the potential to contribute to a broader range of applications. For instance, they could be applied to secure and efficient authenticated key management schemes in UAV (Unmanned Aerial Vehicle)-assisted infrastructureless IoV (Internet of Vehicles) networks. Such networks operate in dynamic environments with limited infrastructure, where lightweight hash functions can enable fast and secure key management. Similarly, the proposed hash functions could be effectively used in vehicle-assisted aggregate authentication schemes for infrastructureless vehicular networks. These networks, lacking centralized infrastructure, require efficient and secure authentication methods that can be provided by lightweight and fast algorithms. Additionally, lightweight hash functions could be integrated into end-to-end data authentication deep learning models to secure IoT configurations. In decentralized and dynamic environments, ensuring data security, particularly in terms of data integrity and authentication, is of critical importance.

In future work, the hardware implementation of PLWHF on other platforms will be explored, along with cryptanalysis to further evaluate its security, including formal security proofs against SIMON-specific vulnerabilities. Additional performance factors, such as power consumption, will also be taken into account to assess the energy efficiency of PLWHF in resource-constrained IoT environments. Further testing of PLWHF in cloud applications will provide valuable insights into its scalability and efficiency across various environments. Moreover, the digest size of the hash function can be adjusted to 256 bits or 128 bits by modifying the SIMON cipher block size, allowing for greater flexibility and optimization for different use cases, particularly for low-memory IoT nodes. Future optimizations will focus on enhancing both the parallel and sequential sections of PLWHF to maximize performance on multi-core systems, such as the Raspberry Pi 4. This will also be explored in future experiments to better understand the impact of chunk scheduling on the scalability of the PLWHF algorithm.

Data Availability Statement

The data that support the findings of this study are available on request from the corresponding author. The data are not publicly available due to privacy or ethical restrictions.

Conflicts of Interest

The author declares no conflicts of interest.

Footnotes

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Figures and Tables

Figure 1. Hash function in IoT application.

Figure 2. Basic hash properties.

Figure 3. The general structure of the proposed hash function.

Figure 4. The SIMON block cipher with CTR mode.

Figure 5. The sequences of the bit binary presentations under six conditions.

Figure 6. Distribution of changed bit numbers.

Figure 7. Statistical histogram of changed bit numbers.

Figure 8. Frequency distribution of hash value.

Figure 9. The variance in bit location index.

Figure 10. Comparison of running times.

Figure 11. Comparison of running times for various threads.

Figure 12. Multi-threading performance on Raspberry Pi 4.

Table 1

Summary of related work.

Study	Approach	Key Contribution and Limitation
Yang et al. [20]	Lattice-based cryptography	Collision resistance and parallel iterative hash structure. High computational complexity for IoT devices.
Wang et al. [21]	Coupled map lattices	Chaotic-based parallel hash function. Limited scalability.
Li and Ge [22]	Cross-coupled map lattices	Parallel hash for multimedia security. Increased memory overhead.
Zhang et al. [23]	Parallel hash with variable rotation values	Improved security with chaining variables. Computationally expensive.
Akhavan et al. [24]	3D Trigonometric chaotic maps	Enhanced randomness. Requires significant processing power.
Li et al. [25]	Piecewise linear and chaotic asymmetric tent maps	Iterations with changeable parameters. Complexity makes hardware implementation challenging.
Teh et al. [26]	Multiple chaotic maps	New shuffling mechanism for hashing speed. Single variant of the baseline network was utilized for the prototype.
Abdelfatah et al. [27]	Tent map, logistic map, sine function and diamond lattice	Chaotic map-based security. High dependency on chaotic system stability.
Xiao et al. [28]	Chaotic neural network	Novel approach to chaotic parallel hashing. High training complexity.
Nouri et al. [29]	Chebyshev–Halley type methods	Variable parameter-based parallel hashing. Difficult implementation in lightweight devices.
Kishore et al. [31]	Enveloped Inverted Tree Recursive Hashing (EITRH)	Improved execution time of hash functions. Scalability issues.
Han et al. [32]	GPU-based authenticated encryption	High-throughput hashing for IoT. Limited to GPU environments.
Liu et al. [33]	HAIFA iterative structure with Lorenz chaotic system	Secure parallel hash function. Not optimized for lightweight IoT devices.
Bhoyar et al. [46]	FPGA/ASIC implementation of Simeck	Lightweight hardware implementation. Requires specialized hardware.
El-Hadedy et al. [47]	PRO-GAGE processor	Embedded device hashing optimization. Limited flexibility for software applications.
Windarta et al. [48]	Saturnin block cipher (sponge-based)	Secure lightweight sponge-based hashing. Performance trade-offs.
Mahmoud et al. [49]	RNS-ABE with fog computing	Fine-grained lightweight access control. Added complexity due to encryption integration.
Achar et al. [50]	LiteHash (SHA-512-based)	Approximate computing for lightweight hashing. Reduces computational cost at potential security trade-offs.

Table 2

Comparison for statistical analysis of hash functions.

Parameters	${\mathit{B}}_{\mathit{c}}$	Avr. ${\mathit{B}}_{\mathit{c}}$	${\mathit{R}}_{\mathit{c}}$ (%)	$\mathbf{\Delta }$  ${\mathit{B}}_{\mathit{c}}$	$\mathbf{\Delta }$ ${\mathit{R}}_{\mathit{c}}$ (%)
PLWHF	225–290	256.09	50.01	10.87	2.12
SHA3 [79]	221–288	255.82	49.96	11.08	2.16
Whirlpool [80]	206–294	256.00	50.00	11.23	NaN
PLHF [20]	91–168	127.91	49.96	8.93	3.49
Ref. [23]	NaN	127.91	49.96	5.35	2.09
Ref. [27]	104–149	128.62	50.24	7.57	2.95
Ref. [81]	65–96	80.11	50.07	3.79	NaN
Ref. [26]	46–86	64.12	50.09	5.72	4.42
Ref. [21]	47–80	64.00	50.00	5.67	4.43
Ref. [29]	49–80	64.14	50.11	4.39	3.37
Ref. [22]	47–79	64.05	50.04	5.27	4.12
Ref. [24]	45–82	63.83	49.87	5.86	4.50
Ref. [30]	NaN	64.11	50.09	5.53	4.33
Ref. [28]	NaN	64.26	50.21	5.78	4.52
Ref. [25]	NaN	63.64	49.72	8.02	6.27

Table 3

The number of the equal entries at the same location in a hash value.

Number of Equal Characters	0	1	2	3	4	Digest Size
PLWHF-512	1574	395	29	2	0	512
Ref. [82]	1607	371	67	3	0	512
Ref. [27]	1809	224	14	0	0	256
Ref. [83]	1820	214	12	0	0	256
Ref. [30]	1924	120	4	0	0	128
Ref. [22]	1930	117	2	0	0	128
Ref. [28]	1925	120	2	0	0	128

Table 4

The absolute difference results.

	Size Output	${\mathit{N}}_{\mathit{s}}$ (Max)	${\mathit{D}}_{\mathit{hash}}$ (Max)	${\mathit{D}}_{\mathit{hash}}$ (Min)	${\mathit{D}}_{\mathit{hash}}$ (Mean)	${\mathit{D}}_{\mathit{avr}}$
PLWHF	512	3	6961	3850	5467	85.43
SHA3 [79]	512	3	7106	3933	5502	85.97
PLHF [20]	256	1	4096	1364	2731	85.34
KECCAK [20]	256	2	4105	1368	2733	85.40
Ref. [23]	256	2	3602	1777	2731	85.36
Ref. [27]	256	2	4079	1474	2733	85.41
Ref. [25]	128	2	2221	514	1367	85.47
Ref. [26]	128	1	2390	575	1379	86.18
Ref. [21]	128	2	2064	655	1367	85.44
Ref. [29]	128	2	2243	678	1579	98.68
Ref. [22]	128	2	2019	688	1350	84.38
Ref. [30]	128	2	2156	658	1431	89.45
Ref. [28]	128	2	1952	605	1227	76.73

References

1. Borgia, E. The Internet of Things vision: Key features, applications and open issues. Comput. Commun.; 2014; 54, pp. 1-31. [DOI: https://dx.doi.org/10.1016/j.comcom.2014.09.008]

2. Wang, C.; Daneshmand, M.; Dohler, M.; Mao, X.; Hu, R.Q.; Wang, H. Guest Editorial-Special issue on internet of things (IoT): Architecture, protocols and services. IEEE Sens. J.; 2013; 13, pp. 3505-3510. [DOI: https://dx.doi.org/10.1109/JSEN.2013.2274906]

3. Abed, S.; Jaffal, R.; Mohd, B.J.; Al-Shayeji, M. An analysis and evaluation of lightweight hash functions for blockchain-based IoT devices. Clust. Comput.; 2021; 24, pp. 3065-3084. [DOI: https://dx.doi.org/10.1007/s10586-021-03324-1]

4. Bhoyar, P.; Sahare, P.; Dhok, S.B.; Deshmukh, R.B. Communication technologies and security challenges for internet of things: A comprehensive review. AEU-Int. J. Electron. Commun.; 2019; 99, pp. 81-99. [DOI: https://dx.doi.org/10.1016/j.aeue.2018.11.031]

5. Jebrane, J.; Lazaar, S. ILAPU-Q: An Improved Lightweight Authentication Protocol for IoT Based on U-quark Hash Function. Recent Adv. Comput. Sci. Commun. (Former. Recent Patents Comput. Sci.); 2024; 17, pp. 78-87. [DOI: https://dx.doi.org/10.2174/0126662558274597231204114801]

6. Tanrıverdi, M. Design and Implementation of Blockchain Based Single Sign-On Authentication System for Web Applications. Sak. Univ. J. Comput. Inf. Sci.; 2020; 3, pp. 343-354. [DOI: https://dx.doi.org/10.35377/saucis.03.03.757459]

7. Lange, T. Hash-Based Signatures. Encyclopedia of Cryptography, Security and Privacy; Springer: Berlin/Heidelberg, Germany, 2025; pp. 1110-1112.

8. Drake, J.; Khovratovich, D.; Kudinov, M.; Wagner, B. Hash-Based Multi-Signatures for Post-Quantum Ethereum. Cryptol. ePrint Arch.; 2025; preprint

9. Atighehchi, K.; Rolland, R. Optimization of tree modes for parallel hash functions: A case study. IEEE Trans. Comput.; 2017; 66, pp. 1585-1598. [DOI: https://dx.doi.org/10.1109/TC.2017.2693185]

10. El Allam, O.; Alali, A.; Sadik, M.; Elmaaradi, H. Open-source Hardware FPGA Platforms for IoT: Paradigms, opportunities and open issues. Proceedings of the 2023 10th International Conference on Future Internet of Things and Cloud (FiCloud); Marrakesh, Morocco, 14–16 August 2023; pp. 292-297.

11. Rajasekar, P.; Mangalam, H. Design and implementation of power and area optimized AES architecture on FPGA for IoT application. Circuit World; 2020; 47, pp. 153-163.

12. Magyari, A.; Chen, Y. Review of state-of-the-art FPGA applications in IoT Networks. Sensors; 2022; 22, 7496. [DOI: https://dx.doi.org/10.3390/s22197496]

13. Khan, S.; Inayat, K.; Muslim, F.B.; Shah, Y.A.; Atif Ur Rehman, M.; Khalid, A.; Imran, M.; Abdusalomov, A. Securing the IoT ecosystem: ASIC-based hardware realization of Ascon lightweight cipher. Int. J. Inf. Secur.; 2024; 23, pp. 3653-3664. [DOI: https://dx.doi.org/10.1007/s10207-024-00904-1]

14. Nguyen, K.D.; Dang, T.K.; Kieu-Do-Nguyen, B.; Le, D.H.; Pham, C.K.; Hoang, T.T. ASIC Implementation of ASCON Lightweight Cryptography for IoT Applications. IEEE Trans. Circuits Syst. II Express Briefs; 2024; 72, pp. 278-282. [DOI: https://dx.doi.org/10.1109/TCSII.2024.3483214]

15. Ahmad, N.; Zamri, M.H.; Ahmed, S.; Wijayanto, A.; Isaak, S. Design of Advanced Encryption System (AES) Algorithm Using ASIC Implementation for Internet of Things (IoT) Devices. J. Adv. Res. Des.; 2024; 123, pp. 131-145.

16. Singh, S.; Sharma, P.K.; Moon, S.Y.; Park, J.H. Advanced lightweight encryption algorithms for IoT devices: Survey, challenges and solutions. J. Ambient. Intell. Humaniz. Comput.; 2024; 15, pp. 1625-1642. [DOI: https://dx.doi.org/10.1007/s12652-017-0494-4]

17. El-Hajj, M.; Mousawi, H.; Fadlallah, A. Analysis of lightweight cryptographic algorithms on iot hardware platform. Future Internet; 2023; 15, 54. [DOI: https://dx.doi.org/10.3390/fi15020054]

18. Shukla, S.K.; Pant, B.; Viriyasitavat, W.; Verma, D.; Kautish, S.; Dhiman, G.; Kaur, A.; Srihari, K.; Mohanty, S.N. An integration of autonomic computing with multicore systems for performance optimization in Industrial Internet of Things. IET Communications; Wiley: Hoboken, NJ, USA, 2022.

19. Pan, X.; Yang, K.; Li, N.; Zheng, S.; Guo, Q. Research on blockchain architecture for terminal side business applications of distributed iot. Proceedings of the 2024 6th International Conference on Energy, Power and Grid (ICEPG); Guangzhou, China, 27–29 September 2024; pp. 1892-1898.

20. Yang, Y.; Chen, F.; Sun, Z.; Wang, S.; Li, J.; Chen, J.; Ming, Z. Secure and efficient parallel hash function construction and its application on cloud audit. Soft Comput.; 2019; 23, pp. 8907-8925. [DOI: https://dx.doi.org/10.1007/s00500-018-3489-y]

21. Wang, Y.; Wong, K.W.; Xiao, D. Parallel hash function construction based on coupled map lattices. Commun. Nonlinear Sci. Numer. Simul.; 2011; 16, pp. 2810-2821. [DOI: https://dx.doi.org/10.1016/j.cnsns.2010.10.001]

22. Li, Y.; Ge, G. Cryptographic and parallel hash function based on cross coupled map lattices suitable for multimedia communication security. Multimed. Tools Appl.; 2019; 78, pp. 17973-17994. [DOI: https://dx.doi.org/10.1007/s11042-018-7122-y]

23. Zhang, P.; Zhang, X.; Yu, J. A parallel hash function with variable initial values. Wirel. Pers. Commun.; 2017; 96, pp. 2289-2303. [DOI: https://dx.doi.org/10.1007/s11277-017-4298-9]

24. Akhavan, A.; Samsudin, A.; Akhshani, A. A novel parallel hash function based on 3D chaotic map. EURASIP J. Adv. Signal Process.; 2013; 2013, 126. [DOI: https://dx.doi.org/10.1186/1687-6180-2013-126]

25. Li, Y.; Xiao, D.; Deng, S.; Han, Q.; Zhou, G. Parallel Hash function construction based on chaotic maps with changeable parameters. Neural Comput. Appl.; 2011; 20, pp. 1305-1312. [DOI: https://dx.doi.org/10.1007/s00521-011-0543-4]

26. Teh, J.S.; Samsudin, A.; Akhavan, A. Parallel chaotic hash function based on the shuffle-exchange network. Nonlinear Dyn.; 2015; 81, pp. 1067-1079. [DOI: https://dx.doi.org/10.1007/s11071-015-2049-6]

27. Abdelfatah, R.I.; Baka, E.A.; Nasr, M.E. Keyed Parallel Hash Algorithm Based on Multiple Chaotic Maps (KPHA-MCM). IEEE Access; 2021; 9, pp. 130399-130409. [DOI: https://dx.doi.org/10.1109/ACCESS.2021.3113855]

28. Xiao, D.; Liao, X.; Wang, Y. Parallel keyed hash function construction based on chaotic neural network. Neurocomputing; 2009; 72, pp. 2288-2296. [DOI: https://dx.doi.org/10.1016/j.neucom.2008.12.031]

29. Nouri, M.; Safarinia, M.; Pourmahdi, P.; Garshasebi, M.H. The parallel one-way Hash function based on Chebyshev-Halley methods with variable parameter. Int. J. Comput. Commun. Control; 2014; 9, pp. 24-36. [DOI: https://dx.doi.org/10.15837/ijccc.2014.1.867]

30. Xiao, D.; Liao, X.; Deng, S. Parallel keyed hash function construction based on chaotic maps. Phys. Lett. A; 2008; 372, pp. 4682-4688. [DOI: https://dx.doi.org/10.1016/j.physleta.2008.04.060]

31. Kaps, J.P.; Kishore, P.Y.; Surapathi, K.; Habib, B.; Vadlamudi, S.; Gurung, S.; Pham, J. Lightweight Implementations of SHA-3 Candidates on FPGAs. Proceedings of the International Conference on Cryptology in India; Chennai, India, 11–14 December 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 270-289.

32. Han, K.; Lee, W.K.; Hwang, S.O. cuGimli: Optimized implementation of the Gimli authenticated encryption and hash function on GPU for IoT applications. Clust. Comput.; 2022; 25, pp. 433-450. [DOI: https://dx.doi.org/10.1007/s10586-021-03415-z]

33. Liu, G.; Zhou, X.; Liu, Y. Parallel HAIFA Hashing Algorithm Based on Lorenz Chaos. Adv. Comput. Signals Syst.; 2021; 5, pp. 98-106.

34. Badel, S.; Dağtekin, N.; Nakahara, J.; Ouafi, K.; Reffé, N.; Sepehrdad, P.; Sušil, P.; Vaudenay, S. ARMADILLO: A multi-purpose cryptographic primitive dedicated to hardware. Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems; Santa Barbara, CA, USA, 17–20 August 2010; Springer: Berlin/Heidelberg, Germany, 2010; pp. 398-412.

35. Poschmann, A. Lightweight Cryptography- Cryptographic Engineering for a Pervasive World. Ph.D. Thesis; Ruhr-Universität Bochum: Bochum, Germany, 2009.

36. Berger, T.P.; D’Hayer, J.; Marquet, K.; Minier, M.; Thomas, G. The GLUON family: A lightweight hash function family based on FCSRs. Proceedings of the International Conference on Cryptology in Africa; Ifrance, Morocco, 10–12 July 2012; Springer: Berlin/Heidelberg, Germany, 2012; pp. 306-323.

37. Choy, J.; Yap, H.; Khoo, K.; Guo, J.; Peyrin, T.; Poschmann, A.; Tan, C.H. SPN-Hash: Improving the provable resistance against differential collision attacks. Proceedings of the International Conference on Cryptology in Africa; Ifrance, Morocco, 10–12 July 2012; Springer: Berlin/Heidelberg, Germany, 2012; pp. 270-286.

38. Hirose, S.; Ideguchi, K.; Kuwakado, H.; Owada, T.; Preneel, B.; Yoshida, H. A lightweight 256-bit hash function for hardware and low-end devices: Lesamnta-LW. Proceedings of the International Conference on Information Security and Cryptology; Seoul, Republic of Korea, 1–3 December 2010; Springer: Berlin/Heidelberg, Germany, 2010; pp. 151-168.

39. Bogdanov, A.; Knežević, M.; Leander, G.; Toz, D.; Varıcı, K.; Verbauwhede, I. SPONGENT: A lightweight hash function. Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems; Nara, Japan, 28 September–1 October 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 312-325.

40. Guo, J.; Peyrin, T.; Poschmann, A. The PHOTON family of lightweight hash functions. Proceedings of the Annual Cryptology Conference; Santa Barbara, CA, USA, 14–18 August 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 222-239.

41. Aumasson, J.P.; Henzen, L.; Meier, W.; Naya-Plasencia, M. Quark: A lightweight hash. J. Cryptol.; 2013; 26, pp. 313-339. [DOI: https://dx.doi.org/10.1007/s00145-012-9125-6]

42. Aumasson, J.P.; Bernstein, D.J. SipHash: A fast short-input PRF. Proceedings of the International Conference on Cryptology in India; Kolkata, India, 9–12 December 2012; Springer: Berlin/Heidelberg, Germany, 2012; pp. 489-508.

43. Bussi, K.; Dey, D.; Kumar, M.; Dass, B. Neeva: A lightweight hash function. Cryptol. Eprint Arch.; 2016.

44. Kavun, E.B.; Yalcin, T. A lightweight implementation of keccak hash function for radio-frequency identification applications. Proceedings of the Radio Frequency Identification: Security and Privacy Issues: 6th International Workshop, RFIDSec 2010; Istanbul, Turkey, 8–9 June 2010; Springer: Berlin/Heidelberg, Germany, 2010; pp. 258-269.

45. Aumasson, J.P.; Meier, W.; Phan, R.C.W.; Henzen, L. The Hash Function BLAKE; Springer: Berlin/Heidelberg, Germany, 2014; [DOI: https://dx.doi.org/10.1007/978-3-662-44757-4]

46. Bhoyar, P.; Dhok, S.; Deshmukh, R. Hardware Implementation of Simeck Cipher as a Lightweight Hash Function. Advances in VLSI, Communication, and Signal Processing; Springer: Singapore, 2020; pp. 125-131.

47. El-Hadedy, M.; Margala, M.; Mosanu, S.; Gligorosk, D.; Hwu, W.M. PRO-GAGE: A High Performance Compact GAGE Hash Function Processor for Small Space Technology. Proceedings of the 2021 IEEE Space Computing Conference (SCC); Laurel, MD, USA, 23–27 August 2021; pp. 9-16.

48. Windarta, S.; Suryadi, S.; Ramli, K.; Lestari, A.A.; Wildan, W.; Pranggono, B.; Wardhani, R.W. Two new lightweight cryptographic hash functions based on saturnin and beetle for the Internet of Things. IEEE Access; 2023; 11, pp. 84074-84090. [DOI: https://dx.doi.org/10.1109/ACCESS.2023.3301128]

49. Mahmoud, M.A.; Gurunathan, M.; Ramli, R.; Babatunde, K.A.; Faisal, F.H. Review and Development of a Scalable Lightweight Blockchain Integrated Model (LightBlock) for IoT Applications. Electronics; 2023; 12, 1025. [DOI: https://dx.doi.org/10.3390/electronics12041025]

50. Achar, S.D.; P, T.; Nandi, S.; Nandi, S. LiteHash: Hash Functions for Resource-Constrained Hardware. ACM Trans. Embed. Comput. Syst.; 2025; 24, pp. 1-17. [DOI: https://dx.doi.org/10.1145/3677181]

51. Hızal, S.; Akhter, A.S.; Çavuşoğlu, Ü.; Akgün, D. Blockchain-based IoT security solutions for IDS research centers. Internet Things; 2024; 27, 101307. [DOI: https://dx.doi.org/10.1016/j.iot.2024.101307]

52. Li, M.; Wang, M.; Duan, M. Atomic and privacy-preserving cyclic cross-chain protocol based on chameleon hash function. Blockchain Res. Appl.; 2025; 100262. [DOI: https://dx.doi.org/10.1016/j.bcra.2024.100262]

53. Süzen, A.A.; Duman, B. Blockchain-based secure credit card storage system for e-commerce. Sak. Univ. J. Comput. Inf. Sci.; 2021; 4, pp. 204-215. [DOI: https://dx.doi.org/10.35377/saucis.04.02.895764]

54. Chalkias, K.K.; Lindstrøm, J.; Roy, A. An Efficient Hash Function for Imaginary Class Groups. Cryptol. Eprint Arch.; 2024; preprint

55. Yüzkollar, C. Sequential and Correlated Image Hash Code Generation with Deep Reinforcement Learning. Sak. Univ. J. Comput. Inf. Sci.; 2023; 6, pp. 149-159. [DOI: https://dx.doi.org/10.35377/saucis..1339150]

56. Erbil, M.E.; Özkahraman, M.; Bayrakçı, H.C. Enhancing Industrial Robot Arms Data Security with a Hybrid Encryption Approach. Sak. Univ. J. Sci.; 2024; 28, pp. 756-773. [DOI: https://dx.doi.org/10.16984/saufenbilder.1440949]

57. Cherckesova, L.V.; Safaryan, O.A.; Lyashenko, N.G.; Korochentsev, D.A. Developing a new collision-resistant hashing algorithm. Mathematics; 2022; 10, 2769. [DOI: https://dx.doi.org/10.3390/math10152769]

58. Sevin, A.; Mohammed, A.A.O. A survey on software implementation of lightweight block ciphers for IoT devices. J. Ambient. Intell. Humaniz. Comput.; 2023; 14, pp. 1801-1815. [DOI: https://dx.doi.org/10.1007/s12652-021-03395-3]

59. Panahi, P.; Bayılmış, C.; Çavuşoğlu, U.; Kaçar, S. Performance evaluation of lightweight encryption algorithms for IoT-based applications. Arab. J. Sci. Eng.; 2021; 46, pp. 4015-4037. [DOI: https://dx.doi.org/10.1007/s13369-021-05358-4]

60. Çavuşoğlu, Ü.; Al-Sanabani, H. The Performance Comparison of Lightweight Encryption Algorithms. Sak. Univ. J. Comput. Inf. Sci.; 2019; 2, pp. 158-169.

61. Sevin, A.; Çavuşoğlu, Ü. Design and Performance Analysis of a SPECK-Based Lightweight Hash Function. Electronics; 2024; 13, 4767. [DOI: https://dx.doi.org/10.3390/electronics13234767]

62. Sevin, A.; Osman Mohammed, A.A. Comparative Study of Blockchain Hashing Algorithms with a Proposal for HashLEA. Appl. Sci.; 2024; 14, 11967. [DOI: https://dx.doi.org/10.3390/app142411967]

63. Lai, X.; Massey, J.L. Hash functions based on block ciphers. Proceedings of the Workshop on the Theory and Application of of Cryptographic Techniques; Balatonfüred, Hungary, 24–28 May 1992; Springer: Berlin/Heidelberg, Germany, 1992; pp. 55-70.

64. Wong, K.W. A combined chaotic cryptographic and hashing scheme. Phys. Lett. A; 2003; 307, pp. 292-298. [DOI: https://dx.doi.org/10.1016/S0375-9601(02)01770-X]

65. Damgård, I.B. Collision free hash functions and public key signature schemes. Proceedings of the Workshop on the Theory and Application of Cryptographic Techniques; Amsterdam, The Netherlands, 13–15 April 1987; Springer: Berlin/Heidelberg, Germany, 1987; pp. 203-216.

66. Al-Kuwari, S.; Davenport, J.H.; Bradford, R.J. Cryptographic Hash Functions: Recent Design Trends and Security Notions. IACR Cryptol. ePrint Arch.; 2011; 2011, 565.

67. Van Oorschot, P.C.; Menezes, A.J.; Vanstone, S.A. Handbook of Applied Cryptography; CRC Press: Boca Raton, FL, USA, 1996; [DOI: https://dx.doi.org/10.1201/9780429466335]

68. Merkle, R.C. One way hash functions and DES. Proceedings of the Conference on the Theory and Application of Cryptology; Houthalen, Belgium, 10–13 April 1989; Springer: New York, NY, USA, 1989; pp. 428-446.

69. Damgård, I.B. A design principle for hash functions. Proceedings of the Conference on the Theory and Application of Cryptology; Houthalen, Belgium, 10–13 April 1989; Springer: New York, NY, USA, 1989; pp. 416-427.

70. Bertoni, G.; Daemen, J.; Peeters, M.; Van Assche, G. Sponge functions. ECRYPT Hash Workshop; Citeseer: University Park, PA, USA, 2007; Number 9

71. Winternitz, R.S. A secure one-way hash function built from DES. Proceedings of the 1984 IEEE Symposium on Security and Privacy; Oakland, CA, USA, 29 April–2 May 1984; 88.

72. Lucks, S. A failure-friendly design principle for hash functions. Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security; Chennai, India, 4–8 December 2005; Springer: Berlin/Heidelberg, Germany, 2005; pp. 474-494.

73. Dunkelman, O.; Biham, E. A framework for iterative hash functions: Haifa. 2nd NIST Cryptographich Hash Workshop; Computer Science Department Technion: Haifa, Israel, 2006; Volume 22.

74. Bellare, M.; Rogaway, P. Collision-resistant hashing: Towards making UOWHFs practical. Proceedings of the Annual International Cryptology Conference; Santa Barbara, CA, USA, 17–21 August 1997; Springer: Berlin/Heidelberg, Germany, 1997; pp. 470-484.

75. Meuser, T.; Schmidt, L.; Wiesmaier, A. Comparing Lightweight Hash Functions–PHOTON & Quark; The Technical University of Darmstadt: Darmstadt, Germany, 2015.

76. Avoine, G.; Hernandez-Castro, J. Security of Ubiquitous Computing Systems: Selected Topics; Springer Nature: Canterbury, UK, 2021; [DOI: https://dx.doi.org/10.1007/978-3-030-10591-4]

77. Nursi, S. From the Risale-i Nur Collection: The Words; Nur Publishers: Istanbul, Turkey, 1993; Volume 1.

78. Shannon, C.E. A mathematical theory of cryptography. Math. Theory Cryptogr.; 1945; 1, pp. 1-132.

79. Dworkin, M.J. SHA-3 standard: Permutation-based hash and extendable-output functions. Federal Inf. Process. Stds. (NIST FIPS); 2015; 1, pp. 1-29. [DOI: https://dx.doi.org/10.6028/NIST.FIPS.202]

80. Ismailova, R. Analysis of Three Block Cipher Based Hash Functions: Whirpool, Grøstl and Grindahl. Ph.D. Thesis; Middle East Technical University: Ankara, Turkey, 2012.

81. Yang, Y.; Chen, F.; Zhang, X.; Yu, J.; Zhang, P. Research on the hash function structures and its application. Wirel. Pers. Commun.; 2017; 94, pp. 2969-2985. [DOI: https://dx.doi.org/10.1007/s11277-016-3760-4]

82. Abdoun, N.; El Assad, S.; Manh Hoang, T.; Deforges, O.; Assaf, R.; Khalil, M. Designing Two Secure Keyed Hash Functions Based on Sponge Construction and the Chaotic Neural Network. Entropy; 2020; 22, 1012. [DOI: https://dx.doi.org/10.3390/e22091012] [PubMed: https://www.ncbi.nlm.nih.gov/pubmed/33286780]

83. Abdelfatah, R.I.; Nasr, M.; Abdelkhalek, B.E. Enhanced Parallel Hash Function Algorithm Based on 3C Construction (EPHFA-3C). Am. Sci. Res. J. Eng. Technol. Sci.; 2020; 74, pp. 206-221.

84. OpenMP Architecture Review Board. OpenMP Application Program Interface. Specification, OpenMP. Available online: https://www.openmp.org/specifications/ (accessed on 19 December 2024).