Just-in-time post-quantum cryptography (PQC) key expansion

The aspects described herein generally relate to the use of secure data communications and, more particularly, to the use of a secure communications that utilize a key expansion process that may be implemented for post-quantum cryptography (PQC) with increased efficiency.

Public-Key Cryptography (PKC) is an essential part of modern security concepts, and is used in a variety of automotive applications such as key exchange and software update verification. However, the security assumptions of current PKC algorithms, such as the Rivest-Shamir-Adleman cryptosystem and Elliptic-Curve Cryptography (ECC), no longer hold once sufficiently large quantum computers become available. For this reason, considerable effort has been made to find successors to the cryptographic algorithms that are also secure against malicious attacks via quantum computers.

To consolidate these efforts, PQC algorithms have been developed such as CRYSTALS-KYBER for key-encapsulation mechanisms (KEM), as well as CRYSTALS-DILITHIUM, FALCON, and SPHINCS+ for Digital Signature Algorithms (DSAs). The security of CRYSTALS-KYBER, CRYSTALS-DILITHIUM, and FALCON (as well as other conventional PQC algorithms e.g. NTRU and SABER) is based on mathematical problems related to (module-) lattices, and offer a good trade-off between performance, key size, and security. However, the public and private key, as well as the ciphertext/signature that are used for PQC algorithms, are still considerably larger than those used for current PKC algorithms. This issue is further complicated when considering the need for storage of intermediate values in the several schemes, e.g., CRYSTALS-KYBER and CRYSTALS-DILITHIUM, since parts of the key are expanded from a seed and increase in size significantly. This is particularly an issue in embedded applications and, in particular, in dedicated HW accelerators, as the additional memory and configuration overhead become very costly.

The example aspects of the present disclosure will be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.

Again, the conventional architectures used in conjunction with the execution of PQC algorithms have various drawbacks, particularly with respect to the processing power, memory, overhead, and time required to generate the expanded keys. For instance, a conventional PQC algorithm functions to receive a seed as an input and then uses this seed to generate an expanded key. Doing so requires the use of an additional amount of memory equal to the entire size of the expanded key, which may be orders of magnitude larger than that of the seed.

The embodiments provided herein address these issues by providing a more efficient means of key expansion for use in various cryptographic algorithms. Specifically, and as further discussed below, architectures are disclosed for both an accelerator and an expander, which may be implemented in accordance with any suitable type of cryptographic algorithm that utilizes key expansion, such as PQC algorithms, a key encapsulation mechanism (KEM) algorithm, a Digital Signature Algorithm (DSA), etc. The accelerator architecture enables portions of the expanded key to be generated by a processing block only when required, and allows for the reuse of memory to reduce memory size and thus provide a smaller footprint (i.e. physical size) compared to conventional architectures. Furthermore, the embodiments discussed herein are directed to an improved expander architecture, which reduces the required interactions and data transfers between the processing block and the expander, thereby reducing the load on the processing block and system components, such as shared busses and bridges.

In the following description, numerous specific details are set forth to provide a thorough understanding of the aspects of the present disclosure. However, it will be apparent to those skilled in the art that the aspects, including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the disclosure.

I. Technology Overview: POC Accelerator Architecture

1 FIG. 1 FIG. 100 100 102 104 106 108 108 102 108 108 108 1 106 illustrates a block diagram of a conventional PQC accelerator architecture. The PQC architectureas shown inillustrates an example key expansion process that is conventionally used by various PQC algorithms. To do so, the PQC architectureincludes a PQC accelerator, which comprises an expander block, a memory, and a processing block. The processing blockmay comprise processing logic, processing circuitry, etc., configured to execute one or more predetermined functions in accordance with the particular algorithm for which the PQC acceleratoris configured to operate. For instance, the processing blockmay be configured to perform verification (e.g. for the purposes of authentication), encryption, decryption, etc., with respect to a received message or ciphertext, as the case may be. The processing blockmay thus facilitate the performance of various “primitives” in accordance with the various cryptographic functions that are executed. For example, for a Digital Signature Algorithm (DSA), such primitives may comprise key generation, signing, and verification. As another example, for a key encapsulation mechanism (KEM), such primitives may comprise key generation, encapsulation or encryption, decapsulation or decryption, etc. To perform these functions, the processing blockaccesses the expanded key (key partexpanded) from the memoryand uses the expanded key for these functions.

104 1 1 2 102 104 108 1 FIG. To generate the expanded key, the expandermay comprise hardware circuitry configured to execute predetermined expansion functions on a received seed value, which is shown inas a portion (key part) of a larger key that comprises key partand key part. Thus, the predetermined expansion function may be executed in accordance with a specific type of PQC algorithm. For example, the PQC acceleratormay be implemented as a SHAKE-128 HW accelerator, and the expanderand processing blockmay execute their respective functions in accordance with the SHAKE-128 based functions.

1 FIG. 104 1 106 106 106 104 108 104 108 106 106 As shown in, the expanderreceives a seed (i.e. key part) at its input and generates an expanded key, which is stored in the memory. Using this conventional approach, the memoryis required to be of a size that is capable of storing the entirety of the expanded key, even when the memoryis shared by the expanderand the processing block. In other words, the conventional PQC accelerator architecture utilizes the expanderand processing block, which do not implement additional internal memory to store the expanded key. Thus, such solutions require the addition of the memory, which needs to be large enough to store the expanded key values. This requirement for the memorylimits the application of such conventional PQC accelerator architectures, particularly with respect to small, low cost, and/or embedded applications.

To better illustrate this issue, an illustrative example is provided for CRYSTALS-DILITHIUM, which is a digital signature scheme that is strongly secure under chosen message attacks based on the “hardness” of lattice problems over module lattices. The security notion means that an adversary having access to a signing oracle cannot produce a signature of a message whose signature has not yet been seen, nor produce a different signature of a message that has already been observed in the signed state. CRYSTALS-DILITHIUM was selected as a winner of a recent competition of candidate algorithms submitted to the National Institute of Standards and Technology (NIST) post-quantum cryptography project, and is now in the process of becoming a new standard. Sec https://csrc.nist.gov/Projects/post-quantum-cryptography/selected-algorithms-2022.

q i,j n The following example is provided for case of explanation with respect to the verification subroutine of the CRYSTALS-DILITHIUM signature scheme. However, it is noted that the following also applies to other suitable schemes. The example process is also simplified for case of explanation and to highlight the relevant steps. For instance, to perform a verification of a signature σ=(z,c) for the message M using the public key pk:=(ρ, t), the most important step is the computation of w:=Az−ct. Here, A∈is a matrix over a polynomial ring R=[X]\(X+1), which is generated by expanding each entry via a=Expand(ρ,i,j). As an illustrative example, for the parameters considered in the official submission of CRYSTALS-DILITHIUM, each element in this polynomial ring is of degree n=256 and each of these coefficients is an integer<q with q=8380417, which can be represented by 23 bits as 8380417 is slightly less than the full range of 2{circumflex over ( )}23−1 that could be covered by a 23-bit integer.

1 106 1 FIG. Thus, using the parameters suggested in the official submission as an example, the public key is a combination of ρ and t. Thus, the “key part” that is shown inand further discussed herein with respect to the other Figures refers to ρ, as the public key is represented by 32 bytes (the size of ρ) plus 2560 bytes (the size of t). However, when expanding the entire matrix, the memory required to hold this expanded public key is 41216 bytes (the size of A) plus 2560 bytes (the size of t). Therefore, while the public key is only 2592 bytes, or ˜2.6 kB, the size of the memoryrequired to store the intermediate values is 43776 bytes, or ˜43.8 kB.

II. Technology Overview: Expander Architecture

2 FIG. 2 FIG. 1 FIG. 2 FIG. 2 FIG. 200 204 104 102 100 104 108 204 204 1 210 204 210 210 1 illustrates a block diagram of a conventional PQC expander architecture. The PQC expander architectureas shown incomprises an expander, which may be identified with the expanderas shown and discussed above with respect to the PQC accelerator. However, it is noted that although the PQC accelerator architectureas shown inwas described in terms of the expanderand the processing blockworking closely together, many conventional systems also implement “loosely” coupled security satellites. In general, such loosely-coupled satellites comprise an input buffer, cryptographic primitives, and an output buffer. With respect to the expanderas shown in, the input and output buffers are not shown for purposes of brevity, but the input buffer(s) may be identified with any suitable buffers implemented by the expanderto temporality store the configuration data and the input data (the key part) that is received by the crypto or hash accelerator blockas shown in. The output buffer(s) may be identified with any suitable buffers implemented by the expanderto temporality store the output data generated by the crypto or hash accelerator block. Thus, the crypto or hash accelerator blockmay apply the cryptographic primitives that are configured in accordance with the received configuration data, and which consume the input data (e.g. the key part) and write a result (i.e. the output data) according to their respective configuration to the output buffer (i.e. the output data).

2 FIG. 210 210 Thus, conventional acceleration of cryptographic operations is realized by implementing dedicated crypto or hash accelerators, which are represented inas the crypto or hash accelerator block. Typically, these accelerators perform a single crypto or hash operation, as described in further detail below. Depending on the design, the complete set of input data or parts of the input data may be stored in the input buffer. Additionally, an operation specific configuration is required to perform the intended operation via the crypto or hash accelerator block. Moreover, the complete output data or portions thereof may be stored in the output buffer.

108 210 210 2 FIG. The end of the operation is signaled to a processing block (e.g. the processing block) either by a status flag, which can be polled, or via the use of an interrupt (not shown). Thus, after finishing one operation, the operation specific configuration (e.g. the configuration data) and the data transfer (the input data) need to be transferred to the crypto or hash accelerator blockmultiple times, as shown in. This is independent of whether the crypto or hash accelerator blockis a secondary module or has its own primary interface.

204 200 1 2 FIG. It is noted that, for many PQC algorithms, a large number of similar cryptographic operations need to be performed sequentially. In this context, the term “similar” refers to a significant portion of input data (e.g. the seed) being the same for a certain set of operations, as well as the operation specific configuration (i.e. identified by the configuration data) being the same for a certain set of operations. Thus, using classical crypto or hash accelerators, such as those implemented via the conventional expander, multiple reads and writes are required for each instance of input data, which in each case contains mostly the same data. Also, it is generally required in many applications to rewrite the operation specific configuration, even though it is also the same as the previous operations. For example, and with reference to the PQC expander architectureas shown in, the key partmay be the same for multiple operations, as only the last bytes ‘i’ an ‘j’ are changed, but the entirety of the input data still needs to be written to the input buffer for each sequential operation. Thus, conventional PQC expanders require significant processing overhead, which the embodiments described in further detail herein function to reduce to provide for more efficient operation.

III. An Example POC Accelerator Architecture

The use of the embodiments as described herein may be advantageous for PQC algorithms by providing solutions that decrease memory use, reduce the requirements for memory, and reduce processing overhead, as further discussed herein. However, although the embodiments disclosed herein are described with respect to PQC algorithms, this is by way of example and not limitation, and the embodiments may be implemented in accordance with any suitable type of symmetric or asymmetric cryptography. The embodiments described herein may be particularly useful for implementation with respect to the use of PQC algorithms or other suitable algorithms that implement key expansion, as the increase in efficiency may be leveraged to provide significant improvements in such scenarios.

302 404 For example, the embodiments as discussed herein (e.g. the PQC acceleratorand/or the expander) may be implemented to perform any suitable number and/or type of cryptographic-based functions using key expansion. Such PQC algorithms may be implemented in accordance with the embodiments discussed herein to perform cryptographic-based functions such as the use of a Digital Signature Algorithm (DSA) to provide an expanded key for the digital signature of data messages and/or to verify the authenticity of a digitally-signed message. As noted above, some examples of PQC algorithms used for a DSA may comprise CRYSTALS-DILITHIUM, Falcon, and SPHINCS+. The embodiments as described herein may additionally or alternatively be implemented to perform cryptographic-based functions in accordance with a Key Encapsulation Mechanism (KEM), with examples of PQC algorithms including CRYSTALS-KYBER, which may implement expanded key functionality to perform key generation, encapsulation, and/or decapsulation, and thus the cryptographic-based functions may comprise the encryption of plaintext and/or the decryption of ciphertext to provide plaintext using CRYSTALS-KYBER or any other suitable PQC algorithms that leverage key expansion. For KEM applications, the plaintext may represent, for example, a key that is used in accordance with symmetric encryption. Additional examples of the PQC algorithms that may be implemented in accordance with the embodiments described herein include SABER.

Furthermore, the embodiments as further discussed herein may be implemented in accordance with any suitable application in which PQC algorithms are used. Examples of such applications that implement DSA include automotive applications, in which a secure boot process is used to perform software verification, as well as diagnostic systems that perform a secure authentication of diagnostic data. Examples of applications that implement KEM comprise automotive applications such as performing a key exchange for the IEEE 802.1AE (MACsec) standard, which specifies a set of protocols to meet the security requirements for protecting data traversing Ethernet LANs, IPsec, Transport Layer Security (TLS) communications, etc. The use of the embodiments described herein in accordance with automotive applications is also provided by way of example and not limitation, and the embodiments herein may be implemented in accordance with any suitable application that utilizes cryptographic algorithms and cryptographic-based functions.

3 FIG. 3 FIG. 300 302 304 306 308 302 320 322 324 326 300 302 300 300 illustrates a block diagram of an accelerator architecture, in accordance with an embodiment of the disclosure. The accelerator architecturecomprises a PQC accelerator(also referred to herein as a PQC hardware accelerator), which includes an expander block, a memory, and a processing block. The PQC acceleratoralso includes data buffers,,, and, which may comprise any suitable type of registers, data banks, memory, etc., and which are configured to temporarily hold their respective data values. Furthermore, for purposes of brevity, additional components identified with the flow of data among the various components of the accelerator architectureare not shown. For example, the PQC accelerator, as well as any other suitable components of the accelerator architecture, may comprise any suitable number and/or type of data interfaces, ports, buses, interconnections, etc., which facilitate the flow of data among the various components of the accelerator architecture. The flow of data in this manner is represented by the various arrows as shown in.

304 304 104 304 308 306 308 304 306 The expander block, which may also be referred to herein as an expander, may comprise any suitable number and/or type of hardware components, hardware circuitry, software, or combinations of these. The expanderis configured to perform any suitable number and/or type of key expansion functions, which may comprise those discussed herein with respect to any suitable PQC algorithms, for example. However, instead of generating the entire expanded key at once, as discussed herein with respect to the expander, the expandersequentially generates expanded data fragments (also referred to herein simply as data fragments) of the expanded key. Thus, and as further discussed below, the processing blockmay “consume” each data fragment to obtain the expanded key by way of an iterative aggregation of the sequentially generated data fragments. Because of the sequential nature in which the data fragments are consumed, a portion of the memorymay be shared between successively generated data fragments. That is, as the previously stored data fragments are consumed by the processing block, this data may be overwritten by the expanderwith newly generated data fragments. This enables a significant reduction in the memory required, as the memoryonly needs to store data fragments identified with the expanded key data fragments instead of the entirety of the expanded key, as is the case for conventional PQC accelerators.

304 302 304 302 304 3 FIG. 4 FIG. In some embodiments, the expanderis configured to perform a single, predetermined key expansion function in accordance with a predetermined configuration, which is based upon the particular PQC algorithm that is being implemented by the PQC accelerator. In other embodiments, the expanderis configured to perform different key expansion functions in accordance with respective configurations, each being based upon the particular PQC algorithm that is implemented by the PQC acceleratorat a particular time. In any event, the configuration data provided to the expander, which is not shown infor purposes of brevity, may comprise cryptographic configuration parameters and/or other suitable parameters that define how the data fragments of the expanded key are to be sequentially generated. Additional details regarding the cryptographic configuration parameters, which is also referred to herein as configuration data, is further discussed below with respect to.

320 1 1 2 308 2 324 308 324 3 FIG. To this end, additional details of the PQC key expansion process are now provided for the sake of clarity. The embodiments discussed herein function to perform key expansion from smaller seed values, which may comprise keys (e.g. public or private keys) or portions of such keys, and which are commonly used in many types of known PQC cryptosystems. For instance, the buffermay store a key part, a portion (or the entirety thereof) comprising a seed value as discussed herein. Thus, the seed value may be identified with a portion of a cryptographic key, which may comprise the key partand the key partas shown in, for example. As further discussed herein, once the seed value is used to provide the expanded key, the processing blockmay utilize this expanded key in conjunction with the other portion of the key (i.e. the key part) to perform various cryptographic-based functions on the data that is stored in the data buffer. This data may represent, for example, a message, ciphertext, etc., based upon the particular cryptographic-based function being performed by the processing block. The manner in which the expanded key is used in conjunction with the data stored in the bufferto perform the various cryptographic-based functions is generally known, and thus additional details regarding this process is not provided for purposes of brevity. However, the manner in which the expanded key is obtained using the sequentially data fragments differs from the conventional use of expansion functions.

To clarify the principle of key expansion, it is noted that for many PQC algorithms, the processing (e.g. the specific cryptographic-based function that is performed) requires objects/keys that are expanded from smaller seeds. The expanded key is formed of several smaller sub-parts, which are also referred to herein as sub-blocks, as each sub-part may be represented as a smaller “block” of digital data with respect to the entire expanded key. As one example, the expanded key may comprise a matrix, and the entries of this expanded key matrix may comprise each of the smaller sub-parts. In other words, the expanded key matrix may comprise a plurality of entries, with each one of the plurality of entries comprising a value. In accordance with some PQC algorithms (e.g. CRYSTALS-DILITHIUM), the entries of the key expansion matrix may be identified with polynomials.

304 304 304 304 304 308 304 402 304 308 304 308 304 4 FIG. The term “identified with” is used here to convey that some post processing is used to translate the initial output of the expanderto the respective matrix entries of the expanded key. In other words, the output of the expandermay not necessarily be the final representation of the polynomial of the key expansion matrix. In any event, the output of the expander(e.g. a hash function output) may be mapped to a final representation of the polynomial entries of the key expansion matrix. In other words, the data fragments output by the expandermay be identified with the key expansion matrix entries such as polynomials, in the sense that each entry/polynomial may be uniquely derived from (i.e. mapped to) the data fragments output by the expander. The post processing used to generate the key expansion matrix entries may be performed, for example, as part of the sub-part operations as discussed herein with respect to the processing block. Alternatively, this post processing may be performed by the expander, and which may include post processing that is performed by the crypto or hash accelerator blockfurther discussed below with reference to. In this case, the data fragments output by the expandermay represent the matrix entries, which are processed by the processing blockas part of each respective sub-part operation as discussed in further detail herein. Thus, in some embodiments the data fragments output by the expandermay include pre-processed data that, upon being further processed via the processing block, result in a conversion of the data fragments into the polynomial matrix entries of the expanded key matrix. In other embodiments, the data fragments output by the expandermay already be post-processed, e.g. already represent the respective polynomial matrix entries of the expanded key matrix. In either case, the data fragments are identified with the entries of the expanded key matrix, which again may represent polynomial values. The post-processing that is performed to convert the data fragments into the polynomial values is generally known as part of each respective PQC algorithm, and thus additional details are not provided for purposes of brevity.

i,j Each sub-part (e.g. each matrix entry) is thus expanded deterministically from the seed, independently from the other sub-parts. The embodiments as described herein exploit the fact that the processing of each expanded key sub-part may be completed before the next sub-part is required. As an illustrative example, the verification step again is considered from the CRYSTALS-DILITHIUM PQC algorithm. The matrix A∈is defined by the seed ρ, specifically each entry is given by a=Expand(ρ, i, j), where ExpandA is an expansion function based on SHAKE-128. In this example, the matrix A represents the expanded key, and comprises a number of entries (i.e. sub-parts) represented in Equation 2 below as follows:

308 0,0 0,1 With reference to Equation 1 above, for the current example, the z values represent vector coefficients, and thus Az represents a matrix-vector product that is used by the processing blockto perform a specific cryptographic-based function, which is a verification step in the current example. The value v represents the intermediate values of the matrix-vector product. The entries of the expanded key matrix A may be defined as having a size of k×l, which are correlated to an index notation in which i represents a row of the expanded key matrix and j represents a column of the expanded key matrix. Each entry of the matrix is a single element of the polynomial ring, i.e., a polynomial with n=256 integer coefficients. Thus, the expanded key matrix entry ais identified with i=0, j−0, i.e. ExpandA(ρ,0,0). The expanded key matrix entry ais identified with i=0, j=1, i.e. ExpandA(ρ,0,1), and so on. Thus, Eqn. 1 shows the breakdown of this calculation into the corresponding vectors. In the algorithm below, it is further described how single elements are expanded and “consumed” in the calculation, while the variable (the memory space) “a” is reused for each entry.

304 304 0,1 i,j In an embodiment, the expanderis configured to iteratively generate, in a sequential manner, each one of the matrix entries a. . . aas respective data fragments of the expanded key as noted above. In other words, each one of the sequentially generated data fragments may be identified with a different respective one of the plurality of entries of the expanded key matrix. Thus, by computing each summand consecutively, an algorithmic description of this sum may be expressed by the following pseudocode, which may be implemented via the expander.

1: k×1 v ← 0 2: for j = 0, ... , l − 1 do 3:  for i = 0, ... , k − 1 do 4:   a′ = ExpandA(ρ,i,j) 5: i i j   v← v+ z· a′ 6:  end for 7: end for

q 302 404 Together, the intermediate values v and a′ consist of k+1 elements of R. Again, although the above example is provided with respect to the verification step is considered in the CRYSTALS-DILITHIUM PQC algorithm, this is by way of example and not limitation. The embodiments described herein (e.g. the PQC acceleratorand/or the expander) may generate the expanded key and/or perform the various cryptographic-based functions in accordance with any suitable PQC algorithm, e.g. CRYSTALS-DILITHIUM, CRYSTALS-KYBER, etc.

3 FIG. 304 306 308 308 0,0 k-1,l-1 Turning back now to, the expanderis configured to sequentially generate, from the same seed value, each one of the data fragments of the expanded key, which again may represent each of the matrix entries a. . . aof the expanded key matrix A. Each of the sequentially generated data fragments is then stored in the memory, which may be implemented as any suitable type of memory for this purpose (e.g. a volatile memory, a non-volatile memory, buffers, data banks, registers, etc.). The processing blockis configured to “consume” each of the sequentially generated data fragments, one at a time, to iteratively perform each computation identified with the matrix-vector product Az. For example, the processing blockmay perform a sequential series of computations that results in an iterative aggregation of the sequentially generated data fragments.

308 308 308 308 308 To do so, the processing blockmay comprise any suitable number and/or type of hardware components, hardware circuitry, software, or combinations of these. For instance, the processing blockmay be configured in accordance with a hardware implementation, which may comprise any suitable number and/or type of dedicated hardware components such as a microcontroller, an application specific integrated circuit, a field programmable gate array (FPGA), a system on a chip (SoC), dedicated logic and/or other circuitry, etc. As another example, the processing blockmay be configured in accordance with a software implementation in which instructions are executed to enable the processing blockto perform each cryptographic-based function. As another example, the processing blockmay be configured in accordance with a combination of a hardware and a software implementation, with the different portions thereof performing the various parts (individually or in combination) of each cryptographic-based function.

308 308 308 0,0 i,j In any event, the processing blockmay perform the iterative aggregation of the sequentially generated data fragments based upon the particular PQC algorithm that is implemented. That is, because the expanded key includes sub-parts that may be multiplied by respective values (or subjected to other operations), the processing blockmay compute the result of each sub-part operation, and add (i.e. aggregate) this result to subsequent sub-part operations in accordance with each sequentially generated data fragment. The processor blockmay repeat this iterative process of performing a sub-part operation (e.g. multiplication) and adding the result to the previous ones until all sub-part operations have been completed (e.g. until the sub-part operation identified with all matrix entries a. . . ahave been completed). At this point, the resulting aggregation of all sub-part operations is equivalent to the operations being performed using the entire expanded key.

308 308 308 0 0,0 To provide an illustrative example using the verification step as noted above, the processing blockmay perform a first sub-part operation by multiplying the first vector coefficient zby the first expanded key matrix entry ato compute a first summand of the matrix-vector product Az. The processing blockmay continue to iteratively multiply each one of the generated data fragments of the expanded key by a respective vector coefficient z to iteratively compute each one of the respective summands of the vector-matrix product Az, and then add the result to the previous one as part of the iterative aggregation process. Once this process is completed, the processing blockmay use the resulting matrix-vector product Az in accordance with the cryptographic-based function.

304 308 304 308 To perform the iterative aggregation process in this way, each of the expanderand the processing blockis configured in accordance with cryptographic configuration parameters that define the type of expansion function, how the seed value is used to perform the key expansion via sequential data fragments, as well as the size of the expanded key (e.g. the size of the expanded key matrix and number of entries). Thus, the cryptographic configuration parameters may comprise instructions, logic, code, settings, and/or hardware configuration data that identifies, to the expanderand to the processing block, how the expanded key is generated, as well as how the expanded key is used to perform a specific type of crypto-graphic-based function as discussed herein. For example, the cryptographic configuration parameters may define a security level and accompanying k andvalues, which are known parameters in accordance with various PQC algorithms, and thus define the size of the expanded key matrix and the parameters of its generation via data fragments.

304 308 308 308 308 304 308 306 0,0 3 FIG. In this way, the expanderand the processing blockeach “knows,” via the cryptographic configuration parameters, the maximum values for i and j, which are alternatively referred to herein as “sub-block indices.” Thus, the processing circuitryis configured to increment the sub-block indices i, j upon completing each iterative aggregation of the sequentially generated data fragments. For example, upon completing the first sub-part operation identified with the matrix entry a, the processing circuitrymay increment the sub-block indices i, j to 0, 1. Then, the processing blockmay transmit a control signal to the expanderas feedback (sub-block indices i, j as shown in) that is indicative of these sub-block indices. This triggers the expanderto perform the expansion of the next data fragment (e.g. matrix entry) of the expanded key, as the change in the sub-block indices indicates that a next respective data fragment of the expanded key should be generated and stored in the memory.

304 308 Thus, in accordance with an embodiment, the expanderis configured to perform the key expansion function to sequentially generate the data fragments of the expanded key. This process is repeated until each one of the plurality of data fragments (e.g. the sub-parts or the entries of the matrix identified with the expanded key) has been generated in accordance with cryptographic configuration parameters that define the size of the expanded key (e.g. the i×j size of the matrix). Likewise, the processing blockis configured to iteratively perform the aggregation of the sub-part operations identified with each consecutively generated data fragment of the expanded key until all the sub-part operations have been performed.

304 306 306 Because the expandergenerates the data fragments of the expanded key in a sequential manner, which may be used independently of one another, the size of the memorymay be significantly reduced compared to conventional PQC algorithm architectures. For example, the memorymay have a size that is equal to or sufficient to store only a single data fragment, or alternatively be configured to store two or more data fragments depending upon the desired tradeoff between processing speed and memory size for a particular application.

304 308 308 306 304 308 306 Moreover, the sub-block indices may function to synchronize the processing operations of the expanderand the processing block. This synchronization enables the processing blockto consume a data fragment stored in a first portion of the memoryfor a current sub-part operation while (or immediately prior to, excepting for communication and read and write latency) the expanderwriting the next data fragment (to be used by the processing blockfor the subsequent sub-part operation) to a second portion of the memory. Thus, the embodiments as discussed herein recognize that it is not necessary to expand the entire key before processing it. Instead, the “just-in-time” techniques as discussed herein expand the key in data fragments, e.g., one matrix entry at a time, process this data fragment, and then proceed to the next data fragment.

302 302 204 2 FIG. The use of the sub-block indices to coordinate the generation of the data fragments of the expanded key also enables a reduction in data transfers to the PQC accelerator. For example, the use of the sub-block indexing system enables the expanderto receive the seed value only once prior to performing the key expansion function to sequentially generate the data fragments of the expanded key. This is in contrast with the conventional PQC accelerator architectures, which require the expander to receive the same seed value multiple times, with only the sub-block indices changing in each case, as noted above with respect to the conventional expanderof.

308 306 308 304 306 308 Again, as each expanded data fragment only needs to be processed once, and this processing is independent of the other expanded data fragments, the processing blockmay consume each data fragment and then release a portion of the memoryto be overwritten with the next data fragment. For instance, because the processing blockno longer requires the previous data fragment once the sub-part operation and aggregation with the previous sub-part operation has been completed, the expanderis configured to overwrite each previously-generated data fragment in the memorywith a subsequently-generated data fragment. This process may continue until each of the data fragments of the expanded key have been generated and processed by the processing block.

302 As a result, the embodiments discussed herein function to reduce the size of the memory dedicated to the expanded key, which again may be equivalent to the size of a single data fragment in some embodiments. To provide an illustrative example of the advantages of memory size reduction in accordance with the embodiments, an example scenario is provided in which the parameter for security level V of CRYSTALS-DILITHIUM (k=7,=8, q=8380417). In this scenario, the memory required to store the intermediate values v is 6624 bytes. In comparison, the entire matrix A requires 41216 bytes to store. Hence, the PQC acceleratorenables a memory footprint that decreases by 84% for this example. In general, the memory footprint of the expanded key and intermediate calculation results is reduced in accordance with Equation 2 below as follows:

306 306 304 308 307 308 302 304 308 304 308 Thus, the size of the memorymay be reduced to a single data fragment size, as noted above. However, to increase throughput and enable pipelined processing, implementing the memoryto store twice the data fragment size allows for the expanderand the processingto work in parallel. That is, the expandermay compute and write the next required data fragment while the processing blockconsumes the previous data fragment. To further increase the throughput at the cost of an increased area, embodiments include the PQC acceleratorcomprising multiple expandersand/or multiple processing blocks. Providing multiple expandersand/or processing blocksmay facilitate parallelized processing of multiple data fragments.

IV. An Example PQC Expander Architecture

4 FIG. 4 FIG. 400 404 418 420 400 406 404 406 406 404 404 404 406 406 406 404 illustrates a block diagram of an expander architecture, in accordance with an embodiment of the disclosure. The expander architecturecomprises an expanderand data buffers,, which may comprise any suitable type of registers, data banks, memory, etc., and which are configured to temporarily hold their respective data values. The expander architecturealso comprises a memory, which is shown inas being separate from the expanderby way of example and not limitation. The memorymay be implemented as any suitable type of memory (e.g. a volatile memory, a non-volatile memory, buffers, data banks, registers, etc.). The memorymay be integrated as part of the expanderor may comprise a memory that is physically separate from the expander. In either case, the expanderhas dedicated access to the memoryand/or a portion of the memory. Thus, the memorymay be implemented as a physically separate memory dedicated to the expanderor, alternatively, as a dedicated portion (e.g. range of addresses) within a larger memory.

400 308 404 406 404 406 308 4 FIG. i,j As further described below, other components of the system in which the expander architectureis implemented (e.g. other “actors,” which may include processing blocks such as the processing blockfor example) are configured to access to the memory space that is dedicated for the expander(e.g. via the memory access data lines as shown in). For instance, other such components may access the data stored in the memoryto perform cryptographic-based functions and/or to read the stored data after a cryptographic-based function has been completed. However, because the memory is dedicated to the expander, other such actors do not control this expander-dedicated memory to get access to the data, but instead copy the data to their own memory (which may be also be a dedicated memory or a dedicated region of a larger memory). Upon copying the data accessed from the memoryin this manner, the actor (e.g. the processing block) may then further process the data, which may include executing the sub-part operations as discussed herein (e.g. the multiplication of the coefficients of z with the respective matrix entry aand subsequent aggregation with other summands).

300 400 404 406 418 420 406 404 308 404 4 FIG. Furthermore, and as was the case for the accelerator architecture, for purposes of brevity additional components identified with the flow of data among the various components of the expander architectureare not shown. For example, the expanderand the memorymay comprise any suitable number and/or type of data interfaces, ports, buses, interconnections, etc., which facilitate the flow of data among the data buffers,, the memory, the various components of the expander, as well as the other actors (e.g. the processing block) that are utilized in the system in which the expanderis implemented. The flow of data in this manner is represented by the various arrows as shown in.

404 404 304 302 420 320 406 306 3 FIG. 3 FIG. 3 FIG. The expandermay be configured to operate as an independent cryptographic “satellite,” and thus may be implemented in accordance with any suitable system in which expanded keys are generated. In some embodiments, the expandermay be identified with the expander, for instance, as discussed above with respect to the PQC acceleratorof. Thus, the data bufferand accompanying input data may likewise be identified with the data buffer, as shown and discussed herein with respect to, and the memorymay be identified with the memoryas discussed above with reference to.

302 404 304 406 406 406 308 404 302 404 4 FIG. 3 FIG. In accordance with such embodiments, the functionality and advantages of the PQC acceleratormay be combined with the functionality and advantages provided by the expander, as further discussed herein. For example, the output data as shown inmay represent the sequentially generated data fragments as discussed above with respect to the expander, which are written to the memory. Again, portions of the memorymay be shared between successively generated data fragments, i.e. portions of the memorymay be overwritten with subsequent data fragments upon the previously stored data fragments being consumed by the processing block(or other suitable actor). It is noted that the use of the expanderas part of the PQC acceleratorofis provided by way of example and not limitation, and the expandermay operate as an independent cryptographic satellite as part of any suitable system, as further noted herein.

404 408 408 402 408 408 408 408 408 408 418 The expanderalso comprises a first counterA, a second counterB, and a crypto or hash accelerator block, which is alternatively referred to herein as “accelerator circuitry.” The first and second countersA,B may be implemented as any suitable type of processors (processing circuitry), hardware components, executed instructions (e.g. software components), or combinations of these. Each of the countersA,B may be configurable with respect to the range of counter values that it counts up to before being reset. That is, each of the countersA,B may be configured, by way of the received configuration data provided via the data buffer, to count to a maximum counter value before resetting to its initial or default counter value (e.g. 0).

408 408 408 408 408 408 408 408 402 408 408 418 408 408 404 4 FIG. For example, the configuration data may be identified with or otherwise comprise the cryptographic configuration parameters as noted above, which define the type of expansion function, how the seed value is used to perform the key expansion via sequential data fragments (e.g. how the data fragments of the expanded key are to be sequentially generated), as well as the size of the expanded key (e.g. the size of the expanded key matrix and the number of entries). Thus, the countersA,B may be configured to increment their respective counter values, which may correspond for example to a row index i and a column index j, respectively, of the expanded key matrix as discussed herein. The countersA,B may be configured to set their maximum count values in accordance with the size of the expanded key that is indicated via the configuration data. To provide an illustrative example, if the configuration data indicates that the expanded key matrix is a size k×l of 5×5, then each of the countersA,B would be configured to count from a digital value equal to 0 up to a digital value equal to 4, i.e. i and j would range between 0 and 4. The countersA,B may be configured in this manner via communication with the crypto or hash accelerator block, as shown invia the “counter data.” Alternatively, the countersA,B may access the configuration data stored in the data bufferor otherwise be configured independently via data communications that utilize the configuration data (not shown). As yet another alternative, the countersA,B may be configured in this manner via communications with an external device (not shown), which may comprise a host device in which the expanderis implemented or otherwise forms a part thereof.

408 408 402 300 404 404 308 404 402 408 408 404 402 In any event, each of the countersA,B may be configured to independently increment their respective counter values in accordance with any suitable timing schedule to facilitate the crypto or hash accelerator blockreceiving the next incremented values (i.e. the sub-block indices) after each data fragment is generated as the output data, which is written to any suitable memory. As noted above for the PQC accelerator architecture, the data fragments output by the expandermay be identified with the entries of the expanded key matrix, and may be processed by the expanderor the processing block (e.g. processing block) to uniquely derive the matrix entries. For example, the combination of the sub-block indices (which may represent e.g. column and the row indices) indicate to the expander(e.g. the crypto or hash accelerator) a next one of the data fragments (e.g. a next one plurality of entries of the key expansion matrix) to generate a respective data fragment of the expanded key. To do so, the countersA,B may be clocked by any suitable system clock in which the expanderis implemented, which may be asynchronous or synchronous with respect to the operation of the crypto or hash accelerator block.

408 408 402 402 408 408 402 408 408 402 402 For example, the countersA,B may asynchronously increment their counter values in accordance with a predetermined schedule that ensures that the crypto or hash accelerator blockhas completed the previous data fragment computation and is thus ready to compute the next sequential data fragment. As another example, the crypto or hash accelerator blockmay be configured to provide feedback to indicate to the countersA,B when to increment their respective counter values via the counter data, which may be in accordance with a predetermined sequential order that is known by the crypto or hash accelerator blockbased upon the configuration data. Thus, the countersA,B may be configured, upon the crypto or hash accelerator blockcompleting each sequentially generated data fragment of the expanded key, to selectively increment their respective index values to indicate, to the crypto or hash accelerator block, a next one of sequentially generated data fragments (e.g. a next one of the plurality of entries of the matrix) to generate with respect to the expanded key.

404 304 302 308 404 408 408 404 404 308 302 404 302 302 In this way, it is noted that in accordance with embodiments in which the expanderis implemented as the expanderof the PQC accelerator, the feedback (i.e. the sub-block index control signals) between the processing blockand the expandermay not be required, as the internal countersA,B of the expandermay indicate to the expanderwhich sub-blocks (i.e. which data fragments) of the expanded key to generate at a particular time. Thus, in this scenario, the control signals that are provided by the processing blockare no longer needed to trigger each sequentially generated data fragment as noted above for the PQC accelerator. However, it is noted that the expanderis not limited to implementations via the PQC accelerator, and may be implemented as part of any suitable PQC accelerator architecture, including known PQC accelerator types and/or PQC accelerators other than the PQC accelerator.

404 402 402 402 402 Thus, through the use of the configuration data, flexible operation of the expanderis realized, and may be configured to perform any suitable type of key expansion functions based upon the particular PQC algorithm and/or application. For instance, the crypto or hash acceleratormay be configured in accordance with a hardware implementation, which may comprise any suitable number and/or type of dedicated hardware components such as a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system on a chip (SoC), dedicated logic and/or other circuitry, etc. As another example, the crypto or hash accelerator blockmay be configured in accordance with a software implementation in which instructions are executed to enable the crypto or hash acceleratorto perform specific types of key expansion functions. As another example, the crypto or hash accelerator blockmay be configured in accordance with a combination of a hardware and a software implementation.

402 408 408 308 402 302 420 1 In any event, is it noted that the configuration data may comprise cryptographic configuration parameters that include instructions, logic, code, settings, and/or hardware configuration data that identifies, to the crypto or hash accelerator block(and optionally to the countersA,B and the relevant processing block such as the processing block, for example), how the expanded key is generated. For example, and as noted above, the cryptographic configuration parameters may define a security level and accompanying k andvalues, which are known parameters in accordance with various PQC algorithms, and thus define the size of the expanded key matrix and the parameters of its generation via the data fragments. Thus, the crypto or hash accelerator blockmay have a flexible configuration to perform any suitable number and/or type key expansion functions or other suitable functions with respect to the input data, which may be a function of the particular type of PQC algorithm and/or application currently implemented as indicated by the configuration data. The input data may comprise, for instance, a cryptographic key or a portion of a cryptographic key, as noted above for the PQC accelerator. For instance, the entirety or portion of the input data may be stored in the data buffer, e.g. key part, a portion (or the entirety thereof) comprising a seed value as discussed herein.

404 418 420 402 408 408 404 204 402 406 402 However, in contrast to conventional expanders, the expanderdoes not need to receive the configuration data and the seed value multiple times as the expanded key is generated. Instead, the configuration data and the input data may be received (e.g. read from their respective data buffers,) by the crypto or hash accelerator blockonce (e.g. only once) prior to each of the data fragments being sequentially generated for an expanded key. This is achieved by way of the use of the sub-block indexes that are provided via the countersA,B internally to the expander, which obviates the need to repeatedly receive these sub-block indices (along with their respective seed value) as the data fragments are computed for the same seed value, as was the case for the expander. For example, the input data of one operation (e.g. the seed value) may be internally stored by the crypto or hash accelerator block(or stored in the dedicated portion of the memory), and thus may be reused for each subsequent key expansion operation. Moreover, because the sub-block indices are generated internally, these may also be attached to the stored input data by the crypto or hash accelerator blockinstead of being received over multiple data transfers of the input data.

402 408 408 402 302 402 404 2 FIG. Therefore, the crypto or hash accelerator blockmay perform multiple operations based on the same input data with incrementing counter values, and all data fragments of the expanded key may be processed with a single data configuration. In other words, the internal countersA,B output counter values that are appended to the seed value, thereby enabling the crypto or hash accelerator blockto repeatedly compute each expanded key data fragment without repeatedly receiving additional seed values, which typically include the same seed value and the appended sub-block indices as noted above with respect to. For example, and as noted above with respect to the PQC accelerator, the crypto or hash accelerator blockmay, upon receiving the configuration data and input data one time (e.g. only once), be triggered to sequentially generate each of the data fragments of the expanded key. Once triggered, this process may continue until each one of the data fragments (e.g. each of the plurality of entries of the matrix) identified with the expanded key has been generated in accordance with cryptographic configuration parameters that define the size of the matrix. This advantageously enables the expanderto function as an independent satellite that performs multiple calls, and only needs to be triggered once with a single configuration and seed value to provide all data fragments of a resulting expanded key. This reduces data configuration overhead, data input overhead, and latency compared to the conventional computation of expanded keys.

402 308 402 308 406 406 As each data fragment is output via the crypto or hash accelerator block, the follow-up processing by the processing block (e.g. processing block) may be performed in various ways depending on the system setup. For example, the crypto or hash acceleratoris configured to sequentially generate each of the data fragments of the expanded key, as noted above. Thus, the output data that is accessed and copied by the processing block (e.g. the processing block) may comprise data blocks of any suitable size such that the processing block may access and copy from the memoryany suitable number of data fragments to perform the respective sub-part operations as discussed herein. For instance, in one scenario the output data may comprise each sequentially generated data fragment, which is accessed via the processing block after each data fragment is stored in the memory. As another example scenario, the output data may comprise a larger data block that comprises a concatenation of all data fragments of the expanded key. In this scenario, the processing block may wait until all data fragments have been generated before performing the subsequent sub-part operations.

404 406 406 406 404 406 In various embodiments, the expandermay thus be configured such that the sub-part operations are performed each time a data fragment is stored in the memory, after all data fragments are stored in the memory, or after any suitable number of data fragments less than all data fragments have been stored in the memory. In other words, the configuration data may be leveraged to control a granularity with which the stored data fragments are accessed by the processing block to perform the subsequent sub-part operations. Thus, for some applications it may be desirable for the processing block to obtain each data fragment as fast as possible (e.g. as soon as the data fragment is stored), while in other cases it might be more desirable for the processing block to wait for all data fragments to be generated. This latter scenario may be particularly advantageous, for instance, to keep the overhead that is associated with initiating a copying operation low. Thus, the expandermay output any suitable number of data fragments, which may be concatenated together into larger data blocks, before being accessed from the memoryby the processing block and processed.

402 308 406 402 4 FIG. 4 FIG. In an embodiment, the crypto or hash acceleratormay communicate with the processing block (e.g. the processing block) via one or more data lines (control to/from processing block) as shown in. The data sent to the processing block via such communications may include any suitable type of control signals that may inform the processing block when the next data block (which again may contain any suitable number, or all, of the data fragments) is available. The information about the availability of data fragments in the memorymay be provided to the processing block in any suitable number and/or types of ways via such data communications. For example, the crypto or hash acceleratormay implement flags, polling, interrupts, etc., via the use of the control signals that are provided to the processing block, as shown in.

404 404 402 406 420 404 In this way, another significant advantage of the expanderis the reduction in the number of interactions required with the processing block, since the configuration data and the input data do not need to be written as each data fragment is accessed and processed. Instead, the size of the data blocks accessed by the processing block may be made available of any suitable size that is best suited to the flow of the processing block. Furthermore, it is noted that the amount of input data to be stored in the expander(e.g. in the crypto or hash accelerator block) is generally smaller than the data block length, i.e. the size of the output data block identified with the results written to the memory. Therefore, no additional buffers are needed to keep this data in the data bufferover multiple operations. As a result, this feature does not increase the memory area of the expandercompared to conventional expanders.

i,j To provide an illustrative example, the verification step again is considered in the CRYSTALS-DILITHIUM PQC algorithm. The matrix A∈is defined by the seed ρ, specifically each entry is given by a=Expand(ρ, i, j), where ExpandA is an expansion function based on SHAKE-128. A typical configuration for CRYSTALS-DILITHIUM has ρ=256 bit and i and j consisting of 1 byte each. For a security level of V, the largest dimensions are considered with k=8 and=7.

These conditions result in the following inputs:

k· = A classical crypto or hash accelerator requires:nrOperations=56transferSize=(256 bits+16 bits)·nrOperations=1904 bytes

404 nrOperations=1 transferSize=256 bits=32 bytes The expanderas described above requires:

404 Performing this operation using the expandermay reduce the number of configuration interactions to a single interaction, or by k·−1=55, which increases, for example, the software stack efficiency significantly. In other words, there are k·elements in the matrix, and only a single configuration is used instead of a configuration per each element. Thus, the reduction is the difference between the two scenarios. Moreover, the bus traffic is reduced by 1872 bytes.

404 404 404 404 It is noted that the expanderutilizes an additional configuration of the selected security level in this example, which may be used to determine the size of the key expansion matrix as noted herein. However, this configuration effort is negligible, as this could be implemented by 2 only bits. The above mentioned conditions thus results in the amount of output data being the same for both conventional crypto or hash accelerators and the expander, which illustrates that the input data and the number of interactions are reduced significantly. For instance, the expandermay facilitate a reduction in the number of interactions with the processing block by concatenating all outputs of the k·operations and informing the processing block once the operation is finished. For example, only a single polled signal or a single interrupt signal may be required, as noted above. Such a configuration may be particularly advantageous for the interaction of the expanderwith a software stack. Moreover, for tightly coupled systems, the data fragments identified with the output data may be accessed more frequently via the processing block.

V. Example Process Flows

5 FIG. 5 FIG. 5 FIG. 5 FIG. 500 302 402 500 illustrates an example process flow, in accordance with an embodiment of the disclosure. With reference to, the process flowmay be a method executed by and/or otherwise associated with any suitable number and/or type of components such as one or more processors (processing circuitry), hardware components, executed instructions (e.g. software components), or combinations of these. The components may be associated with, for example, one or more components of the PQC acceleratoras discussed herein and/or one or more components of the expanderas discussed herein. The flowmay include alternate or additional steps that are not shown infor purposes of brevity, and may be performed in a different order than the steps shown in.

500 502 304 404 Flowmay begin with one or more components performing (block) a key expansion function. This may include, for example, the expander/sequentially generating data fragments of an expanded key using a seed value, as noted above. The seed value may be identified, for example, with a portion of a cryptographic key.

500 504 306 The flowmay additionally include the one or more components storing (block) the sequentially generated data fragments. This may include, for example, the memorystoring the sequentially generated data fragments, which may include overwriting previously stored data fragments as these are consumed as part of the iterative aggregation process, as noted herein.

500 506 The flowmay additionally include the one or more components performing (block) at least part of a cryptographic-based function. The cryptographic-based function may comprise, for instance, providing a digital signature, verifying (e.g. for authentication) a digital signature, encrypting plaintext to provide ciphertext, decrypting ciphertext to provide plaintext, etc. The cryptographic-based function may be performed, for example, in accordance with the expanded key based upon an iterative aggregation of the sequentially generated data fragments, as noted herein.

6 FIG. 6 FIG. 6 FIG. 6 FIG. 600 302 402 600 illustrates an example process flow, in accordance with an embodiment of the disclosure. With reference to, the process flowmay be a method executed by and/or otherwise associated with any suitable number and/or type of components such as one or more processors (processing circuitry), hardware components, executed instructions (e.g. software components), or combinations of these. The components may be associated with, for example, one or more components of the PQC acceleratoras discussed herein and/or one or more components of the expanderas discussed herein. The flowmay include alternate or additional steps that are not shown infor purposes of brevity, and may be performed in a different order than the steps shown in.

600 602 Flowmay begin with one or more components outputting (block) a first index value. This first index value may comprise, for example, a first sub-block index value, as discussed herein, which may be generated via a first counter. For example, the first index value may comprise a row index identified with the plurality of entries of an expanded key matrix.

600 604 Flowmay additionally include the one or more components outputting (block) a second index value. This second index value may comprise, for example, a second sub-block index value, as discussed herein, which may be generated via a second counter. For example, the second index value may comprise a column index identified with the plurality of entries of an expanded key matrix.

600 606 304 404 Flowmay additionally include the one or more components performing (block) a key expansion function. This may include, for example, the expander/sequentially generating data fragments of an expanded key using a seed value, as noted above. The seed value may be identified, for example, with a portion of a cryptographic key. Moreover, a combination of the first and the second index values indicate a next one of the data fragments of the expanded key that is to be generated.

600 608 The flowmay additionally include the one or more components performing (block) at least part of a cryptographic-based function. The cryptographic-based function may comprise, for instance, providing a digital signature, verifying a digital signature (e.g. via authentication), encrypting plaintext to provide ciphertext, or decrypting ciphertext to provide plaintext, etc. The cryptographic-based function may be performed, for example, in accordance with the expanded key based upon an iterative aggregation of the sequentially generated data fragments, as noted herein.

The techniques of this disclosure may also be described in the following examples.

A post-quantum cryptography (PQC) hardware accelerator, comprising: an expander configured to perform a key expansion function using a seed value by sequentially generating data fragments of an expanded key, the seed value being identified with a portion of a cryptographic key; a memory configured to store the sequentially generated data fragments; and processing circuitry configured to perform a cryptographic-based function in accordance using the expanded key based upon an iterative aggregation of the sequentially generated data fragments.

The PQC hardware accelerator of Example 1, wherein the expander is configured to overwrite previously-generated data fragments of the expanded key stored in the memory with subsequently-generated data fragments.

The PQC hardware accelerator of any combination of Examples 1-2, wherein the expanded key is associated with a matrix having a plurality of entries, each one of the plurality of entries being identified with a polynomial value.

The PQC hardware accelerator of any combination of Examples 1-3, wherein each one of the sequentially generated data fragments is identified with a different one of the plurality of entries of the matrix, and wherein the expander is configured to perform post processing on each one of the sequentially generated data fragments to generate, as each different one of the plurality of entries of the matrix, a respective polynomial value.

The PQC hardware accelerator of any combination of Examples 1-4, wherein each one of the sequentially generated data fragments is identified with a different one of the plurality of entries of the matrix, and wherein the processing circuitry is configured to perform post processing on each one of the sequentially generated data fragments to generate, as each different one of the plurality of entries of the matrix, a respective polynomial value.

The PQC hardware accelerator of any combination of Examples 1-5, wherein the expander is configured to perform the key expansion function to sequentially generate the data fragments of the expanded key until each one of the plurality of entries has been generated in accordance with cryptographic configuration parameters that define a size of the matrix.

The PQC hardware accelerator of any combination of Examples 1-6, wherein the processing circuitry is configured, upon completing each iterative aggregation of the sequentially generated data fragments, to transmit a control signal to the expander indicative of a next one of the plurality of entries of the matrix to generate a respective data fragment of the expanded key.

The PQC hardware accelerator of any combination of Examples 1-7, wherein the processing circuitry is configured to perform the iterative aggregation of the sequentially generated data fragments by iteratively multiplying each one of the generated data fragments of the expanded key by a respective vector coefficient to iteratively compute respective summands of a vector-matrix product that is used to perform at least part of the cryptographic-based function.

The PQC hardware accelerator of any combination of Examples 1-8, wherein the cryptographic-based function comprises one or more of providing a digital signature, verifying a digital signature, encrypting plaintext to provide ciphertext, or decrypting ciphertext to provide plaintext.

The PQC hardware accelerator of any combination of Examples 1-9, wherein the expanded key is generated in accordance with a PQC algorithm that comprises CRYSTALS-DILITHIUM or CRYSTALS-KYBER.

The PQC hardware accelerator of any combination of Examples 1-10, further comprising: a first counter configured to increment a row index of the matrix; and a second counter configured to increment a column index of the matrix, wherein a combination of the column and the row indices indicate, to the expander, a next one of the plurality of entries of the matrix to generate a respective data fragment of the expanded key.

The PQC hardware of any combination of Examples 1-11, wherein the expander is configured to receive the seed value only once prior to performing the key expansion function to sequentially generate the data fragments of the expanded key.

The PQC hardware accelerator of any combination of Examples 1-12, wherein the cryptographic-based function is performed in accordance with a Key Encapsulation Mechanism (KEM) in which the plaintext represents a key used for symmetric encryption.

A post-quantum cryptography (PQC) key expander, comprising: a first counter configured to output a first index value; a second counter configured to output a second index value; and accelerator circuitry configured to perform a key expansion function using a seed value by sequentially generating data fragments of an expanded key, the seed value being identified with a portion of a cryptographic key, wherein a combination of the first and the second index values indicate, to the accelerator circuitry, a next one of the data fragments of the expanded key that is to be generated, and wherein the expanded key is used to perform at least part of a cryptographic-based function.

The PQC key expander of Example 14, wherein the accelerator circuitry is configured to receive configuration data indicative of parameters that define how the data fragments of the expanded key are to be sequentially generated, and wherein the accelerator circuitry is configured to receive each of the configuration data and the seed value only once prior to the accelerator circuitry performing the key expansion function to sequentially generate the data fragments of the expanded key.

The PQC key expander of any combination of Examples 14-15, wherein the expanded key is associated with a matrix having a plurality of entries, each one of the plurality of entries being identified with a polynomial value.

The PQC key expander of any combination of Examples 14-16, wherein the first index value comprises a row index identified with the plurality of entries of the matrix, and wherein the second index value comprises a column index identified with the plurality of entries of the matrix.

The PQC key expander of any combination of Examples 14-17, wherein each one of the sequentially generated data fragments is identified with a different one of the plurality of entries of the matrix, and wherein the accelerator circuitry is configured to perform post processing on each one of the sequentially generated data fragments to generate, as each different one of the plurality of entries of the matrix, a respective polynomial value.

The PQC key expander of any combination of Examples 14-18, wherein the accelerator circuitry is configured to perform the key expansion function to sequentially generate the data fragments of the expanded key until each one of the plurality of entries of the matrix has been generated in accordance with cryptographic configuration parameters that define a size of the matrix.

The PQC key expander of any combination of Examples 14-19, wherein the first and the second counter is each configured, upon the accelerator circuitry completing each sequentially generated data fragment of the expanded key, to selectively increment the first index value and the second index value, respectively, to indicate to the accelerator circuitry a next one of the plurality of entries of the matrix to generate a respective data fragment of the expanded key.

The PQC key expander of any combination of Examples 14-20, wherein the cryptographic-based function comprises one or more of providing a digital signature, authenticating a digital signature, encrypting plaintext to provide ciphertext, or decrypting ciphertext to provide plaintext.

The PQC key expander of any combination of Examples 14-21, wherein the expanded key is generated in accordance with a PQC algorithm that comprises CRYSTALS-DILITHIUM or CRYSTALS-KYBER.

The PQC key expander of any combination of Examples 14-22, wherein the accelerator circuitry is configured to write output data comprising one or more of the sequentially generated data fragments of the expanded key to a memory, and wherein processing circuitry copies the output data from the memory to perform at least part of the cryptographic-based function.

The PQC key expander of any combination of Examples 14-23, wherein the output data comprises one or more generated data fragments of the expanded key from among the sequentially generated data fragments.

The PQC key expander of any combination of Examples 14-24, wherein the output data comprises each one of the sequentially generated data fragments of the expanded key.

An apparatus as shown and described.

A method as shown and described.

Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

It is further to be noted that specific terms used in the description and claims may be interpreted in a very broad sense. For example, the terms “circuit” or “circuitry” used herein are to be interpreted in a sense not only including hardware but also software, firmware or any combinations thereof. The term “data” may be interpreted to include any form of representation data. The term “information” may in addition to any form of digital information also include other forms of representing information. The term “entity” or “unit” may in embodiments include any device, apparatus circuits, hardware, software, firmware, chips, or other semiconductors as well as logical units or physical implementations of protocol layers etc. Furthermore, the terms “coupled” or “connected” may be interpreted in a broad sense not only covering direct but also indirect coupling.

It is further to be noted that methods disclosed in the specification or in the claims may be implemented by a device having means for performing each of the respective steps of these methods.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present disclosure. This disclosure is intended to cover any adaptations or variations of the specific embodiments discussed herein.