Fast and Efficient Hardware Implementation of HQC

Abstract

This work presents a hardware design for constant-time implementation of the HQC (Hamming Quasi-Cyclic) code-based key encapsulation mechanism. HQC has been selected for the fourth round of NIST’s Post-Quantum Cryptography standardization process and this work presents the first, hand-optimized design of HQC key generation, encapsulation, and decapsulation written in Verilog targeting implementation on FPGAs. The three modules further share a common SHAKE256 hash module to reduce area overhead. All the hardware modules are parametrizable at compile time so that designs for the different security levels can be easily generated. The design currently outperforms the other hardware designs for HQC, and many of the fourth-round Post-Quantum Cryptography standardization process, with one of the best time-area products as well. For the combined HighSpeed design targeting the lowest security level, we show that the HQC design can perform key generation in 0.09 ms, encapsulation in 0.13 ms, and decapsulation in 0.21 ms when synthesized for an Xilinx Artix 7 FPGA. Our work shows that when hardware performance is compared, HQC can be a competitive alternative candidate from the fourth round of the NIST PQC competition.

Appendices

Appendix 1.A Fast and Non-Biased (FNB) Fixed-Weight Vector Generation

Although the CWW design is constant in time, it does have a small bias. As an alternative, we propose a new FNB fixed-weight vector generation design which is based on fixed-weight vector generation technique given in [1]. Our FNB fixed-weight generation module can be parametrized to create design with an arbitrarily small probability of timing attack being possible. In our hardware module, have a parameter ACCEPTABLE_REJECTIONS, which can be used to specify how many indices could be rejected in either rejection sampling or in duplicated detection and still, the design will behave constant time. The parameter (ACCEPTABLE_REJECTIONS) can be set based on user’s target failure probability. If the actual failures are within the failure probability set by the selected parameter value, then the timing side channel given in [13] is not possible.

We use SHAKE256 module described in Sect. 2.1 to expand 320-bit seed to a $24 \times w$-bit string. Since the SHAKE256 module has 32-bit interface, the seed is loaded in 32-bit chunks, and the seed is stored in a BRAM. The 32-bit chunk from SHAKE256 is broken into 24-bit integer by preprocess unit and stored in the ctx_RAM then threshold check and reduction are performed. For the reduction, we use Barrett reduction [6]. Unlike the variable Barrett reduction discussed in Sect. 2.1.A, this specific Barrett reduction is optimized as we always reduce the inputs to a specific fixed value (n). After the reduction, the integer values (locations) are stored in a BRAM. Once the locations BRAM is filled, the duplicate detection module is triggered. The duplicate detection module helps detect potential duplicates values in the locations BRAM by traversing through all address locations and updating the value stored in a dual-ported BRAM. While the duplicate detection module checks for duplicates, the SHAKE256 module generates the next $24 \times w$-bit string to tackle any potential duplicates and stores them in another BRAM. This way, we can hide any clock cycles taken for seed expansion. Our hardware design uses a PRNG to generate the uniformly random bits required for the fixed weight vector generation from an input seed of length 320-bits. Our hardware design includes this PRNG in the form of SHAKE256 and assumes that the seed will be initialized by some other hardware module implementing a true random number generator. Our FNB fixed-weight generation module can be parametrized to create design with an arbitrarily small probability of timing attack being possible. In our hardware module, have a parameter name is ACCEPTABLE_REJECTIONS, which can be used to specify how many indices could be rejected, and still, the design will behave constant time (at the cost of extra area for more storage and extra cycles). The extra area is needed because we generate additional (based on parameter value) uniformly random bits in advance and store them in the a BRAM. The extra clock cycles are needed because even after we found the required number of indices that are under the threshold value, we still go over all the locations to maintain constant time behavior. For the duplicate detection logic inside the duplicate detection module, the control logic is programmed to take the same cycles in both cases of duplicate being detected or not. The parameter (ACCEPTABLE_REJECTIONS) can be set based on the user’s target failure probability. If the actual failures are within the failure probability set by the selected parameter value, then the timing side channel given in [13] is not possible.

Table 5 shows the comparison of our new FNB design to the CCW design. The area results shown in Table 5 exclude SHAKE256 module as the SHAKE256 is shared among all primitives. The reported frequency in Although the CWW algorithm ensures the constant time behavior in generating fixed-weight vectors, there is a small bias between the uniform distribution and the algorithm’s output. Meanwhile, for the new FNB algorithm, there is no bias. Further, FNB is faster than CWW, and the time-area product is better. These benefits come at the cost of extremely small probabilities that the design is not constant time, but only if it happens that there are more rejections than $w_r$. Table 5 shows that the probability of non-constant time behavior for FNB can be $2^{-200}$ or even smaller. To compute the failure probability (given in Table 5) for each parameter set, we take into account both threshold check failure and duplicate detection probabilities for the respective parameter sets.

Table 14. Comparison of the time and area of state-of-the-art hardware implementations of other (NIST PQC competition) round 4 KEM candidates.

Comparison to Hardware Designs for Other Round 4 Algorithms

We also provide Table 14 where we tabulate latest hardware implementations of all other post-quantum cryptographic algorithm hardware implementations from the fourth round of NIST’s standardization process, plus the to-be standardized Kyber algorithm. We focus on comparison of the hardware designs for lowest level of security, Level 1, as all publications give clear time and area numbers.