Comparative Study of Keccak SHA-3 Implementations

Abstract

This paper conducts an extensive comparative study of state-of-the-art solutions for implementing the SHA-3 hash function. SHA-3, a pivotal component in modern cryptography, has spawned numerous implementations across diverse platforms and technologies. This research aims to provide valuable insights into selecting and optimizing Keccak SHA-3 implementations. Our study encompasses an in-depth analysis of hardware, software, and software–hardware (hybrid) solutions. We assess the strengths, weaknesses, and performance metrics of each approach. Critical factors, including computational efficiency, scalability, and flexibility, are evaluated across different use cases. We investigate how each implementation performs in terms of speed and resource utilization. This research aims to improve the knowledge of cryptographic systems, aiding in the informed design and deployment of efficient cryptographic solutions. By providing a comprehensive overview of SHA-3 implementations, this study offers a clear understanding of the available options and equips professionals and researchers with the necessary insights to make informed decisions in their cryptographic endeavors.

1. Introduction

Open contests have become a preferred method for selecting cryptographic standards in the U.S. and worldwide, beginning with the Advanced Encryption Standard (AES) contest organized by the NIST in 1997–2000. Four typical criteria taken into account in the evaluation of candidates in such contests are security, performance in software, performance in hardware, and flexibility [1]. Security, though crucial, is complex to assess quickly in contests. Hardware performance often serves as a tiebreaker when other criteria fail to declare a clear winner among cryptographic algorithms. In this survey, we focus on Secure Hash Algorithm 3 (SHA-3). It is a cryptographic hash function standard selected by the National Institute of Standards and Technology (NIST) in 2015. It emerged victorious in a rigorous competition organized by the NIST to find a successor to the aging SHA-2.

Among the contenders, Keccak, designed by Guido Bertoni, Joan Daemen, Micha$\ddot{e}$l Peeters, and Gilles Van Assche, stood out for its innovative design and strong security properties, ultimately earning its place as the foundation of SHA-3. This achievement marked a significant milestone in modern cryptography, ensuring robust and efficient hash functions for various security applications. While it currently stands as the leader in resisting recent cryptanalysis attacks and excels in hardware performance, there is a continuous demand for developing an efficient implementation, be it software, e.g., Central Processing Unit (CPU), or hardware, e.g., Field-Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC). Common software implementations on a microcontroller offer high flexibility, but they may not provide the required performance for cryptographic algorithms with high computational demands. Microcontrollers are versatile and programmable, making them suitable for a wide range of applications, but they may struggle with the computational intensity of modern cryptographic algorithms. Moving up the spectrum, an extensible processor, such as an application microprocessor, co-processors (i.e., [2]), or a Digital Signal Processor (DSP), offers more significant performance potential than fixed ones. These processors can be optimized for specific cryptographic operations, providing better throughput and efficiency than a generic microcontroller. However, they are still limited by their general-purpose architecture, which may not match the specialized requirements of specific cryptographic algorithms. A programmable datapath takes the customization a step further by allowing users to design custom hardware accelerators for cryptographic tasks. This approach offers a balance between flexibility and performance. Programmable datapaths enable the efficient execution of cryptographic algorithms through parallel processing and custom hardware instructions (i.e., [3]). Finally, the least flexible but most efficient solution is the hardwired datapath, typically implemented in ASICs (Application-Specific Integrated Circuits). ASICs are designed specifically for a particular cryptographic algorithm or set of algorithms, making them highly efficient in terms of speed and power consumption. However, their lack of flexibility means that any changes or updates to cryptographic algorithms require a new hardware design.

In summary, the choice of implementation approach for cryptographic algorithms depends on the trade-off between flexibility and efficiency, as shown in Figure 1. Selecting the most suitable implementation space depends on the specific cryptographic requirements and application constraints.

The rest of the article is organized as follows: Section 2 reports a background about SHA-3 construction. Section 3 describes Keccak structure. Section 4 is developed to report all of the solutions found in the state of the art for implementing SHA-3, compared with each other, while, in Section 6, there are comments and examinations of different hardware implementation solutions more in details; Section 6 reports implementations results, and Section 7 the conclusion of this analysis.

2. SHA-3

SHA-3 is a subset of the Keccak family standardized by the NIST. The standard lists four specific instances of SHA-3 and two extendable-output functions (SHAKE128 and SHAKE256). While the SHA-3 functions have a specified output length, the two SHAKE variants permit extraction of a variable length of output data, which makes SHA-3 a suitable candidate for pseudo-random bit generation [4]. All SHA-3 functions operate within a shared foundational framework known as the sponge construction (as shown in Figure 2a). This framework is highly adaptable and allows for the generation of hash values with variable length, making it well suited for diverse applications.

The NIST standard defines four versions of the Keccak sponge function [5] for a message M and an output length d, as shown in

Table 1. SHA3 instances.

Instance	Output Size d	Rate r	Capacity c
SHA3-224	224	1152	448
SHA3-256	256	1088	512
SHA3-384	384	832	768
SHA3-512	512	576	1024

. The algorithm uses two parameters for the sponge construction: the bitrate with r-bits, which determines the number of bits absorbed in each step, and the capacity with c-bits, which determines the attainable security level (Figure 2a).

The flow of a sponge function can be understood through the following steps:

• Initialization: the sponge function is initialized depending on r and c parameters.
• Padding: The input message is padded to ensure that length is a multiple of r. Most of the architectures utilize a software scheduler for preparing the input by splitting and padding long messages into blocks of 1600 bits (multi-block messages) for truncating, if necessary, the output of the hash computation in the appropriate size of the selected mode of operation and for updating the state matrix in the case of multi-block messages. As an example, in [4,6,7,8] the input to the SHA-3 block is assumed to be already padded.
  In other works, i.e., [8], the hardware block is not performing only the f-transform, but it also has a Versioning and XOR-iring module (VSX) that is responsible for forming the appropriate state per algorithm version.
  There are some implementations in which all the steps of the sponge function are supported (padding, mapping, and truncation), but, generally, these architectures assume that the input can only be of a certain length (i.e., [9] considers input messages whose length is fixed to 64 bits), or have a precise application (i.e., [10] considers only the CRYSTALS-Kyber 768 algorithm).
• Absorbing Phase: Here, the padded message is divided into blocks of a size of r bits each, and each block is XORed with the current state of the sponge function. The resulting state is then processed through a series of bitwise operations, typically using a permutation function, to mix the input data with the current state. The function f acts on the state, with a width of $b=r+c$.
• Squeezing Phase: After all of the message blocks have been absorbed, the function produces the hash output by repeatedly extracting r bits from the state. These bits are concatenated to form the final hash value. The squeezing phase continues until the desired hash length is achieved.
• Finalization: in the end, the sponge function may perform additional operations to finalize the hash value, such as truncating it to the desired length or applying additional cryptographic transformations.

Central to the sponge construction is the concept of state. The state has a length of 1600 bits and consists of a three-dimensional $5\times 5\times 64$ table, as shown in Figure 2b. Each bit of this cube can be addressed with $A[x,y,z]$. In order to facilitate the description of the applied functions, the following conventions are used: the part of the state that presents the word is also called a lane, a two-dimensional part of the state with a fixed z is called a slice, and all lanes with the same x-coordinate form a sheet.

3. Keccak

The most important part of the SHA-3 and SHAKE primitives is the Keccak permutation function, which calls for 24 rounds of the f-1600 function. Each round is characterized by the five consecutive steps $\theta ,\rho ,\pi ,\chi$, and $\iota$. These steps have a state array A as input and an output B, which is a processed new state array. As shown in Equation (1), $\theta$ consists of a parity computation, a rotation of one position, and a bitwise XOR.

$$\begin{array}{cc}\hfill \theta :& C\left[x\right]=A[x,0]\oplus A[x,1]\oplus A[x,2]\oplus A[x,3]\oplus A[x,4]0\le x\le 4\hfill \\ \hfill & D\left[x\right]=C[x-1]\oplus ROT\left(C\right[x+1],1)0\le x\le 4\hfill \\ \hfill & A[x,y]=A[x,y]\oplus D\left[x\right]0\le x,y\le 4\hfill \end{array}$$

(1)

In Equation (2), $\rho$ is a rotation by an offset that depends on the word position, and $\pi$ is a permutation.

$$\begin{array}{c}\hfill \rho -\pi :B[y,2x+3y]=ROT\left(A\right[x,y],r[x,y\left]\right)0\le x,y\le 4\end{array}$$

(2)

In Equation (3), $\chi$ consists of bitwise XOR, NOT, and AND gates.

$$\begin{array}{c}\hfill \chi :A[x,y]=B[x,y]\oplus (\left(\overline{B[x+1,y]}\right)·\left(B[x+2,y]\right))0\le x,y\le 4\end{array}$$

(3)

Lastly, $\iota$, in Equation (4) is a constant round addition.

$$\begin{array}{c}\hfill \iota :A[0,0]=A[0,0]\oplus RC0\le x,y\le 4\end{array}$$

(4)

When these five are completed, a round is completed.

Table 2. Values RC[i] constants.

RC[0] 0x0000000000000001	RC[8] 0x000000000000008a	RC[16] 0x8000000000008002
RC[1] 0x0000000000008082	RC[9] 0x0000000000000088	RC[17] 0x8000000000000080
RC[2] 0x800000000000808a	RC[10] 0x0000000080008009	RC[18] 0x000000000000800a
RC[3] 0x8000000080008000	RC[11] 0x000000008000000a	RC[19] 0x800000008000000a
RC[4] 0x000000000000808b	RC[12] 0x000000008000808b	RC[20] 0x8000000080008081
RC[5] 0x0000000080000001	RC[13] 0x800000000000008b	RC[21] 0x8000000000008080
RC[6] 0x8000000080008081	RC[14] 0x8000000000008089	RC[22] 0x0000000080000001
RC[7] 0x8000000000008009	RC[15] 0x8000000000008003	RC[23] 0x8000000080008008

reports the round constant function RC[i], which is a 24-value permutation that assigns 64-bit data to the Keccak function.

Table 3. Values r[x,y] constants.

	X = 3	X = 4	X = 0	X = 1	X = 2
Y = 2	25	39	3	10	43
Y = 1	55	20	36	44	6
Y = 0	28	27	0	1	62
Y = 4	56	14	18	2	61
Y = 5	21	8	41	45	15

reports the cyclic shift offset r[x,y].

More information about the Keccak algorithm can be found in [11].

4. Implementation

When developing a real implementation, a diverse array of possibilities within the design space is available. These options encompass entirely hardware-based solutions, pure software implementations, and hybrid approaches, such as Integrated Software Environments (ISE) or Application-Specific Instruction Processor (ASIP). Strictly hardware-based solutions involve dedicated IP cores, while pure software implementations rely solely on software resources. ISEs (Integrated Software Environment) or ASIP, representing a hybrid solution, enhance general-purpose processor cores with specialized hardware and instructions.

Figure 3 shows the different aspects covered in the next sections and proposes for each implementation approach a choice of proper references. Let us now delve into the intricacies of each conceivable approach.

4.1. Hardware Solutions

Hardware implementations of Keccak demand careful consideration of trade-offs. When implementing Keccak in hardware, the choice of design parameters and strategies heavily depends on the specific goals and constraints of the target application. These objectives typically revolve around factors such as speed, power efficiency, and area utilization. In this section, we will explore the various aspects that can be considered during the hardware implementation of Keccak, with a focus on these key parameters.

Unrolling. Unrolling is particularly efficient in improving the throughput for single-message hashing. Considering Keccak, the f-permutation block can be replicated and unrolled in the SHA-3 hash function. As an example, Refs. [6,12] implement SHA-3 considering an unrolling factor of two, while, in [7], an even higher degree of unrolling has been analyzed. Moumni et al. [9] and Nannipieri et al. [13] have made several attempts, instantiating from a single instance to twelve, going from 24 clock cycles to 2; however, this resulted in an onerous increase in area.

Pipelining. Pipelining brings the advantages of combined data throughput enhancement in multi-message hashing, where the function processes more than one message concurrently. In addition, two different types of pipelining can be distinguished:

• Classic pipelining, generally used between one round and another;
• Sub-pipelining, inserted instead between two steps of the same round.

For instance, in [8,14], the pipeline is inserted between the $\pi$ and $\chi$ steps, while, in [12], it is inserted between the $\theta$ and $\rho$ steps.

Folding. Towards a more compact SHA-3 structure, folding of the round computation can be considered. In the case of [15], each round is computed over multiple clock cycles, depending on the folding factor.

Cutting the Keccak state. The efficient management of the Keccak state is of paramount importance [16]. There are multiple alternatives, namely using slice-wise, plane-wise, and bit-interleaving techniques. Jungk et al. [17] propose a very compact slice-oriented Keccak hardware, based on the observation that all Keccak steps except $\rho$ can be performed efficiently with slice-wise processing. However, since input messages for absorption generally arrive in a lane-oriented fashion, the plane-wise partitioning is favorable (adjacent bits in a register belong to the same lane).

Interleaved lanes. Bit-interleaving is a technique that can be used to break large 64-bit lanes of Keccak into smaller chunks [18].

Resource Sharing. Resource area sharing is a crucial optimization technique employed in hardware design, particularly in the context of FPGAs and ASICs. It aims to maximize the efficient utilization of available resources while minimizing the overall hardware footprint, which can lead to cost savings, improved performance, and reduced power consumption. An interesting example is the co-processor presented in [2], named AE$HA-3, which combines two of the NIST’s standardized algorithms, i.e., Advance Encryption Standard (AES) and SHA-3. Maache et al. [3] also present a multi-purpose cryptographic system performing both AES and SHA-3, implementing it on the IntelFPGA Cyclone-V device.

To sum up, the hardware implementation of Keccak is a multifaceted task that necessitates careful consideration of various trade-offs and objectives. The specific design choices will be heavily influenced by the unique demands of the target application, whether it be a high-performance cryptographic accelerator, a low-power embedded system, or any other use case in which Keccak is employed. Each implementation will strike a balance between speed, power efficiency, area utilization, and security to meet its intended purpose effectively.

4.2. Software Solutions

Enhancing the software implementation of an algorithm holds the key to unlocking superior performance. By optimizing code, leveraging hardware-specific features, and minimizing resource overhead, software improvements can significantly boost algorithmic efficiency, resulting in faster execution and better utilization of available hardware resources. Accelerating the SHA-3 algorithm on FPGA devices, RISC-V, or ARM without dedicated hardware accelerators involves optimizing the software implementation to maximize performance. Here are some techniques to achieve this.

Parallelization. Using parallelization for implementing multi-threading or multi-processing when having multiple CPU cores can significantly improve performances. Each core can work on a separate chunk of data, improving overall throughput. Pereira et al. [19] present a technique for parallel processing on Graphics Processing Units (GPUs) of the Keccak hash algorithm. They provide the core functionality, and the evaluation is performed on a Xilinx Virtex 5 FPGA.

Vectorization (SIMD). Utilize the SIMD (Single Instruction, Multiple Data) instructions available in modern processors (e.g., ARM NEON, RISC-V RVV) to process multiple data elements in parallel. This can significantly speed up the hashing process, especially when dealing with large datasets. For example, Ref. [20] proposes a set of six custom instructions for Keccak-$f,p$ [1600, 800, 400, 200] primitives, and, similarly to other crypto-instructions (e.g., Intel AES-NI and SHA), they exploit the wide SIMD (Single Instruction, Multiple Data) registers. Li et al. [21] explore the full potential of parallelization of Keccak-f[1600] in RISC-V-based processors through custom vector extensions on 32-bit and 64-bit architectures.

Loop Unrolling. Unroll loops in the SHA-3 algorithm code to reduce loop overhead and enable the compiler to optimize the code more effectively. This can result in faster execution, especially on CPUs with pipelined execution units. Ref. [22] reports several analyses about security versus area versus the timing of PQC decapsulation algorithms, after loop unrolling, showing how, in most cases, this brings a significant reduction in latency.

Instruction-Level Optimization. Hand-tune critical sections of the code to use processor-specific instructions and features. This may include using assembly language or intrinsic to access specialized instructions for SHA-3 operations. Ref. [23] presents two new techniques for the fast implementation of the Keccak permutation on the A-profile of the Arm architecture: the elimination of explicit rotations in the Keccak permutation through barrel shifting, and the construction of hybrid implementations concurrently leveraging both the scalar and the Neon instruction sets of AArch64.

Optimized Compiler Flags. Use compiler optimization flags (-O2, -O3, i.e., in [24]) to instruct the compiler to apply various optimizations, including loop unrolling, inline function expansion, and instruction scheduling. Ref. [25] uses -On command line flags during GCC compilation to improve performance at the cost of increased compilation times.

Memory Access Optimization. Minimize memory access latency by optimizing data structures and memory access patterns. Cache-friendly data structures and efficient memory layouts can reduce the number of cache misses. Choi et al. [26] discuss optimizations, memory management strategies, and parallelization schemes, aiming to enhance the performance and throughput of SHA-3 operations on graphics processing units (GPUs).

Prefetching. Use prefetching techniques to load data into the cache before it is actually needed, reducing memory access stalls and improving data processing speed. Lee et al. [27], using NVIDIA GPU, exploit the feature for which arithmetic instructions and memory load/store instructions can be executed concurrently, as long as there is no dependency between the executing instruction and data being loaded/stored. They prefetch the input data of Keccak before XORing it into the state, so that address calculation and bitwise XOR operation can run in parallel with the memory copy operation.

The effectiveness of these techniques will depend on the specific platform, compiler, and workload, so thorough testing and profiling are essential to achieve optimal results. Continuously profiling and benchmarking the software implementation will help identify performance bottlenecks and areas for improvement. This iterative process can lead to significant performance gains.

4.3. Hybrid Solutions

Hybrid solutions, which combine both software and hardware components, represent a versatile approach to solving complex problems by harnessing the strengths of each domain. These solutions essentially encompass all of the techniques discussed in the previous section and merge them into a cohesive, integrated system.

In the realm of technology and problem-solving, software and hardware have traditionally been seen as separate entities. Software provides flexibility and adaptability, while hardware offers raw processing power and efficiency. A hybrid solution brings together the computational capabilities of hardware and the logic and adaptability of software to create a powerful and agile system. It allows optimization of the performance by distributing tasks between software and hardware according to their respective strengths. This means that computationally intensive tasks can be offloaded to dedicated hardware accelerators, while software can handle tasks that require flexibility and frequent updates. This balance ensures that the system operates efficiently without bottlenecks. Moreover, being that software is inherently adaptable, it is easier to implement changes and updates to meet evolving requirements. Fritzmann et al. [4] present RISQ-V, an enhanced RISC-V architecture that integrates a set of powerfully coupled accelerators. Here, hardware/software co-design techniques have been combined to develop complex and highly customized solutions, designing tightly and loosely coupled accelerators and Instruction Set Architecture (ISA) extensions. This is an example of how combining the hardware and software provides the flexibility to adjust algorithms, logic, or functionality in response to changing needs while maintaining the stability and speed of the hardware.

5. Micro-Architecture Details

The Keccak permutation, which consists of five main steps ($\theta$, $\rho$, $\pi$, $\chi$, and $\iota$), is designed to be highly parallelizable, which means that the order of these steps can affect synthesis results and performance on an FPGA. The reasons are manifold.

Different FPGA architectures have distinct types and quantities of resources, and, therefore, the order of the permutation steps can influence how these resources are utilized. Additionally, the timing requirements of the FPGA may vary depending on the order of the steps. Certain steps may introduce longer or shorter critical paths, impacting the maximum achievable clock frequency. Some steps of the Keccak permutation are inherently more parallelizable than others. For example, the $\theta$ and $\chi$ steps can be parallelized more easily than the $\rho$ step, which involves shifting bits. The order in which these steps are arranged can determine how effectively parallelism can be exploited, affecting overall performance.

Obviously, FPGA synthesis tools must be considered too, since they employ various algorithms and optimization techniques to map the design onto the target FPGA.

Considering these factors, it is useful to explore different combinations of the permutation steps during FPGA design to find the optimal arrangement for a given FPGA platform. Some syntheses have been performed on Cyclone V (5CEFA9F31C8), with a time constraint of 6 $\mathrm{n}\mathrm{s}$. In this analysis, only performance is considered. As can be observed from

Table 4. Analysis of Keccak permutation steps.

Case	Rotation Order	F [MHz]	Latency [µs]	Number of Iterations	% with Respect to Case 1
1	$\theta -\rho -\pi -\chi -\iota$	168	0.143	24
2	$\rho -\pi -\chi -\iota -\theta$	180	0.139	25	−2.78%
3	$\pi -\chi -\iota -\theta -\rho$	184	0.136	25	−4.89%
4	$\chi -\iota -\theta -\rho -\pi$	183	0.137	25	−4.37%
5	$\iota -\theta -\rho -\pi -\chi$	165	0.15	25	6.06%
6 *	$\theta -\rho -\pi -\chi -\iota$	84	0.143	12	0.00%
7 *	$\rho -\pi -\chi -\iota -\theta$	93.84	0.139	13	−3.03%
8 *	$\pi -\chi -\iota -\theta -\rho$	94.77	0.137	13	−3.98%
9 *	$\chi -\iota -\theta -\rho -\pi$	95.06	0.137	13	−4.27%
10 *	$\iota -\theta -\rho -\pi -\chi$	72.83	0.18	13	24.95%

* double instance of the round unit (unrolling factor = 2).

, the best results are in cases 2, 3, 4, 7, 8, and 9, which have in common the sequence $\chi -\iota -\theta$. Obviously, changing the rotation order disrupts the dependencies between steps, requiring additional clock cycles to ensure data integrity and correctness, thus increasing the overall processing time by at least one clock cycle (as can be seen from the fifth column of Table 4).

Moreover, there are different possible options for what concerns implementation of the round constant generator (constants reported in Table 2). There are three plausible implementations. First, a circuit constructed using Linear Feedback Shift Register (LFSR) can be employed to perform on-the-fly generation of the round constant values. Another solution is storing all of the 24 pre-calculated round constants of a 64-bit length in memory forms (such as registers or circular buffers) and transferring them to the $\iota$ module via a multiplexer [8]. Since efficient resource utilization is vital for hardware implementations, it has been proved that the length of the RC values can be reduced to less than a byte size (see

Table 5. Simplified round constants.

RC[0] 0x01	RC[6] 0xf1	RC[12] 0x7b	RC[18] 0x2a
RC[1] 0x32	RC[7] 0xa9	RC[13] 0x9b	RC[19] 0xca
RC[2] 0xba	RC[8] 0x1a	RC[14] 0xb9	RC[20] 0xf1
RC[3] 0xe0	RC[9] 0x18	RC[15] 0xa3	RC[21] 0x90
RC[4] 0x3b	RC[10] 0x69	RC[16] 0xa2	RC[22] 0xf1
RC[5] 0x41	RC[11] 0x4a	RC[17] 0x90	RC[23] 0e8

) by storing only the non-zero bits in each of the round constant values [12,28]. This will also save 55–56 XORs in the $\iota$ step.

In addition, a combinatorial circuit using a series of logical gates can be realized to compute the round constant value upon every iteration. For example, the counter value, which was used within SHA-3 to keep track of the number of iterations, was used as input to calculate on-the-fly RC values.

$$\begin{array}{cc}\hfill & RC\left[0\right]=A^{\prime }C+C{E}^{\prime }+BD{E}^{\prime }+A^{\prime }{B}^{\prime }{D}^{\prime }{E}^{\prime }\hfill \\ \hfill & RC\left[1\right]=B{D}^{\prime }{E}^{\prime }+BDE+BC{D}^{\prime }+A{C}^{\prime }{E}^{\prime }+A{C}^{\prime }D+B^{\prime }{C}^{\prime }D{E}^{\prime }+A^{\prime }C{D}^{\prime }{E}^{\prime }+A^{\prime }{B}^{\prime }{C}^{\prime }{D}^{\prime }E\hfill \\ \hfill & RC\left[2\right]=0\hfill \\ \hfill & RC\left[3\right]=B{C}^{\prime }+B{D}^{\prime }+B{E}^{\prime }+C^{\prime }D{E}^{\prime }+A{C}^{\prime }D+A^{\prime }C{D}^{\prime }{E}^{\prime }+B^{\prime }CDE\hfill \\ \hfill & RC\left[4\right]=B{D}^{\prime }+A^{\prime }C{E}^{\prime }+AC{D}^{\prime }+C^{\prime }{D}^{\prime }E+A^{\prime }{B}^{\prime }D{E}^{\prime }\hfill \\ \hfill & RC\left[5\right]=A^{\prime }D{E}^{\prime }+A^{\prime }C{E}^{\prime }+CDE+A{C}^{\prime }{E}^{\prime }+AC{D}^{\prime }+A^{\prime }{B}^{\prime }{C}^{\prime }E\hfill \\ \hfill & RC\left[6\right]=C^{\prime }DE+B{C}^{\prime }D+ADE+AC{E}^{\prime }+B^{\prime }CD{E}^{\prime }+BC{D}^{\prime }{E}^{\prime }+A^{\prime }{B}^{\prime }C{D}^{\prime }E\hfill \\ \hfill & RC\left[7\right]=A{D}^{\prime }+AE+A^{\prime }{B}^{\prime }D+A^{\prime }CD+BCE\hfill \end{array}$$

(5)

In particular, considering A as the MSB of the counter and E as the LSB, seven logical expressions were constructed to obtain the constants shown in Table 5. This solution has been synthesized by targeting an ASIC on 65 $\mathrm{n}\mathrm{m}$ technology with a time constraint of 0.73 $\mathrm{n}\mathrm{s}$. Area results are reported in

Table 6. Round constant generator analysis.

Case	Total Cell Area [µm${}^2$]	Combinational Area [µm${}^2$]	Noncombinational Area [µm${}^2$]
RC-64bit	55,293.48	42,285.24	13,008.24
RC-8bit	55,061.28	42,015.96	13,045.32
RC-8bit *	54,997.20	41,954.40	13,042.80

* evaluated on the fly.

: the second and third solutions provide a slight improvement in terms of area occupancy without changing the critical path of the entire circuit.

These kinds of exploration help achieve the best balance between resource utilization, performance, and power consumption, ultimately leading to a more efficient and effective hardware implementation of the Keccak permutation for a specific FPGA target or a particular technology. Additionally, it allows designers to adapt the design to different platforms without starting from scratch, saving time and effort in the development process.

6. Results

6.1. Stand-Alone Solutions

Regarding FPGA implementation, there are four main parameters to take into account:

• Maximum achievable frequency: the maximum clock frequency with which the FPGA design can operate. It indicates the speed at which the system can work. The higher it is, the faster the overall performance.
• Area: the amount of FPGA resources consumed by the design.
• Throughput: the rate at which a message can be processed. The higher it is, the higher the number of messages that can be handled in the same amount of time.
• Efficiency: the whole effectiveness of the design. The higher it is, the more the FPGA utilization resources and performance are improved.

Table 7. Unrolling and pipeline on FPGA.

Reference	Unrolling Factor	Pipeline Factor	Device	Frequency [MHz]	Area [Slices]	Throughput [Gbps]	Efficiency [Mbps/Slices]
[6]	1	1	Virtex-6	412	1115	9.888	8.868
[6]	2	2	Virtex-6	391	2296	18.768	8.174
[7]	3	3	Virtex-6	391	3965	28.152	7.000
[7]	4	4	Virtex-6	392	4117	37.63	9.141
[12]	2	-	Virtex-6	45	2145	2.16	1.00
[12]	2	2	Virtex-6	85	1416	4.08	2.88
[12]	2	2 (* 2)	Virtex-6	344	1406	16.51	11.47
[8]	-	- (* 1)	Virtex-6	397	1649	19.1	11.6
[15]	1	1	Virtex-5	223	1192	5.35	4.49
[15]	2	1	Virtex-5	273	1163	7.8	6.06
[9]	1	1	Virtex-6	413.77	1432	9.93	6.93
[9]	12	1	Virtex-6	57.91	15,579	16.67	1.07
[28]	2	1 (* 2)	Virtex-6	344.62	1348	16.54	12.27

* Sub-pipelining.

and

Table 8. Straightforward implementations results.

Reference	Device	Frequency [MHz]	Area [Slices]	Throughput [Gbps]	Efficiency [Mbps/Slices]
[29]	Virtex-4	143	2024	6.07	3.0
[30]	Virtex-5	285	2573	5.7	2.21
[31]	Virtex-5	259	1370	10.77	7.69
[32]	Virtex-5	277	1236	6.64	5.37
[33]	Virtex-5	265	448	0.05	0.11
[33]	Virtex-5	122	1330	5.2	3.9
[34]	Virtex-5	137	1647	2.39	1.45
[35]	Virtex-5	271	1414	12.3	8.68
[14]	Virtex-5	317	4793	12.68	2.71
[36]	Virtex-5	189	1117	0.085	0.42
[37]	Virtex-5	277	1217	12.56	10.32
[38]	Virtex-5	248	134	0.25	1.16
[39]	Virtex-5	282	192	81.8	4.32
[40]	Virtex-5	520	151	0.501	3.32
[41]	Virtex-5	313	1304	7.51	5.75
[42]	Virtex-6	291	1015	6.99	6.89
[43]	Virtex-6	299	106	0.136	1.28
[44]	Virtex-6	286	1207	12.98	10.75
[2]	Virtex-6	328.15	1380	8400.64	2.45
[45]	Virtex-6	195	1048	8.830	8.42
[46]	Virtex-6	197	397	1.071	2.19
[47]	Virtex-6	311	91	0.203	2.23
[48]	Virtex-6	291	1.015	6.99	6.89
[49]	Virtex-6	285	188	0.077	0.41
[48]	Virtex-7	255	1.039	6.12	5.88
[50]	Virtex-7	299	983	7.17	7.27
[8]	Virtex-7	434	1618	20.8	12.9
[28]	Virtex-7	396	1452	19.021	13.10
[51]	Virtex-7	374	1454	7.979	5.49
[52]	Virtex-7	414	1418	16.58	11.97

both report the results gathered from the different works found in the state of the art.

The throughput of a hash function is evaluated as:

$$Throughput=\frac{(\#bits)\times Frequency}{c}$$

(6)

In Table 7, the cases in which the unfolding and pipelining/sub-pipelining techniques described in Section 4 are used are examined. In Table 8, on the other hand, the results obtained with straightforward implementations are reported.

Generally, when multiple throughput results are given, SHA3-512 is taken as a reference. However, many of the examples do not provide the results on the different instances of SHA3 or only provide the results of one of the primitives (which may not be the reference one). For further clarification on the type of primitive performed and the length of the input messages absorbed, please refer to the proper reference paper. Obviously, efficient implementation selection does not hinge solely on architectural design; it also depends on the particulard FPGA platform in use.

Based on the results of Table 7, sub-pipelining is observed to be effective in critical path reduction, while unrolling with pipelining enables simultaneous processing in the SHA-3 hash function [12]. In general, both of the techniques bring positive effects on the throughput performance. As previously stated, Table 8 shows the results obtained with straightforward implementations. Since these are standard implementations of the algorithm, and since we have previously described all of the possible implementations that are generally used in Section 3 and Section 4, more detailed descriptions of individual values are not given here. The Table is provided in order to be able to compare the different solutions.

The most relevant implementations mentioned in the previous sections are also reported in the plot of Figure 4, where the efficiency (expressed in terms of Mbit per second over the number of occupied slices) is shown together with the complexity (mentioned in terms of slices).

The utilization of distinct FPGA models—specifically Virtex 5, Virtex 6, and Virtex 7—clearly makes the whole comparison approximate. Each of these boasts slices corresponding to the same quantity of Lookup Tables (LUTs), which is set at four. However, the crux of the matter lies in the fact that, despite these FPGA models sharing an identical number of inputs, the LUTs within them possess varying numbers of outputs. Consequently, the findings presented in Figure 4 should be interpreted with caution, given the subtle yet consequential differences in LUT configurations across the three FPGA models under examination. Additional works exist that have not been incorporated into this analysis because they employed distinct FPGA architectures and evaluation metrics and were not included in this comparison table due to the complexities involved in conducting an equitable comparison with the other showcased studies.

In this application, power considerations are not typically the primary focus. Instead, the predominant emphasis lies in enhancing performance, encompassing throughput, latency, and frequency, alongside the resultant increase in area. Regrettably, relatively few studies delve into power analysis. Furthermore, comparing these sporadic power results proves challenging, as the analysis may occur post-synthesis, post-layout, or post-place and route, accounting for diverse environmental conditions and technology variations. Kundi et al. [53] propose a low-power SHA-3 design using an embedded digital signal processing slice on FPGA. Their compact design on Kintex-7 consumed 88 $\mathrm{m}\mathrm{W}$ of power which is 1/7th and 1/9th of the designs in [54] and [34], respectively. Ref. [55] presents the hardware implementation of a cryptographic accelerators suite, which comprises a SHA3 unit. Considering the post-synthesis power consumption on 7 $\mathrm{n}\mathrm{m}$ technology, the SHA3-unit consumes about 72 $\mathrm{m}\mathrm{W}$.

6.2. Integrated Solution

When defining integrated solutions, there are a series of slightly different metrics to be considered with respect to the stand-alone implementations. Cycle count is a measure of the complexity as well as the energy consumption of an implementation on a specific processor. It is also inversely proportional to the throughput, which describes how fast the algorithm works for a given clock frequency.

In [4], they develop an alternative solution for Keccak that presents a trade-off between performance and area. To avoid a high access rate to the main memory, the state is not split into multiple parts. However, instead of a standalone loosely coupled Keccak accelerator, they design a hardware accelerator for a single round of the Keccak permutation, using RISC-V Floating-Point Register Set (FPR) and a part of the General-Purpose Register Set (GPR). The performance is shown in

Table 9. Clock cycles performance.

Reference	Platform	Function	Software Version	Accelerated Version	Type
[4]	PULPino	SHAKE256	31,907	308	Tightly-coupled
[24]	PULPissimo	Keccak	26,529	1348	Loosely-coupled
[56]	LEON3	Keccak-512	188,708	100,663	ASIP

.

The results show that their design outperforms the uniform and binomial sampling of [57], which uses a loosely coupled high-performance Keccak implementation, which is able to calculate two Keccak rounds in one clock cycle. However, the large communication overhead poses a substantial drawback to their architecture. In [24], a Keccak accelerator is proposed to speed up SHA3 computations for post-quantum cryptographic algorithms on the RISCV-based advanced microcontroller PULPissimo (more information about the microcontroller can be found in [58]). Differently from the previous work, the accelerator is driven in a memory-mapped fashion style and attached to the SoC through an AXI plug. This makes the accelerator more versatile and easier to integrate than the previous ones but at the price of a higher overhead when data need to be exchanged from the processor to the accelerator. Ref. [56] describes an FPGA-based acceleration of SHA-3 on a 32-bit processor, supporting Keccak-224, Keccak-256, Keccak-384, and Keccak-512. The LEON3 processor has been used, achieving around an 87% reduction in execution cycles.

In [59], the Keccak performance on ARMv7-M has been optimized thanks to two kinds of optimizations: the first one consists of taking advantage of the inline barrel shifter in order to remove explicit rotations in the linear layer, and the second consists of a more efficient memory access scheduling to avoid pipeline hazards. Ref. [60] presents instead a hardware implementation of an SHA-3 Application-Specific Instruction Set Processor. A custom implementation of the 32-bit MIPS ISA is developed, where a subset of the MIPS instructions are implemented with the aid of Codasip Studio, and both the C-language compiler and the HDL design are generated and tested. Afterward, two ISEs are advanced to resolve the SHA-3 bottlenecks. Ref. [61] implements algorithm-specific ISEs based on finite state machines for address generation, Lookup Table integration, and extension of computational units through microcode instructions. Rawat et al. [16] propose a set of six custom instructions to support a broad range of Keccak-based cryptographic applications in the context of an ARMv7 micro-architecture. Since the results are reported in terms of instructions/byte for various Keccak modes, they are not inserted into

Table 10. Clock cycles/bytes performance.

Reference	Function	Processor	Clock Cycles/Bytes	Technique
[59]	SHA3-224	ARMv7-M4	72.4	ISE
	SHA3-256		77
	SHA3-384		97.9
	SHA3-512		138.4
[60]	SHA3	32-MIPS	137.9	Co-processor ISE
[61]	Keccak	PIC24	188	ISE

. It can be briefly commented that with SHA-3 (c = 1024), they obtain a speed-up of ×2.2.

7. Conclusions

In conclusion, this paper has undertaken a thorough and insightful journey into the world of SHA-3 implementations, examining a diverse array of solutions across hardware, software, and hybrid domains. By critically evaluating their strengths, weaknesses, and performance metrics, we have contributed valuable knowledge to the field of modern cryptography. Our research has shed light on the critical factors that shape the selection and optimization of Keccak SHA-3 implementations, emphasizing computational efficiency, scalability, and flexibility in various use cases. Through a meticulous analysis of speed and resource utilization, we have provided a comprehensive view of how these implementations fare in real-world scenarios.

The outcomes of this study have far-reaching implications, enhancing the understanding of cryptographic systems and facilitating the design and deployment of efficient solutions. Professionals and researchers alike are now better equipped to make informed decisions when navigating the intricate landscape of SHA-3 implementations, ultimately contributing to the advancement of secure and resilient cryptographic practices.

As the realm of cryptography continues to evolve, our commitment to rigorous evaluation and informed decision-making remains paramount. This research stands as a testament to our dedication to strengthening the foundations of cryptographic knowledge, ensuring that we continue to safeguard the digital world with ever more robust and efficient cryptographic solutions.