PQC-HA: A Framework for Prototyping and In-Hardware Evaluation of Post-Quantum Cryptography Hardware Accelerators

This research was funded by the German Federal Ministry for Education and Research (BMBF) with the funding ID 01IS17050.
This research work was supported by the National Research Center for Applied Cybersecurity ATHENE. ATHENE is funded jointly by the
German Federal Ministry of Education and Research and the Hessian Ministry of Higher Education, Research and the Arts

PQC-HA: Prototyping and Evaluating PQC Hardware Accelerators

Richard Sattel0009-0003-1060-3462
Christoph Spang0000-0003-1606-4474
Carsten Heinz0000-0001-5927-4426
Andreas Koch0000-0002-1164-3082

R. Sattel et al.
Embedded Systems and Applications Group, TU Darmstadt, Germany

{sattel, spang, heinz<EMAIL_ADDRESS>
In the third round of the pqc standardization project, the focus is on optimizing software and hardware implementations of candidate schemes. The winning schemes are CRYSTALS Kyber and CRYSTALS Dilithium, which serve as a kem and dsa, respectively.
This study utilizes the open-source framework to create hardware building blocks for both schemes using from minimally modified ANSI C software reference implementations across all security levels. Additionally, a generic host runtime application is developed in Rust to verify their functionality through the standard interface, utilizing the corresponding kat mechanism on actual hardware.
Building on this foundation, the communication overhead for hardware accelerators on pcie-connected FPGA devices is evaluated and compared with previous work and optimized avx2 software reference implementations. The results demonstrate the feasibility of verifying and evaluating the performance of Post-Quantum Cryptography accelerators on real hardware using . Furthermore, the off-chip accelerator communication overhead of the standard interface is measured, which, on its own, outweighs the execution wall clock time of the optimized software reference implementation of Kyber at Security Level 1.

§ INTRODUCTION

From the perspective of recent progress in the field of quantum computing,
the nist is setting out to standardize a set of algorithms for pqc
to replace the majority of public-key cryptography in use today that will become
insecure with the advent of large quantum computers leaving most
communication unprotected. The third round of this competition
elects CRYSTALS Kyber and CRYSTALS Dilithium as winners, for a kem and dsa respectively, with
a focus on
optimized software and hardware implementations.
The tapasco open-source
framework provides essential components to aid in the design process of these
hardware accelerators, such as a generic hardware architecture in addition to a
Linux kernel driver and userspace runtime library, which complement one another
to schedule jobs on pe<cit.>.
In this work, we present the basis for the integration of pqc building
blocks into the framework.
We use hls to transform the top-level functions of CRYSTALS Kyber and CRYSTALS Dilithium into
, which are hardware kernels containing logic to solve
a specific task.
We synthesize of all nist security levels for Encapsulation
and Decapsulation for Kyber as well as Sign and Verify for
The receive their parameters from a host runtime application
implemented in Rust using the standard nist interface, which is a set of
functions that each candidate of the needs to implement. It is used to test
the functional correctness of the via the nist
kat cases, which are in turn verified to be correct with upstream
repository hashes, to make sure
they generate the same results as the correct upstream reference software
implementation. To enable verification of algorithms that depend on random input data
deterministically and at the same time avoid using insecure rng units on
the fpga,
we extend the nist interface to supply the
with pre-initialized random buffers from the host.
The runtime provides generic functions for kem and
dsa algorithms and defines an extendable interface, which facilitates the
integration of further algorithms of the as long as they adhere
to the nist mandatory interface, optionally including the random buffer extension.
The rest of this work is organized as follows.
In <ref>, we discuss related work for and hdl implementations, which we will later compare to our implementations.
In <ref>, we define our approach.
We describe
how we use to create from the current software ANSI C reference implementation using the same
standard interface for parameters.

In <ref>, we present the results of our designs, compare
them to related work and analyze the communication overhead of the chosen
Finally, we conclude our work in <ref> and end with
subsequent ideas in <ref>.

§ RELATED WORK

§.§ HLS Implementations

In the prior work <cit.> and the follow-up publication
<cit.>, where the authors expand their results for signature
schemes but report results only for the Artix-7 platform,
present the implementation of multiple candidates in round two.
They also list updated results of resource usage, clock, and latency in tables on
their website <cit.> and publish some of their Vivado projects on
Github <cit.>.
our designs
with the results of this
work in

In <cit.>,
extend the nist standard interface with a random buffer to be supplied by
the host software application, which is an approach also used in this work.
They also present optimized hls designs for the Kyber512 variant of
CRYSTALS Kyber in round two, which at this point claimed a security Level of 1,
and report an improvement of 74.6% for the encapsulation and 54.4% for the
decapsulation compared to the prior work in <cit.>
for the lap × clock period metric.
We compare our results with this work in

§.§ HDL Implementations

In <cit.>,
evaluate existing hardware implementations for round three kem candidates.
They make a distinction between lightweight and
implementations and conclude that implementations are inferior both in
resource usage and performance compared to hdl implementations.
They present
new high-performance hdl designs for CRYSTALS Kyber, Saber, and NTRU
kem schemes, which they claim to
be the fastest concerning latency to date.
We compare our results with this work in

In <cit.>,
present new lightweight implementations of the CRYSTALS Dilithium
dsa scheme, of which they claim to make the most efficient use of resources,
surpassing the results of <cit.>.
They also publish their implementations as open-source, which makes
them a promising dsa candidate for integration in .
The authors of another high-performance Dilithium hdl implementation
<cit.> claim to beat this work in
terms of latency but require more resources, which is the reason why we choose
this work for comparison with our results in

§.§ TaPaSCo-related Work

In <cit.>,  present
multiple open-source cores made ready to use as . They
evaluate the performance of their designs in hardware utilizing the same Linux
kernel driver and runtime libraries as this work. This approach serves as an example, which we are
adapting for accelerators.
These could be extended with in-pipeline accelerators leveraging
hdl methodologies as in <cit.>.
On the contrary, communication with other standalone accelerators as presented
in this work is not implicitly supported, but requires to implement an individual interconnect feature.

§ APPROACH AND IMPLEMENTATION

In this section, we integrate accelerators in
. First, we discuss some preliminary considerations.
Then, we take the
ANSI C reference implementation of CRYSTALS Dilithium and CRYSTALS Kyber as a basis for .
Subsequently, we modify the
interface for Kyber to take a random buffer supplied by the host runtime.
we outline the key points in
the design of the host runtime application, which is developed
to test the designs through the mechanism.

Utilizing the framework means the functionality of our accelerators
is implemented in pe. A is a hardware kernel containing the
logic to solve a specific task. Usually a design is composed of
multiple , which are accompanied by generic components that are necessary to
control their usage such as a dma engine, an interrupt controller, and a status core, which stores meta-information about the design that is required by the Linux driver and runtime applications. In this work, we map each operation of a scheme, such as Encapsulation or Sign, to one
First, we need to define an interface to the that minimizes the amount of
data necessary to start the execution in order to overcome the memory wall.
The communication overhead is implementation-independent but an off-chip
accelerator should unite most functionality to reduce frequent transfers
from and to the general-purpose processor.
Most performance evaluations neglect to measure the impact of the
communication overhead for off-chip accelerators in a wall clock execution time
comparison with the
For our , we
measure the time necessary to move data from
and to the and compare it with the optimized avx2
implementation to set
the bottom line for a hardware accelerator.
We decide to use the standard interface consisting of
for kem and
This interface has the advantage concerning the memory communication overhead
that the parameters, such as keys and ciphertexts, are stored in compressed form, which
means it is the smallest data to transfer.
Another advantage concerning the host runtime is that all candidates of the are
conforming to this interface, only with different parameter sets. The wrappers around
can leverage Rust's const generics feature to be generic over the
actually used key sizes. This means if a parameter, like key size, is altered, the
change in the runtime implementation is trivial, and extending the runtime application for
other parameter sets of other candidates is straightforward.
In this work, we use 's hls interface in the version
of commit  from the  branch,
which in turn utilizes the Xilinx Vitis toolchain in version .
With the use of , we focus on larger high-performance because from the software reference implementations
is typically inadequate for smaller designs that can fit on iot-class devices <cit.>.
The devices used throughout this work are the Xilinx Virtex-7 VC709
and Xilinx Alveo U280.
The current ANSI C reference implementation of Dilithium <cit.>
is extended with a  for each of the top-level functions
and  on every security level.
exclude the keypair generation due to its dependence on a
secure rng, which is unavailable on the .
respective files
are located in the  repository in the  folder
Apart from meta information such as name, description, and ID, which should be adapted accordingly, only the  parameter  is necessary to change the security level.
on to CRYSTALS Kyber <cit.>,
software reference implementation <cit.>
is extended with a  for each of the top-level functions
and  on every security level.
The respective files
are located in the  repository in the  folder
Note, that the Kyber have the number of
the  parameter in their name, which has the values 2, 3 and 4 but
corresponds to security Levels 1, 3, and 5.
As for Dilithium,
only the
parameter  is necessary to change the security level.
It requires only one modification to
disable the call to the  function for successful compilation.
This function fills a buffer with bytes from the Linux rng,
which is necessary to create a secure shared secret and is not available on an
At this point, the
Kyber can generate ciphertexts from which the correct shared secret
can be recovered successfully but the buffer usually filled with secure random
data in software is left to consist of arbitrary uninitialized memory.
Therefore, the random buffer used on the is initialized from the random data on the host by using the same approach as <cit.>.
The function  is modified to receive
its buffer of random data via a new parameter, thereby moving its declaration
into the function signature, while the call to  is still disabled.
This change is guarded by the  conditional compilation
The runtime
the  given by the file
in the same manner as the official implementation to give the modified
Encapsulation the correctly initialized buffer of random data. With this
modification in place, the Kyber Encapsulation produces the same shared secret
and ciphertext as the software implementation and all Kyber are fully verified
in hardware.
verification is achieved with the use of response files (suffixed by ), generated from the software
reference implementation.
These can be found directly
in the  repository
The runtime first parses the appropriate file for the given algorithm and
security level to retrieve a list of usually 100 test cases.
The following procedure is the same for both kem and dsa
and generic over specific kem and dsa, to be easily extendable
when further
algorithms will be selected by .
The runtime passes the arguments from the test case to the associated with the
operation and receives its output, which is passed on to the associated with
the  operation. The outputs of both are compared with the
respective entries in the case and if all entries match, the test is passed.
This process is repeated for every
test case in the file.

§ EVALUATION

In this section, we
evaluate the results of the dse in <ref>. Then, we compare our results with related
work using and for an hdl methodology in
Finally, we contrast
this with a software implementation
and analyze the real-world communication overhead from the host runtime application to the in
We implement a bitstream for each of Kyber Encapsulation and Decapsulation and
Dilithium Sign and Verify for all security levels
on Xilinx  and Alveo  .
All produce correct results, which are verified by the host runtime application.
To measure execution time, the host runtime application is invoked 1000 times for each and software implementation. The and are fully connected over pcie 3.0
and the software runs on an
AMD EPYC 7443P
The average of 1000 runs is taken of all runs as in <cit.>.
report resource utilization of the user logic. This
excludes resources required by generic components of every design, such
as the dma engine, interrupt controller, and status core.

§.§ TaPaSCo DSE Results

PE Overview of Resource Usage vs. Design Frequency on U280 (left bars) and VC709 (right bars)

This section describes the results of the dse.
In <ref>, we plot the resource usage and
design frequency of each pe on the and platforms. From left to right each is shown as a triplet of an algorithm, security
level, and operation. The left half displays Kyber, and the right half Dilithium,
while security levels are increasing to the right and operations are
alternating. The left y-axis shows resource usage as the number of elements, where
each color represents another type. are given in red, in green,
are given as a multiple of thousand in orange, and also as a multiple of
thousand in blue. The bold black number on top of each bar shows the rounded total sum
of the elements used, where and enter the calculation as thousands. The left bar of each represents resource usage on the . The right bar shows resource usage on the platform. are given as
equivalents, and as  for both platforms. The right
y-axis shows the design frequency in MHz with a dotted line for and a dashed line for .
The resource usage trend across algorithms and operations is identical for both platforms. For both, the number of , , and is roughly the same, while the number of is consistently higher on . Concerning algorithms, we can see that Kyber uses fewer , and in general, than Dilithium, but required more . An interesting finding is that, while for Kyber with increasing security level usage of , and declines, the use of increases, with Kyber 5 Decapsulation having the highest usage of of all. For Dilithium resource usage increases moderately with the security level. With the exception of of Kyber 5, Decapsulation has less resource usage than Encapsulation and Verify less than Sign for Dilithium respectively.
Besides using less resources, the reaches almost 1.6 times the design frequency for Kyber and approximately 1.3 times for Dilithium compared to . Kyber achieves higher design frequencies with low variability between
different security levels and operations, while for Dilithium on a clear
distinction between Sign and Verify is visible. On Verify achieves
higher frequencies, but on it is Sign.
In general, we can see that the dse can yield optima of unexpectedly
high frequencies, such as Dilithium 3 Sign on , but also those lower
than usual, that is Dilithium 2 Sign on .
By utilizing the portability of designs, moving our to a
newer model can bring less resource usage while achieving higher design

Comparison of TaPaSCo Kyber and Dilithium PEs on Virtex-7 and Security Level 1 with related work using an HLS approach

§.§ Comparison with Related Work

In this section, we compare our implementations with the results of
related work. We first compare the of one scheme with related
work that also uses but reports only and for
security Level 1.
Then, we compare the of the same scheme with related work that uses an
hdl methodology across all security levels.
We use the dse results for because related work also reports results
for Virtex-7 or Artix-7 platforms, whereas the belongs to another generation
of .
We do not apply the lap as our primary metric because there is no clear
methodology how to weight different elements, that is are usually cheaper than
. Therefore we consider resources and latency side-by-side. Additionally, it is unclear
how the latency reports are generated in related work. It looks like the
hardware execution time is calculated by multiplying latency in the average case
with the design frequency, thus not including software overhead. Unfortunately,
Vivado does not report the estimated latency of our , which can nevertheless
vary a lot due to the algorithmic design of the schemes. The average latency can
be analyzed through simulation but for large designs this is slow and for
the amount of our therefore infeasible. Instead, we evaluate average
execution times in the next section from the software standpoint with the
runtime by measuring the execution time of our including
interrupt handling and memory communication overhead.

In <ref>, we compare our Kyber and Dilithium of security Level 1 on with the results of related work in
<cit.> on VC707 and <cit.> as well as <cit.> on .
We only compare and because the authors of related work do not
report their utilization of and .
From left to right, each implementation is displayed as a combination of
work/author, optimization level, and operation, where Encapsulation is compared
in the
first third,
Decapsulation in the
second third
and Sign and Verify in the last third.
The left y-axis shows
the number of elements used, where and are given as multiple of
thousand in blue and orange respectively. The right y-axis shows the mean
execution time measured in software for this work and calculated from latency
and frequency for related work in micro-seconds as a dashed line.
For Kyber, we observe that our designs use the least and the most for both
operations, with the lowest resource utilization in total. The reduced usage of
probably incurs the cost of more but related work does not report
numbers for their use of this element. However, while the
latency for Encapsulation is at the same level as the baseline implementation
from  and better than the baseline
implementation of , the latency for Decapsulation
is higher than those of all other implementations. However, their latency report
does not include overhead contained in the result for .
Employing the same optimizations as  would be
interesting but is not promising when compared to related work using an hdl
approach as seen in

For Dilithium,
we observe that our use fewer and more than the
implementations of  leading to a higher resource
utilization overall.
To conclude, this means that our approach with minimally modified C code is
more suited for Kyber than Dilithium to produce low resource utilization with
comparable latency but in general yields decent results compared to other
-based works.

Comparison of TaPaSCo Kyber PEs on Virtex-7 and related work from Dang et al. (HDL) on Artix-7

In <ref>, we compare our Kyber on all security levels with the results of related work in
From left to right, each is shown as a triplet of work/author, operation, and
security level. The left half displays our Kyber and the right half the
implementations from ,
while security levels are increasing to the right and operations are
alternating. The left y-axis shows resource usage as the number of elements in a
logarithmic scale, where
each color represents another type. are given as a multiple of thousand in
blue, also as a multiple of thousand in orange, in green and are
given in red. The right y-axis shows the mean execution time measured in
software for this work and calculated from latency and frequency for related
work in micro-seconds as a dashed line in a logarithmic scale.
This diagram affirms the conclusion of  that
implementations cannot keep up with hdl designs. Our have roughly a magnitude higher resource utilization, even though they are
specialized for each operation and their core is capable of both operations and
key generation for each security level. Finally, their latency/mean execution
time is also more than a magnitude lower but this still does not yield enough
performance to overcome the memory wall as we show in the next section.

Comparison of TaPaSCo Dilithium PEs on Virtex-7 and related work from Land et al. (HDL) on Artix-7

In <ref>, we compare our Dilithium on all security levels with the results of related work in
From left to right, each is shown as a triplet of work/author, operation, and
security level. The left half displays our Dilithium and the right half the
implementations from ,
while security levels are increasing to the right and the Sign operation is
shown first, Verification second.
The y-axis shows resource usage and mean execution time as in the last diagram
This diagram confirms the conclusion of  that
implementations cannot keep up with hdl designs for Dilithium too.
Our have roughly a magnitude higher resource utilization, even though they
are specialized for each operation and their core is capable of both operations
and key generation. Finally, their latency/mean execution time is also more than a magnitude lower. Yet, this does not yield enough performance to compete with the optimized avx2 implementation, as we will see in the next section.

§.§ Comparison of Execution Time against Software

Mean Execution Time of on U280 and avx2 Software Implementation on AMD Epyc

Communication Overhead of on U280 and Mean Execution Time in avx2 Software Implementation on AMD Epyc

In this section, we compare our results against the software implementations of
Kyber and Dilithium. As are standalone accelerators, we evaluate
the communication overhead introduced by the host and memories connected
through pcie 3.0
. We test under realistic conditions from the same application on the same host and also
include software interrupt handling overhead.

In <ref>, we compare the execution
time from the host runtime application with the optimized avx2
implementation running on the host cpu.
From left to right, all our implementations are listed as triplets of the algorithm,
security level, and the operation. The left half shows results for Kyber, the right
half for Dilithium. The y-axis shows the mean execution time in micro-seconds on a
logarithmic scale of both in blue bars and the avx2 software
implementation in orange bars.
We observe that the software implementation is roughly one magnitude faster than
the .

In <ref>, we compare the
communication overhead of the host runtime application with the
optimized avx2 Implementation running on the host cpu.
From left to right, all our implementations are listed as a triplet of algorithm,
security level, and operation. The left half shows results for Kyber, the right
half for Dilithium. The y-axis shows the mean execution time in nano-seconds on a
linear scale of the avx2 software
implementation in gray bars and the communication overhead for preparation of a
as blue and the release of a as orange bar stacked on top of each other.
Across all , the communication overhead is around/less than 10000.
Mean execution time in software increases generally with security level, while
for Kyber both operations have roughly the same value with Decapsulation only
slightly lower than Encapsulation, Dilithium varies greatly between signing and
We observe that for Kyber 1 Encapsulation the communication overhead alone is
almost as high as the effort to solve the original problem itself. For Kyber 1
Decapsulation the communication overhead alone is already higher than the
software implementation. For Kyber 3 the overhead takes up half of the software
implementation and for Kyber 5 approximately a third.
We conclude that using the architecture accelerating Kyber on security
Level 1 is impossible on the evaluated platform and even using the
state-of-the-art hdl accelerator from
would not be faster than the avx2 software implementation. The same holds
for the Dilithium implementation from , assuming
the same communication overhead for their interface when integrated into the
However, this only holds true if the only metric employed is latency. The
obvious next step to evaluate throughput on high-performance devices is
to look at pipelining. Other scaling mechanisms such as using multiple concurrently in a cluster are also possible and can be combined with multi-potent
hdl designs, where each can perform all operations of the
scheme, key generation, encapsulation, and decapsulation for a
kem, and executes the desired operation according to the current demand.
Accumulating multiple outstanding memory requests could also result in a benefit
concerning the communication overhead and lower overhead could in turn increase
throughput again.
Finally, regarding these results for high-performance standalone accelerators, it would be
interesting to see more in-pipeline accelerators like those of
<cit.> but for high-performance cpus.

§ CONCLUSION

We integrated the software implementations of two algorithms from the into a generic runtime utilizing the features of via hls. We present a bitstream for CRYSTALS Kyber and Dilithium on all
three security levels for Encapsulation/Sign and
Decapsulation/Verify. Our approach leads to designs with
comparable resource utilization and performance to baseline results of
related work also using while achieving a higher design
frequency as a result of the .
They are verified in hardware to produce the same correct
results as the software implementation through the mechanism.
This straightforward methodology is adequate to develop a host runtime
application and evaluate the interface including the corresponding
communication overhead but is clearly inferior in terms of resource utilization
and performance compared to hdl designs of related work.
We demonstrate portability by synthesizing
the same designs for and , thereby
gaining faster designs while lowering resource utilization.
We analyze the communication overhead for standalone memory-mapped accelerators
and conclude that by utilizing the architecture, there is only a tight
window for speeding up Kyber against the optimized reference avx2
implementation. For Kyber on security Level 1, the communication overhead is even as high
as the time necessary to solve the operation in software. The window for
Dilithium is larger, especially for the Sign operation, but assuming the same
overhead, it is questionable if even state-of-the-art hdl implementations
could beat the optimized software implementation in the high-performance domain.

To wrap up, can aid with the design process by using its architecture and
shines in testing of accelerators on real hardware utilizing its Linux kernel
driver and our generic runtime. For the specifically, the ANSI C reference
implementations are straightforward to integrate into the ecosystem via
but this does not replace the hdl methodology.

§ FUTURE WORK

With the foundation for accelerators laid in this work, there are
multiple promising ways for further exploration.
existing hardware implementations that are published as open-source can be
integrated in the architecture, where lightweight designs open the
possibility to make use of the diverse device support for
smaller . There, the communication overhead can be re-evaluated on
embedded platforms that use a different memory architecture, such as shared memory
on the Ultra96
, and compared to the optimized software implementations of
other cpu isa, Neon ntt <cit.>
on ARM.
Finally, the -based approach as shown in this work can be applied
to other, more unexplored, alternate candidates of the for the next round,
where all components, including the host runtime application can be
re-used because all candidates are required to conform to the same interface.

Missing 'biblatex' package
The bibliography requires the 'biblatex' package.

abstractExperts forecast that quantum computers can break classical cryptographic algorithms. Scientists are developing post quantum cryptographic (PQC) algorithms, that are invulnerable to quantum computer attacks. The National Institute of Standards and Technology (NIST) started a public evaluation process to standardize quantum-resistant public key algorithms. The objective of our study is to provide a hardware comparison of the NIST PQC competition candidates. For this, we use a High-Level Synthesis (HLS) hardware design methodology to map high-level C specifications of selected PQC candidates into both FPGA and ASIC implementations.
titleNIST Post-Quantum Cryptography – A Hardware Evaluation Study
Hardware Implementation,Post-Quantum Cryptography,Meta Evaluation,Important,is_fully_read,DILITHIUM,qTESLA

abstractWe present new speed records on the Armv8-A architecture for the lattice-based schemes Dilithium, Kyber, and Saber. The core novelty in this paper is the combination of Montgomery multiplication and Barrett reduction resulting in “Barrett multiplication” which allows particularly efficient modular one-known-factor multiplication using the Armv8-A Neon vector instructions. These novel techniques combined with fast two-unknown-factor Montgomery multiplication, Barrett reduction sequences, and interleaved multi-stage butterflies result in significantly faster code. We also introduce “asymmetric multiplication” which is an improved technique for caching the results of the incomplete NTT, used e.g. for matrix-to-vector polynomial multiplication. Our implementations target the Arm Cortex-A72 CPU, on which our speed is 1.7× that of the state-of-the-art matrix-to-vector polynomial multiplication in Kyber [Nguyen–Gaj 2021]. For Saber, NTTs are far superior to Toom–Cook multiplication on the Armv8-A architecture, outrunning the matrix-to-vector polynomial multiplication by 2.1×. On the Apple M1, our matrix-vector products run 2.1× and 1.9× faster for Kyber and Saber respectively.
shorttitleNeon NTT
titleNeon NTT: Faster Dilithium, Kyber, and Saber on Cortex-A72 and Apple M1
Software Implementation,Promising,implementation,Kyber,NIST PQC,Saber,Armv8-A,Dilithium,Neon

abstractMany currently deployed public-key cryptosystems are based on the difficulty of the discrete logarithm and integer factorization problems. However, given an adequately sized quantum computer, these problems can be solved in polynomial time as a function of the key size. Due to the future threat of quantum computing to current cryptographic standards, alternative algorithms that remain secure under quantum computing are being evaluated for future use. One such algorithm is CRYSTALS-Dilithium, a lattice-based digital signature scheme, which is a finalist in the NIST Post Quantum Cryptography (PQC) competition. As a part of this evaluation, high-performance implementations of these algorithms must be investigated. This work presents a high-performance implementation of CRYSTALS-Dilithium targeting FPGAs. In particular, we present a design that achieves the best latency for an FPGA implementation to date. We also compare our results with the most-relevant previous work on hardware implementations of NIST Round 3 post-quantum digital signature candidates.
titleHigh-Performance Hardware Implementation of CRYSTALS-Dilithium
digital signatures,FPGA,hardware implementations,implementation,Post-Quantum Cryptography,public-key cryptography

abstractRapid advances in quantum computing, together with the announcement by the National Institute of Standards and Technology (NIST) to define new standards for digital-signature, encryption, and key-establishment protocols, have created significant interest in post-quantum cryptographic schemes. This paper introduces Kyber (part of CRYSTALS – Cryptographic Suite for Algebraic Lattices – a package submitted to NIST post-quantum standardization effort in November 2017), a portfolio of post-quantum cryptographic primitives built around a key-encapsulation mechanism (KEM),based on hardness assumptions over module lattices. Our KEM is most naturally seen as a successor to the NewHope KEM (Usenix 2016). In particular, the key and ciphertext sizes of our new construction are about half the size, the KEM offers CCA instead of only passive security, the security is based on a more general (and flexible) lattice problem, and our optimized implementation results in essentially the same running time as the aforementioned scheme. We first introduce a CPA-secure public-key encryption scheme, apply a variant of the Fujisaki–Okamoto transform to create a CCA-secure KEM, and eventually construct, in a black-box manner, CCA-secure encryption, key exchange, and authenticated-key-exchange schemes. The security of our primitives is based on the hardness of Module-LWE in the classical and quantum random oracle models, and our concrete parameters conservatively target more than $128$ bits of post-quantum security.
shorttitleCRYSTALS – Kyber
titleCRYSTALS – Kyber: a CCA-secure module-lattice-based KEM
KEM,KYBER,implementation,lattice techniques,public-key cryptography,Specification

abstractPerformance in hardware has typically played a significant role in differentiating among leading candidates in cryptographic standardization efforts. Winners of two past NIST cryptographic contests (Rijndael in case of AES and Keccak in case of SHA-3) were ranked consistently among the two fastest candidates when implemented using FPGAs and ASICs. Hardware implementations of cryptographic operations may quite easily outperform software implementations for at least a subset of major performance metrics, such as latency, number of operations per second, power consumption, and energy usage, as well as in terms of security against physical attacks, including side-channel analysis. Using hardware also permits much higher flexibility in trading one subset of these properties for another. This paper presents high-speed hardware architectures for four lattice-based CCA-secure Key Encapsulation Mechanisms (KEMs), representing three NIST PQC finalists: CRYSTALS-Kyber, NTRU (with two distinct variants, NTRU-HPS and NTRU-HRSS), and Saber. We rank these candidates among each other and compare them with all other Round 3 KEMs based on the data from the previously reported work.
titleHigh-Speed Hardware Architectures and FPGA Benchmarking of CRYSTALS-Kyber, NTRU, and Saber
FPGA,hardware implementations,implementation,Key Encapsulation Mechanism,lattice-based,Post-Quantum Cryptography,public-key cryptography

abstractEmpowering electronic devices to support Post-Quantum Cryptography (PQC) is a challenging task. PQC introduces new mathematical elements and operations which are usually not easy to implement on standard processors. Especially for low cost and resource constraint devices, hardware acceleration is usually required. In addition, as the standardization process of PQC is still ongoing, a focus on maintaining flexibility is mandatory. To cope with such requirements, hardware/software co-design techniques have been recently used for developing complex and highly customized PQC solutions. However, while most of the previous works have developed loosely coupled PQC accelerators, the design of tightly coupled accelerators and Instruction Set Architecture (ISA) extensions for PQC have been barely explored. To this end, we present RISQ-V, an enhanced RISC-V architecture that integrates a set of powerful tightly coupled accelerators to speed up lattice-based PQC. RISQ-V efficiently reuses processor resources and reduces the amount of memory accesses. This significantly increases the performance while keeping the silicon area overhead low. We present three contributions. First, we propose a set of powerful hardware accelerators deeply integrated into the RISC-V pipeline. Second, we extended the RISC-V ISA with 29 new instructions to efficiently perform operations for lattice-based cryptography. Third, we implemented our RISQ-V in ASIC technology and on FPGA. We evaluated the performance of NewHope, Kyber, and Saber on RISQ-V. Compared to the pure software implementation on RISC-V, our co-design implementations show a speedup factor of up to 11.4 for NewHope, 9.6 for Kyber, and 2.7 for Saber. For the ASIC implementation, the energy consumption was reduced by factors of up to 9.5 for NewHope, 7.7 for Kyber, and 2.1 for Saber. The cell count of the CPU was increased by a factor of 1.6 compared to the original RISC-V design, which can be considered as a moderate increase for the achieved performance gain.
titleRISQ-V: Tightly Coupled RISC-V Accelerators for Post-Quantum Cryptography
Hardware Implementation,Software Implementation,Promising,is_fully_read,lattice-based cryptography,Post-quantum cryptography,public-key cryptography,RISC-V,IoT,instruction set extension

abstractThe integration of FPGA-based accelerators into a complete heterogeneous system is a challenging task faced by many researchers and engineers, especially now that FPGAs enjoy increasing popularity as implementation platforms for efficient, application-specific accelerators for domains such as signal processing, machine learning and intelligent storage. To lighten the burden of system integration from the developers of accelerators, the open-source TaPaSCo framework presented in this work provides an automated toolflow for the construction of heterogeneous many-core architectures from custom processing elements, and a simple, uniform programming interface to utilize spatially distributed, parallel computation on FPGAs. TaPaSCo aims to increase the scalability and portability of FPGA designs through automated design space exploration, greatly simplifying the scaling of hardware designs and facilitating iterative growth and portability across FPGA devices and families. This work describes TaPaSCo with its primary design abstractions and shows how TaPaSCo addresses portability and extensibility of FPGA hardware designs for systems-on-chip. A study of successful projects using TaPaSCo shows its versatility and can serve as inspiration and reference for future users, with more details on the usage of TaPaSCo presented in an in-depth case study and a short overview of the workflow.
issn1939-8018, 1939-8115
journaltitleJournal of Signal Processing Systems
shortjournalJ Sign Process Syst
shorttitleThe TaPaSCo Open-Source Toolflow
titleThe TaPaSCo Open-Source Toolflow: for the Automated Composition of Task-Based Parallel Reconfigurable Computing Systems
8X29W4D/Heinz et al. - 2021 - The TaPaSCo Open-Source Toolflow for the Automate.pdf:application/pdf

Cancun, Mexico

abstractWith the increasing popularity of RISC-V in the academic and industrial world, an ever growing number of open-source implementations of the instruction set have become available. However, it is not an easy task to compare the cores to one another, as they employ different interconnects, build systems and so on.
booktitle2019 International Conference on ReConFigurable Computing and FPGAs (ReConFig)
titleA Catalog and In-Hardware Evaluation of Open-Source Drop-In Compatible RISC-V Softcore Processors
ardware Evaluation of Open-Sourc.pdf:/home/omega/Zotero/storage/XJBM28QD/Heinz et al. - 2019 - A Catalog and In-Hardware Evaluation of Open-Sourc.pdf:application/pdf

abstractCRYSTALS-Dilithium as a lattice-based digital signature scheme has been selected as a finalist in the PQC standardization process of NIST. As part of this selection, a variety of software implementations have been evaluated regarding their performance and memory requirements for platforms like x86 or ARM Cortex-M4. In this work, we present a first set of FPGA implementations for the low-end Xilinx Artix-7 platform, evaluating the peculiarities of the scheme in hardware, reflecting all available round-3 parameter sets. As a key component in our analysis, we present results for a specifically adapted NTT core for the Dilithium cryptosystem, optimizing this component for an optimal LUT and FF utilization by efficient use of special purpose DSPs. Presenting our results, we aim to shed further light on the performance of lattice-based cryptography in low-cost and high-throughput configurations and their respective potential use-cases in practice.
titleA Hard Crystal - Implementing Dilithium on Reconfigurable Hardware
Hardware Implementation,Promising,DILITHIUM,DSA,implementation,FPGA Dilithium PQC

abstractIn July 2020, the lattice-based CRYSTALS-Dilithium digital signature scheme has been chosen as one of the three third-round finalists in the post-quantum cryptography standardization process by the National Institute of Standards and Technology (NIST). In this work, we present the first Very High Speed Integrated Circuit Hardware Description Language (VHDL) implementation of the CRYSTALS-Dilithium signature scheme for Field-Programmable Gate Arrays (FPGAs). Due to our parallelization-based design requiring only low numbers of cycles, running at high frequency and using reasonable amount of hardware resources on FPGA, our implementation is able to sign 15832 messages per second and verify 10524 signatures per second. In particular, the signing algorithm requires 68461 Look-Up Tables (LUTs), 86295 Flip-Flops (FFs), and the verification algorithm takes 61738 LUTs and 34963 FFs on Virtex 7 UltraScale+ FPGAs. In this article, experimental results for each Dilithium security level are provided and our VHDL-based implementation is compared with related High-Level Synthesis (HLS)-based implementations. Our solution is ca 114 times faster (in the signing algorithm) and requires less hardware resources.
titleImplementing CRYSTALS-Dilithium Signature Scheme on FPGAs
Hardware Implementation,Promising,DILITHIUM,DSA,implementation,NTT,Post-quantum cryptography,Digital signatures,FPGA implementation,Number-theoretic transform,VHDL

abstractdeepraj88 has 18 repositories available. Follow their code on GitHub.
titledeepraj88 - Overview

shorttitleNIST Round 2 PQCs
titleNIST Round 2 PQCs: FPGA Implementations – Hardware Assessment of NIST Post Quantum Crypto

Springer International Publishing

titleHardware Architectures for Post-Quantum Digital Signature Schemes
i.pdf:/home/omega/Zotero/storage/7DB5IPI3/Soni et al. - 2021 - Hardware Architectures for Post-Quantum Digital Si.pdf:application/pdf

abstractPublic key cryptography is important in the global communication digital infrastructure. However, the emergence of quantum computer and Shor algorithm has greatly threatened the security of public key cryptography. The CRYSTALS-KYBER, as a lattice-based KEM algorithm, passed three rounds of a global solicitation for post-quantum cryptography algorithms held by the National Institute of Standards and Technology (NIST). This paper explores the implementation and optimization space of hardware design according to CRYSTALS-KYBER algorithm. We analyze its software code and try different strategies to optimize the hardware implementation, and conduct comparative analysis in terms of area and speed. The experimental results show that the performance can be greatly improved by moderately optimizing the loops. In comparison with optimal results of the work [12], our optimizations improve the performance by up to 74.6% for encapsulation algorithm and 54.4% for decapsulation algorithm.
booktitle2020 IEEE 29th Asian Test Symposium (ATS)
noteISSN: 2377-5386
titleOptimization Space Exploration of Hardware Design for CRYSTALS-KYBER
otero/storage/39FIXLZ3/Zhao et al. - 2020 - Optimization Space Exploration of Hardware Design .pdf:application/pdf
y,Encapsulation,Hardware,HLS,Optimization,Pipeline processing,Public key cryptography,Space exploration

List of all with design frequency and resource utilization

Algorithm     Platform     Security Level     Operation     PE Name     Functionality     Frequency [MHz]     kLUTs     kFFs     BRAM     DSPs

0     Kyber     VC709     1     Encapsulate     kyber2_enc     Working     265     63.329000     68.883000     29.500000     143.000000

1     Kyber     VC709     1     Decapsulate     kyber2_dec     Working     280     44.488000     53.918000     27.500000     201.000000

2     Kyber     VC709     3     Encapsulate     kyber3_enc     Working     275     55.982000     59.783000     28.500000     143.000000

3     Kyber     VC709     3     Decapsulate     kyber3_dec     Working     274     36.704000     43.616000     26.500000     201.000000

4     Kyber     VC709     5     Encapsulate     kyber4_enc     Working     262     56.166000     60.297000     28.500000     175.000000

5     Kyber     VC709     5     Decapsulate     kyber4_dec     Working     250     37.864000     47.445000     26.500000     243.000000

6     Kyber     AU280     1     Encapsulate     kyber2_enc     Working     440     64.900000     54.792000     28.500000     137.000000

7     Kyber     AU280     1     Decapsulate     kyber2_dec     Working     450     45.038000     40.858000     26.500000     193.000000

8     Kyber     AU280     3     Encapsulate     kyber3_enc     Working     450     57.164000     48.447000     27.000000     137.000000

9     Kyber     AU280     3     Decapsulate     kyber3_dec     Working     450     37.307000     33.600000     25.000000     193.000000

10     Kyber     AU280     5     Encapsulate     kyber4_enc     Working     440     57.745000     48.585000     27.000000     169.000000

11     Kyber     AU280     5     Decapsulate     kyber4_dec     Working     430     39.127000     35.664000     24.500000     235.000000

12     Dilithium     VC709     2     Sign     dilithium2_sign     Deadlock     177     81.877000     94.875000     29.500000     108.000000

13     Dilithium     VC709     2     Verify     dilithium2_verify     Working     220     64.537000     72.207000     20.500000     59.000000

14     Dilithium     VC709     3     Sign     dilithium3_sign     Working     209     82.336000     94.028000     40.000000     106.000000

15     Dilithium     VC709     3     Verify     dilithium3_verify     Working     230     64.691000     72.448000     26.500000     57.000000

16     Dilithium     VC709     5     Sign     dilithium5_sign     Working     190     86.601000     97.852000     45.500000     106.000000

17     Dilithium     VC709     5     Verify     dilithium5_verify     Working     215     64.569000     72.445000     32.000000     57.000000

18     Dilithium     AU280     2     Sign     dilithium2_sign     Deadlock     320     80.943000     77.604000     29.000000     108.000000

19     Dilithium     AU280     2     Verify     dilithium2_verify     Working     300     62.922000     56.764000     20.000000     59.000000

20     Dilithium     AU280     3     Sign     dilithium3_sign     Working     365     81.262000     75.504000     39.000000     106.000000

21     Dilithium     AU280     3     Verify     dilithium3_verify     Working     300     63.204000     56.795000     25.500000     57.000000

22     Dilithium     AU280     5     Sign     dilithium5_sign     Working     310     85.421000     79.031000     43.000000     106.000000

23     Dilithium     AU280     5     Verify     dilithium5_verify     Working     300     62.857000     56.795000     29.500000     57.000000

List of all with mean execution time and communication overhead

Algorithm     Platform     Security Level     Operation     PE Name     Functionality     Frequency [MHz]     PE Start [ns]     PE Wait [ns]     PE Release [ns]     Mean Duration [$\mu$s]

0     Kyber     VC709     1     Encapsulate     kyber2_enc     Working     265     33879.021000     625722.209000     24261.589000     683.862819

1     Kyber     VC709     1     Decapsulate     kyber2_dec     Working     280     38860.905000     927236.989000     17254.458000     983.352352

2     Kyber     VC709     3     Encapsulate     kyber3_enc     Working     275     39136.417000     908713.685000     23993.971000     971.844073

3     Kyber     VC709     3     Decapsulate     kyber3_dec     Working     274     36845.543000     1353062.283000     14922.066000     1404.829892

4     Kyber     VC709     5     Encapsulate     kyber4_enc     Working     262     33415.510000     1300124.540000     21841.251000     1355.381301

5     Kyber     VC709     5     Decapsulate     kyber4_dec     Working     250     40440.257000     2036665.064000     16949.798000     2094.055119

6     Kyber     AU280     1     Encapsulate     kyber2_enc     Working     440     43271.507000     320968.749000     42768.400000     407.008656

7     Kyber     AU280     1     Decapsulate     kyber2_dec     Working     450     38101.868000     505237.785000     19285.876000     562.625529

8     Kyber     AU280     3     Encapsulate     kyber3_enc     Working     450     46614.493000     463630.703000     46358.170000     556.603366

9     Kyber     AU280     3     Decapsulate     kyber3_dec     Working     450     44759.069000     717163.692000     20182.781000     782.105542

10     Kyber     AU280     5     Encapsulate     kyber4_enc     Working     440     47224.161000     635546.020000     45309.562000     728.079743

11     Kyber     AU280     5     Decapsulate     kyber4_dec     Working     430     46826.185000     1036884.439000     20067.314000     1103.777938

12     Dilithium     VC709     2     Sign     dilithium2_sign     Deadlock     177     49764.787000     29582405.304000     43248.174000     29675.418265

13     Dilithium     VC709     2     Verify     dilithium2_verify     Working     220     37304.096000     2728635.281000     29307.401000     2795.246778

14     Dilithium     VC709     3     Sign     dilithium3_sign     Working     209     45576.437000     25517599.169000     38890.637000     25602.066243

15     Dilithium     VC709     3     Verify     dilithium3_verify     Working     230     40676.377000     3705498.223000     27473.324000     3773.647924

16     Dilithium     VC709     5     Sign     dilithium5_sign     Working     190     44947.777000     32771644.154000     42263.676000     32858.855607

17     Dilithium     VC709     5     Verify     dilithium5_verify     Working     215     40420.255000     5532179.863000     27110.452000     5599.710570

18     Dilithium     AU280     2     Sign     dilithium2_sign     Deadlock     320     56567.794000     23444002.396000     64092.834000     23564.663024

19     Dilithium     AU280     2     Verify     dilithium2_verify     Working     300     50752.353000     1660295.248000     51009.036000     1762.056637

20     Dilithium     AU280     3     Sign     dilithium3_sign     Working     365     55028.980000     12932134.169000     60011.130000     13047.174279

21     Dilithium     AU280     3     Verify     dilithium3_verify     Working     300     52756.371000     2334493.162000     51142.836000     2438.392369

22     Dilithium     AU280     5     Sign     dilithium5_sign     Working     310     57123.034000     17644266.313000     61795.863000     17763.185210

23     Dilithium     AU280     5     Verify     dilithium5_verify     Working     300     52060.355000     3220930.649000     52414.143000     3325.405147