Efficient storage utilization for storing cryptographic keys

Abstract

Method for generating a lattice-based signature (σ), comprising: - Determining an uncorrected signature (c̃, z), - Determining clues (h) based on a verification of the uncorrected signature (c̃, z), wherein the verification is based on a first part (t1) of an uncompressed public key element (t), wherein the second part (t0) of the uncompressed public key element (t) is not used during signature generation, and wherein the effects of omitting the second part (t0) are calculated in reverse without using this second part (t0). - Providing the uncorrected signature (c̃, z) and the hints (h) as a grid-based signature (σ), - where the compression is performed at least partially on one of the following components: - a safety device, - a secure cloud, - a secure service, - an integrated circuit, - a hardware security module, - a trusted platform module, - a crypto unit, - an FPGA, - a processing unit, - a control system, - a smartcard.

Description

[0001] In lattice-based cryptography, keys and ciphertexts and / or signatures are typically large, especially larger than their RSA / ECC counterparts.

[0002] A solution for generating an electronic signature is known from JP 2021-150951 A. This solution uses grid-based signature schemes.

[0003] From [Le, HQ ua: A Blind Signature from Module Latices, IEEE Conference on Dependable and Secure Computing (DSC), Hangzhou, China, 2019] it is known to use the digital signature method Dilithium as a blind signature method.

[0004] A grid-based signature algorithm uses a sender (also called signer) who transmits a signature to a receiver (also called verifier). The receiver must be able to determine whether the signature is valid or not.

[0005] To reduce the size of the public key, the lattice-based digital signature algorithm Dilithium [LDK] splits. + 21] splits an uncompressed public key element t into two parts: A first part t1 contains the higher-order bits of the coefficients of t, and a second part t0 contains the lower-order bits of the coefficients. Only t1 is part of the public key, which reduces the required storage size compared to returning the uncompressed public key t.

[0006] For the returned signatures to be valid, the absence of t0 in the public key must be taken into account during the signing process. With each signing operation, the effect of omitting t0 is calculated and incorporated into the signature. The verifier then uses so-called hints to correct the missing t0 part.

[0007] Calculating the hints according to the method described in the current Dilithium specification requires knowledge of t0, which means that t0 must be stored as part of the key. This could pose a problem for devices with limited memory, as t0 can be quite large (i.e., up to 3.25 kB). The public component, t1, while not directly required for signing, must also be stored on the device for several purposes. For example, the device might need to transmit its public key (in the form of a signed certificate) to an auditor. Therefore, in terms of memory limitations, the signing device does not benefit from splitting the public key into t0 and t1.

[0008] Therefore, one goal is to find a more efficient way to save storage space when handling keys on a device.

[0009] This is solved according to the features of the independent claims. Further embodiments are described in the dependent claims.

[0010] The examples proposed here can be based on at least one of the following solutions. Combinations of the following features can be used to achieve a desired result. The features of the method could be combined with any feature(s) of the device, equipment, or system, or vice versa.

[0011] It should be noted that a cryptographic key can be any key used in a cryptographic context. For example, it can be any private, secure, or public key. In particular, the cryptographic key can be a key used in combination with post-quantum cryptography.

[0012] A method for generating a lattice-based signature (σ) is proposed, which includes: - Determining an uncorrected signature (c̃, z), - Determining clues (h) based on a verification of the uncorrected signature (c̃, z), wherein the verification is based on a first part (t1) of an uncompressed public key element (t), wherein the second part (t0) of the uncompressed public key element (t) is not used during signature generation, and wherein the effects of omitting the second part (t0) are calculated in reverse without using this second part (t0). - Providing the uncorrected signature (c̃, z) and the hints (h) as a grid-based signature (σ), - where the compression is performed at least partially on one of the following components: - a safety device, - a secure cloud, - a secure service, - an integrated circuit, - a hardware security module, - a trusted platform module, - a crypto unit, - an FPGA, - a processing unit, - a control system, - a smartcard.

[0013] Advantageously, the hints can be calculated using a portion of the public key, in the example described here, portion t1, instead of a portion of the secret key t0 that is larger than t1. Thus, only portion t1 needs to be stored locally on the device (but not t0).

[0014] Another advantage is that all additional calculations are performed on public data, resulting in lower security costs.

[0015] Since verification is part of signature generation, this solution can also be used to detect defects or errors that may occur during the signing process.

[0016] Instead of calculating the effects of omitting t0 in the forward direction (where t0 is used to calculate the difference), the effects of omitting t0 are calculated in the reverse direction: The received uncorrected signature is processed by the verification (using t1). The observed difference between this result and the intermediate results calculated during signing can be used to calculate the hints h.

[0017] According to one embodiment, the signature generation is based on or works in conjunction with the grid-based digital signature method Dilithium.

[0018] According to one embodiment, the second part (t0) of the uncompressed public key element is longer than the first part (t1) of the uncompressed public key element.

[0019] According to one embodiment, the second part (t0) of the uncompressed public key element is not stored locally.

[0020] Local can refer in particular to a specific device. This can also be a device (or multiple devices) that is / are connected via a network.

[0021] According to one embodiment, the second part (t0) of the uncompressed public key element is not made publicly available.

[0022] According to one embodiment, the check is used to determine whether an error occurred during the generation of the grid-based signature.

[0023] A device for generating a lattice-based signature (σ) is also provided, the device being designed to perform the following steps: - Determining an uncorrected signature (c̃, z), - Determining clues (h) based on a verification of the uncorrected signature (c̃, z), wherein the verification is based on a first part (t1) of an uncompressed public key element (t), wherein the second part (t0) of the uncompressed public key element (t) is not used during signature generation, and wherein the effects of omitting the second part (t0) are calculated in reverse without using this second part (t0). - Providing the uncorrected signature (c̃, z) and the hints (h) as a grid-based signature (σ), - wherein the device is one of the following or comprises at least one of the following: - a safety device, - a secure cloud, - a secure service, - an integrated circuit, - a hardware security module, - a trusted platform module, - a crypto unit, - an FPGA, - a processing unit, - a control system, - a smartcard.

[0024] Furthermore, a computer program product is provided that can be directly loaded into a memory of a digital processing device and includes software code sections for performing the steps of the procedure described herein.

[0025] Embodiments are illustrated and explained with reference to the drawings. The drawings serve to illustrate the basic principle; therefore, only aspects necessary for understanding the basic principle are shown. The drawings are not to scale. In the drawings, identical reference symbols denote identical features. They show: Fig. 1 shows one from [LDK + 21] taken from the pseudocode for deterministic and randomized versions of Dilithium. Fig. Figure 2 shows an exemplary block diagram of a modified signature method, which can be used particularly in a dilithium environment. Fig. Figure 3 shows an exemplary arrangement of a processing device comprising a CPU, RAM, non-volatile memory, crypto module, analog module, input / output interface and hardware random number generator; Fig. Figure 4 shows an alternative arrangement with a hardware security module (HSM).

[0026] The examples described here enable efficient calculation of the hints using the public key t1 instead of t0. Thus, while t1 is stored locally on a device, t0 is not. This is advantageous because t1 is needed for verification purposes anyway.

[0027] Another advantage is that all additional calculations are performed on public data, resulting in lower security overhead. Furthermore, the approach can be used for error detection.

[0028] Instead of calculating the effects of omitting t0 in the forward direction (where t0 is used to calculate the difference), the effects of omitting t0 are calculated in the reverse direction: The received uncorrected signature is processed by parts of the verification process (using t1). The observed difference between this result and the intermediate results calculated during signing can then be used to calculate the clues that allow for signature correction. Introduction to Dilithium

[0029] The following is a brief and simplified description of the components involved in the dilithium signature process. For further details, see [LDK]. + 21] referred.

[0030] Dilithium works on the basis of vectors and matrices, which consist of polynomials with coefficients modulo q. Polynomials are denoted by simple letters, e.g., a, while vectors and matrices are denoted by bold lowercase letters a and uppercase letters A, respectively.

[0031] Fig. 1 shows one from [LDK +

[21] , page 13, taken from pseudocode for deterministic and randomized versions of Dilithium.

[0032] This pseudocode comprises three sections: a key generation section, a signature generation section, and a verification section. These are described below with reference to the line numbers in Fig. 1 described. Dilithium: Key generation Line 1: A random number ζ is generated. This number serves as the starting value ("seed") for key generation. Line 2: Three further starting values ​​(p, p', K) are derived from the random number ζ. Line 3: The initial value p is used to deterministically generate (using the ExpandA function) a matrix A. The initial value p is also contained in the public and private keys, so that all participants can generate the matrix A. Line 4: A function ExpandS is used to derive secret key elements (s1, s2) from the initial value p'. The coefficients of (s1, s2) are evenly distributed over an interval [-η, η]. Line 5: An uncompressed public key element t is calculated by multiplying the matrix A by the first secret key element s1 and then adding the second secret key element s2. Line 6: The uncompressed public key element t is split into two parts, t1 and t0, using the Power2Round function. Element t1 contains the higher-order bits of the coefficients of the uncompressed public key element t, and element t0 contains the lower-order bits of the coefficients of the uncompressed public key element t. Line 7: The starting value p and the compressed public key element t1 are hashed to a value tr. Line 8: A public key pk is provided, which includes the starting value p and the element t1.

[0033] A secret key sk includes the seed values ​​p and K, the hash value tr of the public key, the secret key elements s1 and s2, and the least significant bits t0 of the uncompressed public key element t.

[0034] It should be noted that p, tr, and t0 are required for signing and are therefore included in the private key, but do not need to be kept secret and can be disclosed. In contrast, K, s1, and s2 must be kept secret. Dilithium: Sign (generation) Line 9: The matrix A is determined based on the starting value p, which is contained in the secret key sk. Line 10: The hash value tr of the public key is hashed together with a message M to be signed. The result is stored in µ. Line 11: A counter variable κ is initialized to 0. Signature output elements (z, h) are initialized to the invalid symbol ⊥. Line 12: The starting value p' is determined: In deterministic signing, p' is derived as a hash of the secret value K together with the value µ. If randomized signing is used, p' is set to a random number. Line 13: Start of the rejection loop: As long as no valid signature is found (i.e., as long as (z, h) are set to the invalid signal ⊥), Dilithium restarts the signing process (from this line onwards). Line 14: A value y is derived deterministically using a function ExpandMask, which takes the initial value p' and the numerator κ. The value y follows a distribution S̃. γ1 , i.e., the coefficients are evenly distributed in an interval determined by the parameter γ1. Line 15: A vector w is determined by multiplying the matrix A by the value y. Line 16: A function `HighBits` decomposes each coefficient of the vector `w` (such that for each coefficient x, x = x1α + x0) and returns a higher-order value `w1`. The value of α is set to 2γ2, whose specific value is defined in the parameter set. Line 17: The value w1 is hashed together with µ, resulting in a hash value c̃. Line 18: A function SampleInBall converts the hash value c̃ into a polynomial c for which the values ​​of the coefficients have a specific distribution. Line 19: The output value z is calculated based on y, c and s1. Line 20: A value w - cs2 is calculated and decomposed, the less significant bits are returned as r0. Line 21: Each coefficient of z and r0 is checked and tested to see if it falls within a certain range, i.e., if ‖z‖∞≥γ1−β If this is true, then at least one coefficient of z lies outside the open interval (- (γ1 - β), (γ1 -β)). If this is the case for either z or r0 (for their respective range parameters), the signature output (z, h) is set to invalid ⊥, and the loop starting in line 13 enters another iteration. Line 22: “Otherwise” refers to the case where all coefficients of z and r0 fall within the specified range. In this case, signature generation continues in line 23: Line 23: Execute the MakeHint function, which calculates the effect of omitting t0 in the public key (see equation (2)), resulting in a so-called hint vector h. This hint vector h describes, for each coefficient, whether this omission causes an incorrect recovery of HighBits(w - cs2) during verification. These incorrectly recovered coefficients are then corrected in the verification process. Line 24: This line contains two further checks, both of which are necessary to ensure that the error caused by omitting t0 from the public key can be corrected later during verification. Firstly, if the value of ct0 exceeds a predefined threshold at any coefficient (i.e., becomes too large), the MakeHint and UseHint functions are no longer able to correct the error, meaning that the current signature must be rejected. Secondly, the vector h is encoded such that up to ω coefficients of HightBits(w−cs2) These errors can be corrected during the verification process. If this number is exceeded, i.e., more than ω coefficients need to be corrected, the information can no longer be properly encoded, and therefore the errors cannot be corrected during the verification. Consequently, the current signature must be rejected. If the checks show that the signature must be rejected, the signature output (z, h) is set to invalid ⊥, which leads to a further iteration of the loop starting in line 13. Line 25: In the (possibly necessary) next iteration of the rejection loop, which begins in line 13, new values ​​for y must be generated. This is achieved by incrementing the counter κ. This occurs regardless of whether another iteration is required (which is the case if (z, h) = ⊥). Line 26: The signature σ, which includes c̃, z and h, is returned. Dilithium: Check Line 27: The matrix A is determined based on the starting value p, which is contained in the public key pk. Line 28: There is a reference to line 10 above. However, the hash value tr is recalculated as tr = H(p||t1), since it is not part of the public key. Line 29: This line corresponds to line 18, i.e., the hash value c̃ is deterministically transformed into a polynomial c whose coefficients follow a specific distribution. Line 30: First, Az - ct1 · 2 dcalculated (see equation (2)). The UseHints function then uses the hint vector h to correct the error caused by omitting t0 from the public key and ensures that the output w'1 matches the value of w1 calculated during signing (line 16). Line 31: Three tests are performed to verify the validity of the signature: The first and third tests ensure that the signer has completed the rejection steps. The second test verifies the validity of the signature. It calculates H(µ||w'1): This value must match the value c̃ that was included in the signature (see line 17 during signing).

[0035] If the complete vector t were contained in the public key, the auditor could calculate Az−ct=A(y−cs1)+c(As1)+s2=Ay+Acs1−Acs1−cs2=w−cs2

[0036] The checks (or tests) performed during the signing process ensure that the following is true: HighBits(w)=HighBits(w−cs2)=w1.

[0037] The auditor can therefore recalculate the following: c˜=H(μ‖w1) and the verifier can determine whether this c̃ corresponds to the provided signature.

[0038] As explained above regarding the Dilithium implementation, only the part t1 (instead of the complete vector t) is provided to the verifier, which then actually computes the following (see line 30 of the in Fig. (1 pseudocodes shown): Az−ct1⋅2d=A(y+cs1)−c(t−t0)=w−cs2+ct0

[0039] To correct the added term ct0, the signer computes hints h, which represent the effect of this addition, and includes these hints in the signature. Essentially, the hints describe whether the addition of ct0 causes a carry into the high bits of w - cs2 (see Algorithm 1, which is computed for each coefficient). Using the hints, the verifier can subtract the carry from the coefficients and thereby properly restore the following: HighBits(w−cs2)=w1.

[0040] With the existing Dilithium method, calculating the clues requires the part t0 of the public key t. Improvements over existing solutions

[0041] In the examples described here, it is not necessary to store the vector t0 as part of the secret key.

[0042] In an exemplary embodiment, a (potential) signature output (z, c) is fed into a verification algorithm that uses the vector t1 to compute the following: w−cs2+ct0 (see equation (2)). This term is then compared with w−cs2, which is calculated during the signing process. By comparing the high bits of these two terms, the hints h can be calculated.

[0043] An example implementation of a modified signature generation process might include the following steps: (1) Generating a valid signature (z, c), i.e., performing all steps of the Dilithium signing algorithm except for line 23. However, the intermediate value w - cs2 is to be retained. (2) Computing part of the verification algorithm using t1: u:=Az−ct1⋅2d=w−cs2+ct0. (3) Restore ct0: v:=ct0=(Az−ct1⋅2d)−(w−cs2)=u−(w−cs2) (4) Calculate the hints h: h=MakeHint(−ct0,w−cs2+ct0)=MakeHint(−v,u).

[0044] These steps are part of Algorithm 2, which demonstrates a modified dilithium signing algorithm, as shown in line 23 of Fig. 1 is replaced by lines 16 to 18 of Algorithm 2.

[0045] Since the MakeHint function calculates the sum of its two operands (when implemented according to the Dilithium specification or simplified Algorithm 1), the execution of MakeHint(−v,u) the calculation of HighBits(x)(=HighBits(w−cs2)) and HighBits(u)(=HighBits(w−cs2+ct0)) and comparing the results for equality (see Algorithm 1).

[0046] The hints h are set to 1 for coefficients where the results are different, and to 0 when they are the same. However, the variable v still needs to be calculated to check ||v| | ∞ to enable.

[0047] Fig. Figure 2 shows an example block diagram of the modified signature according to Algorithm 2, which is summarized in the dashed block 201. A message M is fed into a block 202, which executes the signing process according to lines 1 to 15 of Algorithm 2 using the private key sk.

[0048] A result w - cs2 is forwarded from block 202 to block 203. The hash value c̃ and the output value z are also determined by block 202 and forwarded to block 204, as well as being provided as part of the signature σ.

[0049] Block 204 performs a verification according to line 16 of Algorithm 2 based on the part t1 of the public key t. Furthermore, Block 204 u=w−cs2+ct0 according to equation (2)) to block 203 and to a block 206.

[0050] Block 203 calculates a difference between the input from block 204 and block 202, i.e. u−(w−cs2)=w−cs2+ct0−(w−cs2)=ct0, which is equal to v and corresponds to line 17 of algorithm 2. This vector v is delivered to block 206 and to block 205.

[0051] Block 205 performs a test operation v=ct0 according to line 19 of algorithm 2, which can lead to a restart of the loop, as explained above.

[0052] Block 206 calculates the hints h according to line 18 of algorithm 2 using the MakeHint function. q based on the inputs -v and u.

[0053] Thus, the signature is located at the exit of block 201. σ=(c˜,z,h) available in message M. Integrated sign-then-verify countermeasure

[0054] Although this modified signature procedure does not charge for full verification, it provides an advantageous way of incorporating a sign-then-verify error countermeasure that detects errors that may have been introduced during the signature process.

[0055] The difference between HightBits(w−cs2) and HighBits(w−cs2+ct0) The absolute value of each coefficient must not exceed 1. Since the size of ct0 lies within a certain range (this is shown in line 24 of Fig. (1 checked), the addition of ct0 to any other value x will never result in a larger difference in the functions HighBits(x) and HighBits(x + ct0).

[0056] The current solution does not calculate the quantity w−cs2+ct0, not by adding ct0 to w - cs2, but instead by evaluating part of the verification process. For example, if an error is introduced into the calculation w = Ay during signing, the corrupted w - cs2 will likely deviate significantly from u := Az - et1 · 2 d ab (which in the undisturbed case is equivalent to w - cs2 + ct0). Thus, by checking whether the difference between HighBits(w - cs2) and HighBits(u) is at most one, certain errors can be detected. Further embodiments and advantages

[0057] The presented solution enables a significant reduction in storage space, freeing up existing memory for other purposes. A device that supports both signing and verifying a key pair can therefore advantageously store only the vector t1 instead of the two vectors t1 and t0, resulting in savings of up to 3.25 kB per key. A device that only supports signing a key pair also benefits, as t1 can be stored instead of t0, and t1 requires less storage space than t0.

[0058] Another advantage is that the presented approach has a built-in error detection capability (if required).

[0059] Another advantage is that the solution works with public data (public key, signature output), which may not require additional security measures such as side-channel protection.

[0060] The calculation is part of the rejection loop, and there are certain conditions that require a restart of the signing process (see [LDK] for details). + 21]), but these conditions are checked last, and failure is therefore unlikely. The additional calculations proposed in the modified signature procedure are therefore likely to be performed only once.

[0061] The current reference implementation of Dilithium proposes a MakeHint function that w0−cs2−ct0 and w1 used as input. In this case, ct0 can be recovered before calculating. r0−ct0=w0−cs2−ct0. The following concerns further examples of processing devices that can be used to implement the invention described herein.

[0062] Fig. Figure 3 shows a processing device 500 with a CPU 501, a RAM 502, a non-volatile memory 503 (NVM), a crypto module 504, an analog module 506, an input / output interface 507 and a hardware random number generator 512.

[0063] In this example, the CPU 501 has access to at least one crypto module 504 via a common bus 505, to which each crypto module 504 is coupled. Each crypto module 504 can, in particular, comprise one or more crypto cores to perform specific cryptographic operations. Examples of crypto cores are: - an AES kernel 509, - a SHA 510 core, - an ECC 511 core and - a lattice-based crypto kernel 508.

[0064] The CPU 501, the hardware random number generator 512, the NVM 503, the crypto module 504, the RAM 502, and the input / output interface 507 are connected to the bus 505. The input / output interface 507 can have a connection to other devices, which may be similar to the processing device 500.

[0065] The 504 crypto module may or may not be equipped with hardware-based security features.

[0066] The 505 bus itself can be masked or open. Instructions for processing the steps described here can be stored in the 503 NVM and processed by the 505 CPU. The processed data can be stored in the 503 NVM or in the 502 RAM. Supporting functions can be provided by the 504 crypto modules (e.g., extending pseudorandom data).

[0067] Steps of the procedure described here can be executed exclusively or at least partially on the crypto module 504, e.g. on the lattice-based crypto kernel 508.

[0068] The processing device 500 can be a chip card operated by direct electrical contact or by an electromagnetic field. The processing device 500 can be a fixed circuit or based on reconfigurable hardware (e.g., a field-programmable gate array, FPGA). The processing device 500 can be coupled with a personal computer, a microcontroller, an FPGA, or a smartphone.

[0069] The solution described here can be used by a customer who wants to provide a secure implementation of lattice-based cryptography on a smart card or other secure element.

[0070] Fig.Figure 4 shows another example of a processing device 600. The processing device 600 comprises a hardware security module 601, a non-volatile memory (NVM) 608, a random access memory (RAM) 609, an interface 610 for communication with other devices, and an application processor 607 coupled to the hardware security module (HSM) 601, the RAM 609, the NVM 608, and the interface 610.

[0071] The HSM 601 comprises a controller 602, a hardware random number generator (HRNG) 606, and at least one crypto module 603. The crypto module 603 includes, for example, an AES core 604 and a lattice-based crypto (LBC) core 605.

[0072] According to one embodiment, the HSM 601 and the application processor 607 can be manufactured on the same physical chip with tight coupling. The HSM 601 provides cryptographic services and secure key storage, while the application processor can perform computationally intensive tasks (e.g., image recognition, communication, motor control). The HSM 601 can be accessed only via a defined interface and considered independent of the rest of the system, so that a security breach of the application processor 607 has only a limited impact on the security of the HSM 601. The HSM 601 can perform all or a subset of the tasks described with respect to the processing device 600 using the controller 602, the LBC 605, which is supported, for example, by an AES 604 and the HRNG 606.It can perform the procedures described here (at least partially) either controlled by an internal controller or as a CMOS circuit. Furthermore, the 607 application processor can also perform the procedures described here (at least partially, e.g., in cooperation with the 601 HSM).

[0073] The processing device 600 with this application processor 607 and HSM 601 can be used as a central communication gateway or as a control unit for (electric) motors in cars or other vehicles.

[0074] In one or more examples, the functions described here can be implemented at least partially in hardware, such as in specific hardware components or a processor. More generally, the procedures can be implemented in hardware, processors, software, firmware, or any combination thereof. When implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing device. Computer-readable media can include computer-readable storage media, which correspond to a tangible medium such as a data storage medium, or communication media, which include any medium that enables the transmission of a computer program from one location to another, for example, according to a communication protocol.In this way, computer-readable media can generally correspond to (1) tangible, non-transient, computer-readable storage media or (2) a communication medium, such as a signal or carrier wave. The data storage media can be any available media accessible by one or more computers or processors to retrieve instructions, code, and / or data structures for implementing the methods described in this disclosure. A computer program product can include a computer-readable medium.

[0075] Examples of such computer-readable storage media, without limitation, include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Furthermore, any connection is correctly referred to as a computer-readable medium, i.e., a computer-readable transmission medium.For example, if instructions from a website, server, or other remote source are transmitted using coaxial cable, fiber optic cable, twisted-pair cable, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwaves, then coaxial cable, fiber optic cable, twisted-pair cable, DSL, or wireless technologies such as infrared, radio, and microwaves are included in the definition of medium. However, it is understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other volatile media, but instead refer to non-volatile, tangible storage media.The terms "disc" and "plate" as used here include CDs (Compact Discs), Laser Discs, Optical Discs, DVDs (Digital Versatile Discs), floppy disks, and Blu-ray Discs, with discs typically reproducing data magnetically, while disks reproduce data optically using lasers. Combinations of the aforementioned data carrier types are also considered computer-readable media.

[0076] The instructions can be executed by one or more processors, such as one or more central processing units (CPUs), digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the term "processor," as used herein, can refer to any of the aforementioned structures or to any other structure suitable for implementing the methods described herein. Furthermore, some aspects of the functionality described herein may be provided in dedicated hardware and / or software modules designed for encoding and / or decoding, or may be contained in a combined codec. The methods may also be implemented entirely in one or more circuits or logic elements.

[0077] The methods of this disclosure can be implemented in a wide variety of different devices or arrangements, including a wireless handset, an integrated circuit (IC), or a group of ICs (e.g., a chipset). Various components, modules, or units are described in this disclosure to highlight functional aspects of devices designed to perform the disclosed methods, but do not necessarily require implementation in different hardware units. Instead, as described above, different units can be combined in a single hardware unit or provided by a grouping of interacting hardware units, including one or more processor(s) as described above, in conjunction with suitable software and / or firmware.

[0078] Although various exemplary embodiments of the invention have been disclosed, it will be clear to those skilled in the art that various changes and modifications can be made which achieve some of the advantages of the invention without departing from its essence and scope of protection. It will be clear to those skilled in the art that other components performing the same functions can be appropriately substituted. It should be noted that features explained with respect to a particular figure can be combined with features of other figures, even where this has not been explicitly stated. Furthermore, the methods of the invention can be implemented either in pure software implementations using appropriate processor instructions or in hybrid implementations using a combination of hardware and software logic to achieve the same results.Such modifications to the concept according to the invention are to be covered by the attached claims. Bibliography [LDK + 21] Vadim Lyubashevsky, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Peter Schwabe, Gregor Seiler, and Damien Stehlé. CRYSTALS-Dilithium: Algorithm specification and supporting documentation (version 3.1). Submitted to the NIST Post-Quantum Cryptography Standardization Project [NIS16], 2021. Specification document: https: / / pq-crystals.org / dilithium / data / dilithium-specification-round3-20210208.pdf. Website: https: / / pq-crystals.org / dilithium. [NIS16] NIST Computer Security Division. Post-Quantum Cryptography Standardization, 2016. Website: https: / / csrc.nist.gov / Projects / Post-Quantum-Cryptography.

Claims

[1] Method for generating a grid-based signature (σ), comprising: - Determining an uncorrected signature (c̃, z), - determining clues (h) based on a verification of the uncorrected signature (c̃, z), wherein the verification is based on a first part (t1) of an uncompressed public key element (t), wherein the second part (t0) of the uncompressed public key element (t) is not used during signature generation, wherein the effects of omitting the second part (t0) are calculated in the backward direction without using this second part (t0), - Providing the uncorrected signature (c̃, z) and the hints (h) as a grid-based signature (σ), - wherein the compression is performed at least partially on one of the following components: - a safety device, - a secure cloud, - a secure service, - an integrated circuit, - a hardware security module, - a trusted platform module, - a crypto unit, - an FPGA, - a processing unit, - a control system, - a smart card. [2] Method according to claim 1, wherein the signature generation is based on or cooperates with the lattice-based digital signature method Dilithium. [3] Method according to one of the preceding claims, wherein the second part (t0) of the uncompressed public key element is longer than the first part (t1) of the uncompressed public key element. [4] Method according to one of the preceding claims, wherein the second part (t0) of the uncompressed public key element is not stored locally. [5] A method according to any one of the preceding claims, wherein the second part (t0) of the uncompressed public key element is not public. [6] A method according to any preceding claim, wherein the verification is used to determine whether an error occurred in the generation of the grid-based signature. [7] Apparatus for generating a grid-based signature (σ), the apparatus being arranged to perform the following steps: - Determining an uncorrected signature (c̃, z), - determining clues (h) based on a verification of the uncorrected signature (c̃, z), wherein the verification is based on a first part (t1) of an uncompressed public key element (t), wherein the second part (t0) of the uncompressed public key element (t) is not used during signature generation, wherein the effects of omitting the second part (t0) are calculated in the backward direction without using this second part (t0), - Providing the uncorrected signature (c̃, z) and the hints (h) as a grid-based signature (σ), - wherein the device is one of the following or comprises at least one of the following: - a safety device, - a secure cloud, - a secure service, - an integrated circuit, - a hardware security module, - a trusted platform module, - a crypto unit, - an FPGA, - a processing unit, - a control system, - a smart card. [8] A computer program product which can be loaded directly into a memory of a digital processing device and which comprises software code sections for carrying out the steps of the method according to any one of claims 1 to 6.

Images