Method and apparatus for compiling cryptographic information, consumable, authentication system, and medium

By using lattice-based cryptography and randomness generation techniques, the threat posed by quantum computers to existing asymmetric cryptography has been addressed, achieving improvements in both security and resource efficiency.

CN113971290BActive Publication Date: 2025-11-18INFINEON TECHNOLOGIES AG
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202110836490.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-07-24
Filing Date
2021-07-23
Publication Date
2025-11-18
Estimated Expiration
2041-07-23

AI Technical Summary

Technical Problem

Existing asymmetric cryptography based on RSA and ECC is vulnerable to attacks by quantum computers, necessitating the development of new cryptographic systems to resist such attacks.

Method used

A lattice-based cryptographic system is adopted, which generates parts of the cryptographic information through randomness and transmits them after the rejection criteria are met. Combined with hash value verification and encryption technology, information security is ensured.

Benefits of technology

It effectively resists quantum computer attacks, improves the security and reliability of cryptographic systems, and reduces the demand for storage and computing resources.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113971290B_ABST
    Figure CN113971290B_ABST
Patent Text Reader

Abstract

A method of compiling cryptographic information is disclosed, comprising: (a) determining a first part of the cryptographic information based on an input and randomness; (b) checking whether a rejection criterion is fulfilled based on the first part of the cryptographic information; (b1) if the rejection criterion is fulfilled, restarting step (a) using different randomness; (b2) if not all parts of the cryptographic information have been generated, determining a subsequent part of the cryptographic information based on the input and randomness and proceeding with step (b), or if all parts of the cryptographic information have been generated, proceeding with step (c); (c) determining a first part of the cryptographic information based on the input and randomness; (d) transmitting the respective part of the cryptographic information; and (e) as long as not all parts of the cryptographic information have been generated, determining a subsequent part of the cryptographic information based on the input and randomness and proceeding with step (d). Furthermore, a corresponding security device, an authentication system and a consumable comprising such a security device and a medium are presented.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] Embodiments of the invention relate to a method for efficiently compiling cryptographic information such as signatures. BACKGROUND

[0002] Various internet and industry standards use asymmetric cryptography based on RSA or Elliptic Curve Cryptography (ECC) to protect data communication between smart cards, smart phones, computers, servers or industrial control systems. As an example, with the RSA algorithm, a public key encryption (PKE) scheme can be implemented that allows sending an encrypted email to a recipient (e.g. with PGP / GPG or S / MIME) without having to exchange a symmetric key first via a secure channel. Instead, the public key of the recipient is sufficient to achieve confidentiality.

[0003] A further application of asymmetric cryptography are digital signatures that are also based on RSA or ECC. They can be used to sign and verify data and the public key is used to check the validity of the signature.

[0004] PKE and digital signatures together are essential in the Transport Layer Security (TLS) protocol that is the basis for secure communication in the internet and used by browsers, smart phones and loT (Internet of Things) devices. TLS establishes a secure channel between two devices where communication is encrypted, checked for manipulation and where the identity of the participants is verified using digital certificates provided by a Public Key Infrastructure (PKI). When connecting to a website of e.g. a bank using https instead of http, the browser uses TLS. Typically, a green lock and other information can be displayed to show that communication with the bank website is running and can prevent so-called man-in-the-middle attacks where an attacker could manipulate the communication and fake the accessed website if no such PKI-based identity check was combined with strong data encryption.

[0005] However, it is known that public keys based on RSA and ECC can be subject to successful attacks using e.g. quantum computers. SUMMARY

[0006] It is an object to improve existing solutions and in particular to efficiently provide cryptographic information.

[0007] The examples presented herein can in particular be based on at least one of the following solutions. A combination of the following features can be utilized to achieve the desired results. The features of the method can be combined with any of the features of a device, apparatus or system and vice versa.

[0008] A method for compiling cryptographic information is presented comprising:

[0009] (a) determining a first part of the cryptographic information based on the input and on randomness;

[0010] (b) checking whether a rejection criterion is met based on the first part of the cryptographic information;

[0011] (b1 ) if the rejection criterion is met, restarting step (a) with different randomness;

[0012] (b2) if all parts of the cryptographic information have not been generated, determining a subsequent part of the cryptographic information based on the input and on randomness, and proceeding to step (b), or if all parts of the cryptographic information have been generated, proceeding to step (c);

[0013] (c) determining a first part of the cryptographic information based on the input and on randomness;

[0014] (d) transmitting a respective part of the cryptographic information;

[0015] (e) as long as all parts of the cryptographic information have not been generated, determining a subsequent part of the cryptographic information based on the input and on randomness, and proceeding to step (d).

[0016] The randomness can comprise at least one of true randomness, pseudo-randomness or deterministic features.

[0017] According to an embodiment, the cryptographic information is or comprises at least one of:

[0018] - a signature;

[0019] - pairing information;

[0020] - information associated with a zero-knowledge proof.

[0021] According to an embodiment,

[0022] - wherein, prior to step (d), the respective part of the cryptographic information has been encrypted with a secret key; and

[0023] - the method further comprises transmitting the secret key.

[0024] According to an embodiment, the secret key is transmitted after the last encrypted part of the cryptographic information has been transmitted.

[0025] According to an embodiment, the input is a message.

[0026] According to one embodiment, the method further comprises:

[0027] - for each part of the cryptographic information determined by the loop of steps (a) to (b2), generating and storing a first hash value associated with the respective part of the cryptographic information;

[0028] - in the loop of steps (c) to (e), a second hash value is generated for each part of the password information and the first hash value associated with the same part of the password information is compared with the second hash value; and

[0029] - only if the first hash value corresponds to the second hash value, the method is continued.

[0030] According to embodiments, in case the first hash value does not correspond to the second hash value, the method comprises triggering at least one of the following actions:

[0031] - issuing a notification or an alarm;

[0032] - stopping the method;

[0033] - entering an exception handling;

[0034] - restarting step (a) with a different randomness.

[0035] According to embodiments, the method further comprises:

[0036] - when processing the loop determined by steps (a) to (b2), only one part of the password information is stored at a time.

[0037] According to embodiments, the password information is compiled based on the parts of the password information transmitted.

[0038] According to embodiments, the method comprises authenticating based on the password information.

[0039] According to embodiments, the password information or the part of the password information is processed with at least one cryptographic operation.

[0040] According to embodiments, the method is used for a secure device or for operating a secure device, wherein such a secure device comprises at least one of:

[0041] - an integrated circuit,

[0042] - a hardware security module,

[0043] - a trusted platform module,

[0044] - a cryptographic unit,

[0045] - an FPGA,

[0046] - a processing unit,

[0047] - a controller,

[0048] - a smart card.

[0049] Further, a secure device for compiling cryptographic information is proposed, the secure device being arranged to perform the following steps:

[0050] (a) determining a first part of the cryptographic information based on the input and a randomness;

[0051] (b) checking whether a rejection criterion is fulfilled based on the first part of the cryptographic information;

[0052] (b1 ) if the rejection criterion is fulfilled, restarting step (a) using a different randomness;

[0053] (b2) if all parts of the cryptographic information have not yet been generated, determining a subsequent part of the cryptographic information based on the input and a randomness, and proceeding with step (b), or if all parts of the cryptographic information have been generated, proceeding with step (c);

[0054] (c) determining a first part of the cryptographic information based on the input and a randomness;

[0055] (d) transmitting a respective part of the cryptographic information;

[0056] (e) as long as all parts of the cryptographic information have not yet been generated, determining a subsequent part of the cryptographic information based on the input and a randomness, and proceeding with step (d).

[0057] Further, a consumable is proposed, comprising a secure device as described herein.

[0058] In addition, a system is proposed, comprising a secure device as described herein and a host, wherein the secure device is arranged to transmit a respective part of the cryptographic information to the host.

[0059] According to an embodiment, the host is arranged to authenticate the secure device based on the received parts of the cryptographic information.

[0060] Further, a computer program product is provided, which can be directly loadable into the memory of a digital processing device, comprising software code portions for performing the steps of the method as described herein. BRIEF DESCRIPTION OF DRAWINGS

[0061] Embodiments are illustrated and described with reference to the drawings. The drawings are intended to illustrate basic principles, thus only aspects necessary for understanding the basic principles are shown. The drawings are not drawn to scale. In the drawings, the same reference designations denote similar features.

[0062] Figure 1 A process of compiling a signature and providing the signature from the cryptographic engine to the terminal is shown;

[0063] Figure 2An exemplary flow chart showing the steps of a method to be run on, for example, a cryptographic engine;

[0064] Figure 3 An exemplary flow chart showing the steps of a method to be run on, for example, a cryptographic engine; Figure 2 An exemplary flow chart showing the steps of a method to be run on, for example, a cryptographic engine;

[0065] Figure 4 An exemplary arrangement of a processing device is shown, comprising a CPU, a RAM, a non-volatile memory, a cryptographic module, an analog module, an input / output interface and a hardware random number generator;

[0066] Figure 5 An alternative arrangement with a hardware security module (HSM) is shown. DETAILED DESCRIPTION

[0067] The solutions described herein are applicable to both classical cryptographic systems as well as post-quantum cryptographic systems.

[0068] A quantum computer can be described as a computer that directly exploits quantum mechanical phenomena to speed up processing. A key concept in establishing a quantum computer is the so-called qubit or quantum bit (qubit) that stores a state in a quantum register. Such a quantum computer can be used to successfully break cryptographic concepts that were considered secure before such processing power was available.

[0069] Hence, the general motivation is to move away from classical asymmetric cryptographic systems (RSA / ECC) to schemes that cannot be successfully attacked by a quantum computer. Therefore, new solutions are needed for signature schemes, key exchange and public key encryption that are not based on the same fundamentals as RSA and ECC (i.e. the discrete logarithm problem / factorization). This need for new technical solutions has been recognized by standardization bodies such as NIST (National Institute of Standards and Technology) that are investigating alternative encryption systems.

[0070] A cryptographic system can be a public key encryption, a key exchange or a signature scheme, or can be an advanced scheme such as homomorphic encryption or attribute-based encryption. In public key encryption, data is encrypted using a non-secret public key, which can only be decrypted using an associated secret key. In a signature scheme, a message is signed using a secret key, and the associated public key can be used to verify that the signer possessed the secret key and was thus authorized to produce the signature. Key exchange or key establishment is an interactive protocol in which two parties establish a secret key that is unknown to a passive or sometimes active adversary or eavesdropper. Again, different options can be used to combine public key encryption, key exchange or signature schemes into a protocol, such as Transport Layer Security (TLS).

[0071] One approach considered resistant to quantum computer attacks is lattice-based cryptography. Lattice-based cryptography may become the successor to RSA and ECC and can operate on large matrices (standard lattices) or polynomial rings (ideal lattices). For more information on lattice-based cryptography, see, for example, https: / / en.wikipedia.org / wiki / Lattice-based_cryptography.

[0072] A lattice is a structure created by linear combinations of integers of basic vectors. Therefore, a lattice can be described as a regular structure in n-dimensional space. Similarly, a lattice can be viewed as an arrangement of points in a Euclidean space with a regular structure. Given n linearly independent vectors b1,…, The lattice generated by them Defined as:

[0073]

[0074] in,

[0075] –b1,…,b n It is the foundation of form, and

[0076] –from The element is from A vector of m entries.

[0077] In Ge In n-dimensional space, certain fundamental problems (such as finding short basis vectors) are considered computationally difficult, or at least quite complex, to be unsuitable for encryption. Typically, the difficulty of breaking lattice-based cryptosystems can be reduced, or is related to the difficulty of solving such fundamental problems. Lattice-based cryptography or lattice-based cryptosystems are cryptosystems whose security is based on the difficulty of certain mathematically difficult problems within lattices, or related to that difficulty.

[0078] Lattices can be used to construct cryptographic systems. User-friendly examples include the error learning (LWE) problem and the ring LWE (RLWE) problem, and lattice-based cryptography is also known. In this context, a "problem" refers to a mathematical problem (e.g., finding something) that is considered difficult to solve (i.e., no polynomial-time algorithm is available) but is also capable of constructing cryptographic schemes (e.g., factorization problems similar to RSA or discrete logarithms in ECC).

[0079] Typically, to solve the LWE problem, given an approximately random system of linear equations concerning the secret vector s, it is necessary to recover the secret vector s over a ring of integers modulo q. Therefore, the system of linear equations is distorted due to a certain amount of randomness, making it difficult for known algorithms to solve.

[0080] Thus, the LWE and RLWE problems allow to construct schemes where the scheme designer cannot really see the lattice structure in practice. However, when proving the security of LWE / RLWE based schemes, the lattice structure is also used when trying to solve the LWE or RLWE problem, as lattice algorithms are an efficient way to find the secret vector or polynomial s. This is also described as solving the "lattice problem". The RLWE problem runs over a polynomial ring and supports security reductions to the difficulty problem on ideal lattices, while LWE is able to reduce to arbitrary lattices. Ideal lattices carry more structure, although not all lattices are ideal lattices, but also allow to design schemes with more practical public key, ciphertext and signature lengths.

[0081] Prominent examples of lattice-based cryptography are the so-called NTRU and NTRU signature schemes and the so-called GGH (Goldreich-Goldwasser-Halevi, see e.g. https: / / en.wikipedia.org / wiki / GGH_encryption_scheme) scheme. For most of the schemes, the transition from public key encryption to key exchange is trivial. In addition, for PKE, various security levels can be achieved using standard transformations, e.g. semantic security against chosen plaintext attacks (CPA) or semantic security against chosen ciphertext attacks (CCA).

[0082] This has been shown exemplarily for the NewHope scheme, which can also be instantiated as a CPA-secure or CCA-secure PKE [NewHopeNistl7]. NewHope-Simple and other schemes are direct adaptations of the scheme called LPR10 (see [NewHopeSimplePaperEprintl6]). Examples of lattice-based signature schemes are Dilithium, BLISS, GLP12 and qTESLA (see e.g. https: / / csrc.nist.gov / Projects / Post-Quantum-Cryptography / Round- 1-Submissions).

[0083] Technical challenges regarding lattice-based cryptography

[0084] When implementing lattice-based cryptography and lattice-based cryptographic systems on computers, microcontrollers, integrated circuits, in hardware-software co-design or as fixed circuitry, several technical challenges arise when performing cryptographic operations (e.g. signing, encrypting, decrypting, verifying, key generation).

[0085] Examples of such technical challenges arising in the art are:

[0086] - improved performance by using a specially optimized sequence of operations and using all features (special registers or instructions) of the available target hardware to perform the steps of the cryptographic system.

[0087] - performing cryptographic operations using a minimum amount of volatile or non-volatile memory.

[0088] - implementing cryptographic operations or parts thereof with a minimum amount of logic circuits and storage units (e.g. formed by CMOS technology) given a performance target.

[0089] - effective and comprehensive protection against implementation attacks (also known as physical attacks, observatory attacks, invasive and semi-invasive attacks).

[0090] It is noted that protection against implementation attacks and / or physical attacks is particularly advantageous for cryptographic systems executed on a secure controller or in any hostile environment (e.g. hardware security module, HSM).

[0091] Possible attacks are side-channel attacks, where an attacker tries to obtain secret information by observing the physical behavior of the device, like power consumption (e.g. simple or differential power analysis (SPA / DPA)), electromagnetic radiation or temperature. Furthermore, fault attacks are feasible in case an attacker tries to introduce disturbances in the execution flow or data (e.g. with a laser) to obtain secret information or to influence the behavior of the device.

[0092] A characteristic of implementation attacks is that such attacks do not exploit weaknesses in the mathematical description of the scheme (which would be considered as cryptanalysis), but in the way the scheme is implemented on a particular device. Typically, when performing an implementation attack, the adversary is assumed to have access to the device.

[0093] Typically, devices like smart cards are constructed in such a way that physical effects (e.g. power consumption or radiation) are disguised to make it difficult to obtain security critical assets. A common approach to counter physical attacks is to perform randomized values to prevent invasive and non-invasive attacks that aim at extracting secret keys or intermediate values from the device. However, implementing such randomization or redundancy in an efficient way without adding additional attack opportunities is a technical challenge.

[0094] Symbols and abbreviations

[0095] In particular, the following symbols, abbreviations and references are used:

[0096] q is an integer,

[0097] k is an integer,

[0098] n is an integer,

[0099] mod q is a modulo q operation defined on integers in the range [0, q-1] of results,

[0100] Z is an integer (written as a number without a fractional part), for the definition of "number", see https: / / en.wikipedia.org / wiki / Number; for the definition of "fractional part", see https: / / en.wikipedia.org / wiki / Fraction_(mathematics),

[0101] is a real number (a value that can represent a continuous quantity of distance along a line),

[0102] Z q is the ring of integers modulo q, which is the quotient ring of the equivalence classes of integers modulo q, Z / qZ,

[0103] X is indeterminate,

[0104] f is a polynomial of maximum degree n,

[0105] R = Z[X] / (f) is the ring of integer polynomials modulo f; an element v e Z[X] / (f) can be represented by an integer polynomial of degree less than n with coefficients reduced modulo q, or alternatively can be represented as a vector of coefficients v e Z n ,

[0106] R q = Z q [X] / (f) is the ring of integer polynomials modulo both the polynomial f and the integer q; an element v e Z q [X] / (f) can be represented by an integer polynomial of degree less than n with coefficients reduced modulo q, or alternatively can be represented as a vector of coefficients v e Z

[0107] v e R q is a polynomial (shown in bold) that is an element in R q ,

[0108] v[i] is the vector at position i or

[0109] the coefficient of the polynomial v e R q ,

[0110] θ is an error distribution,

[0111] is a random sample from a set or distribution,

[0112] D Z,σis a discrete Gaussian distribution over integers with standard deviation s,

[0113] ψ k is a binomial distribution with integer parameter k,

[0114] U() is a uniform distribution,

[0115] 1001 b is a number in binary representation, e.g., 1001 b = 9,

[0116] U(R q,k ) is a uniform random sampling of a polynomial in R q with all coefficients being uniform random numbers in [-k, k],

[0117] FFT is a fast Fourier transform,

[0118] NTT is a number theoretic transform,

[0119] DPA is a differential power analysis,

[0120] SPA is a simple power analysis,

[0121] ALU is an arithmetic logic unit,

[0122] PKE is public key encryption,

[0123] KEM is a key encapsulation mechanism,

[0124] CCA is a chosen ciphertext attack,

[0125] CPA is a chosen plaintext attack,

[0126] IND is indistinguishability.

[0127] Quotient rings are structures in abstract algebra. Details are found e.g. at https: / / en.wikipedia.org / wiki / Quotient_ring.

[0128] Ideal lattices and polynomial algorithms

[0129] Currently, there are two kinds of lattice-based cryptography, namely ideal-lattice-based cryptography and standard-lattice-based cryptography. An intermediate view is the so-called module-lattice-based cryptography which mixes concepts from ideal lattices and standard lattices. See e.g. [NewHopeNistl7].

[0130] The basic operations in ideal-lattice-based cryptography are polynomial multiplication, addition or subtraction in the quotient ring

[0131] R q = Zq [x] / (f),

[0132] where the modulus q is an integer and the dimension (number of coefficients) is an integer n. A polynomial a e R q can be represented as an array of values and individual values a[i] at integer positions i can be accessed. All major computations in lattice-based cryptosystem schemes can be performed on arrays of values modulo q.

[0133] For the ring of quotients, operations like addition and multiplication can be defined. Addition c = a + b, a, b, c e R q , can be defined as:

[0134]

[0135] where i is an integer, q is an integer, a[i] is the ith coefficient of a, b[i] is the ith coefficient of b, and x is indeterminate. Subtraction c = a - b operates in the same way, with “+” replaced by “-”.

[0136] The product c = a · b of polynomials a, b, c e R q can also be computed. It is defined as ordinary polynomial multiplication (sometimes also called “textbook” multiplication), followed by reduction modulo the polynomial f and reduction modulo the integer q, i.e.,

[0137]

[0138] The formula for polynomial multiplication can be simplified by considering the following special rule: when f = x n + 1, x n ≡ -1, but similar polynomials can also be used accordingly:

[0139]

[0140] where i and j are integers, q is an integer, a[i] is the ith coefficient of a, b[j] is the jth coefficient of b, and x is indeterminate.

[0141] Sparse multiplication

[0142] Efficiency of polynomial algorithms can be obtained by algorithms that exploit specific properties of polynomials. As an example, a polynomial s e R q may have only few non-zero coefficients, it can consist only of coefficients that are one or minus one, or it can typically have small coefficients. Also, it can exhibit a combination of these properties.

[0143] Number theoretic transform (NTT)

[0144] Implementations following this formula will require n 2 submodular multiplications, and thus will be quite expensive.

[0145] Another approach to fast polynomial multiplication is the Number Theoretic Transform (NTT). The NTT is basically a Fast Fourier Transform (FFT) defined over a finite field or ring. Thus, all the complex roots of unity of the FFT are exchanged for integer roots of unity, and the computation is performed in the ring of integers modulo an integer q. Polynomial multiplication for a, b, c e R q using the NTT can be computed as:

[0146]

[0147] where, denotes coefficient-wise multiplication, is the transform of polynomial a, is the transform of polynomial b, and NTT -1 () is the inverse transform. The coefficient-wise multiplication can be defined as:

[0148]

[0149] The advantage of the NTT is that, when using efficient algorithms, the polynomial multiplication operation requires only roughly n log2 n submodular multiplications, and a reduction modulo

[0150] f = x n + 1

[0151] (socalled circular convolution property) or reduction modulo

[0152] f = x n - 1

[0153] can be incorporated into the NTT algorithm. Thus, an n-point NTT together with an n-coefficient polynomial is enough.

[0154] To formally introduce the NTT, the choice of parameters can be restricted; otherwise, the following can be set to make the NTT exist:

[0155] f = x n + 1

[0156] and

[0157] q ≡ 1 mod 2n.

[0158] In addition, the polynomials can be defined as follows:

[0159]

[0160] such that:

[0161]

[0162] wherein:

[0163]

[0164] wherein the integer ω is the 2n-th primitive root of unity modulo q, and the integer Thus, γ is the square root of ω modulo q.

[0165] The inverse transform is implemented similarly. For a polynomial can be defined as:

[0166]

[0167] wherein:

[0168]

[0169] A direct computation of the NTT with the previously given definitions has quadratic complexity and is not more efficient than the textbook method. Thus, in order to implement fast polynomial multiplication using the convolution theorem, a fast algorithm for computing the NTT is required. This can be achieved, for example, by the Cooley-Tukey radix-2 decimation-in-time (DIT) algorithm (see, e.g., https: / / en.wikipedia.org / wiki / Cooley-Tukey_FFT_algorithm) or by the decimation-in-frequency (DIF) algorithm via an implementation of the NTT in Z q with O(n log n) operations. The DIT NTT algorithm divides the computation in a recursive manner into a subproblem for even inputs of the NTT and a subproblem for odd inputs of the NTT.

[0170] Cryptographic engine / consumable and external

[0171] The examples described herein allow a cryptographic engine to provide cryptographic information, which can be part of a controller-like hardware unit or can be a hardware unit on its own. The cryptographic information can be, for example, a signature.

[0172] The method can also be used for zero-knowledge proof or pairing operations.

[0173] The cryptographic engine can be a cryptographic engine capable of at least one cryptographic operation.

[0174] The cryptographic engine can be a chip or a part of a chip. The cryptographic engine can be part of a microcontroller, which in particular can run within a microcontroller or any processing device. The cryptographic engine, the microcontroller or the processing device can be embedded in a car, an industrial (control) device or engine, a medical device, a sensor, etc.

[0175] The cryptographic engine can be attached to a so-called "consumable" that provides something, e.g. a signature, to another entity, also called external entity (or simply "external", also called host or host device).

[0176] The consumable can provide something "to be consumed" to the host. There are many examples for combinations of consumables and hosts, e.g.

[0177] - a print cartridge - a printer;

[0178] - a battery - a device using the battery;

[0179] - a refill cartridge - an electronic cigarette;

[0180] - a credit balance card - a pre-paid handy;

[0181] - a coffee capsule - a coffee machine;

[0182] - a filter cartridge - a water filter;

[0183] - a medical consumable - a medical device.

[0184] The consumable can be physically connected to the host. The host can be configured to authenticate the consumable, and the host can also be configured to use the consumable only in case of successful authentication.

[0185] There can also be an option that the cryptographic engine is attached to a device or part of a device, wherein such device uses the cryptographic engine for authentication purposes, e.g. to a cloud or a network.

[0186] Efficient encoding of cryptographic information

[0187] The solution presented herein allows the cryptographic engine to handle small physical memory and still participate in cryptographic operations involving computations on e.g. large data, e.g. keys.

[0188] The signing process can comprise the following steps:

[0189] (1) generating a signature part sig based on the message m and randomness k e i .

[0190] (2) testing (at least one) statistical property of the signature part sig i by testing (at least one) statistical property of the signature part sig​i A rejection sampling is performed.

[0191] (2a) If the test fails, the signature part sig i is rejected, i.e. the rejection criterion is met. In such a case, a different randomness is used and the generation of the signature part is restarted.

[0192] (2b) If the test succeeds, i.e. the rejection criterion is not met, the signature part sig i is accepted. The generation of the signature continues with the next signature part sig j (j = i + 1) and branches to step (2) as long as the generation of the signature is not completed, i.e. as long as not all signature parts have been generated.

[0193] Note that the signature part sig i is different from the signature part sig j .

[0194] The examples described herein avoid that the result of the computation is visible outside the security boundary of the cryptographic engine in case the statistical properties of the cryptographic information (e.g. the signature) revealed by the rejection sampling do not meet the predefined requirements.

[0195] The computation can advantageously be split into parts, thereby providing individual results in a serial manner.

[0196] As an option, these individual results can be encrypted and only sent across the security boundary of the cryptographic engine after encryption.

[0197] For each signature part sig i , it is determined whether the part meets the rejection criterion. The signature parts are only transferred from the cryptographic engine in case none of the signature parts sig i meets the rejection criterion. Otherwise, different signature parts are determined based on a different randomness k e and these signature parts are subject to the rejection criterion. If none of the signature parts sig i is rejected, the signature parts sig i are computed again and then provided one after the other from the cryptographic engine to a different entity, e.g. a terminal. This entity is then able to combine, e.g. concatenate, the received signature parts sig i into the complete signature sig.

[0198] This allows the cryptographic engine to use only limited resources when compiling and providing the signature, e.g. as part of an authentication. This can be particularly useful for cryptographic engines having limited storage space and / or limited electrical energy stored in or accessible to the cryptographic engine.

[0199] Figure 1 The process of compiling the signature and providing the signature from the cryptographic engine 102 to the terminal 101 (in this example, the terminal 101 acts as a host or “external”) is visualized.

[0200] The terminal 101 can be any device external to the exemplary cryptographic engine 102. The cryptographic engine 102 can be a smart card or any device with a secure environment. As mentioned above, the cryptographic engine 102 can be attached to or combined with a consumable.

[0201] The terminal 101 provides a message 103 for which the cryptographic engine 102 has to provide a signature. This signature can then be used for authentication purposes.

[0202] The cryptographic engine 102 can in particular comprise the following:

[0203] - a cryptographic function “sign” for compiling the signature;

[0204] - generating or obtaining randomness k e , which can be ephemeral key;

[0205] - a private key k s for the cryptographic function;

[0206] - optionally: a symmetric key k j for the encryption function encr (the symmetric key k j may be generated locally, e.g. randomly, pseudo-randomly or in a deterministic way).

[0207] Note that the randomness k e may comprise at least one of a true randomness, a pseudo-randomness or a deterministic feature. The randomness can be generated by the cryptographic engine based on a seed or any true or pseudo-random number or feature. The cryptographic engine is in particular able to determine a plurality of different numbers, each number representing (a different) randomness.

[0208] Note also that the private key k s may be stored in a memory of the cryptographic engine 102 or can be hardwired. One option is to determine the private key k s based on a seed stored in or hardwired into the cryptographic engine 102.

[0209] As an alternative, the message m can be provided by any component other than the terminal 101.

[0210] The cryptographic engine 102 compiles a signature part sig s based on the message m, the private key k e and the randomness k i . There is one signature part sig iCheck if it meets the rejection criterion. If it does, then use different randomness k. e Restart signature generation. If there is no signature part (sig)... i If the rejection criteria are met, the signature portion sig is recalculated. i And then it is provided from the cryptographic engine 102 to the terminal 101.

[0211] This has the advantage that all signature parts (sig) are determined in the first round. i After that, it became clear that these signature parts were sig i None of them meet the rejection criteria. Therefore, an attacker cannot use the signature portion sig. i This determines or derives the key used by the cryptographic function `sign`. Therefore, the signature part `sig`... i Each of them can be allowed to leave the security domain of the cryptographic engine 102 and can be sent to the terminal 101.

[0212] However, one option is to use a symmetric key k. j and the encryption function encr to process at least one signature portion sig leaving the cryptographic engine 102 (towards terminal 101). i Encryption is performed. In the final signature section, sig... i After the key has been transmitted to terminal 101, cryptographic engine 102 can then send the symmetric key k. j This allows terminal 101 to decrypt the signature portion it has already received. This choice adds a layer of security because terminal 101 can only decrypt the signature portion, and therefore only after it receives the symmetric key k from cryptographic engine 102. j Then confirm the complete signature.

[0213] Figure 2 An exemplary flowchart is shown for compiling a signature at cryptographic engine 102 and forwarding the signature portion to terminal 101:

[0214] Step 201: The cryptographic engine 102 receives message m from the terminal 101.

[0215] Step 202: Initialize counter i (i.e., set it to 0). Generate randomness k. e .

[0216] Step 203: Use the cryptographic function sign based on randomness k e And the signature part sig of message m is determined i :

[0217] sig i =sign(m,k e ,i).

[0218] Note that the function "sign" generates a partition based on the value of the counter i.

[0219] Hence, the message m can be processed to determine a number of signature parts sig i based on the value of the counter i.

[0220] The function sign can use the private key k s to compile the signature.

[0221] The randomness k e may be generated locally at the crypto engine 102. It can be that the generated randomness k e is not suitable, in the sense that it can be cryptographically "weak" in the sense that using this particular randomness k e to compile the signature parts sig i allows an attacker to derive details about the secret key k s and / or details about the cryptographic function sign. However, using a weak randomness k e to compile the signature parts sig i may be preferable not to leave the domain of the crypto engine 102.

[0222] Hence, a rejection criterion is used to detect any unsuitable signature parts sig i , which leads to restarting the compilation of the signature parts with a different (hopefully more suitable) randomness k e .

[0223] Step 204: Check whether the signature parts sig i satisfy the rejection criterion. If this is the case, restart the process, i.e. branch to step 202, compile the signature parts using a different randomness k e .

[0224] An exemplary rejection criterion can be as follows: one component of the signature, e.g. a coefficient x q of a polynomial x e R i may be larger than a threshold t. If any x i e R q is larger than the threshold t, the rejection criterion is positive (i.e. satisfied).

[0225] If the signature parts sig i do not satisfy the rejection criterion, there is no rejection and the subsequent step 205 is continued.

[0226] Step 205: Check whether all signature parts have been compiled. If this is the case, branch to step 207. If not all signature parts have been compiled, branch to step 206.

[0227] Step 206: The counter i is increased by 1 and step 203 is continued, i.e. the next signature part sig i .

[0228] Note that after all signature parts have been compiled (before entering step 207), the rejection criterion has been successfully tested for each of the signature parts, i.e. no signature part sig i triggered the rejection criterion. Therefore, the signature comprising the signature parts sig i is considered as valid and suitable to be transmitted outside the cryptographic engine 102. However, so far, the signature parts have not been transmitted to the terminal 101 and, due to the memory limitations of the cryptographic engine 102, they can not have been stored in the memory. Therefore, the signature parts will be computed again in the next steps based on the same randomness k e and then directly transmitted to the terminal 101:

[0229] Step 207: The counter i is reset (i.e. set to 0).

[0230] Step 208: This step 208 corresponds to the above described step 203: determining a signature part sig i .

[0231] Step 209: The signature part sig i is transmitted to the terminal 101.

[0232] Step 210: It is checked whether all signature parts have been compiled. If this is the case, branch to step 212. If not all signature parts have been compiled, branch to step 211.

[0233] Step 211: The counter i is increased by 1 and step 208 is continued, i.e. the next signature part sig i .

[0234] Step 212: The provision of the signature to the terminal 101 is completed.

[0235] Figure 3 An alternative embodiment is shown for compiling the signature at the cryptographic engine 102 and forwarding the signature parts to the terminal 101. Figure 3 The flowchart is based on Figure 2 . In contrast to Figure 2 , between steps 203 and 204, step 301 is entered and between steps 208 and 209, step 302 is entered. These added steps 301 and 302 provide the following features:

[0236] Step 301: Based on the signature part sig i determine a hash value h i :

[0237] h i = HASH(sig i ),

[0238] where HASH() is a hash function, e.g. a one-way function that determines a hash value based on an input.

[0239] Furthermore, the hash value h i is stored for further comparison purposes (see step 302). Thus, after step 205, a hash value h i has been computed and stored for each of the signature parts sig i .

[0240] Step 302: For each of the signature parts sig i , the previously stored hash value h i is compared with a hash value HASH(sig i ) computed based on the signature part sig i determined in step 208.

[0241] Thus, by comparing their hash values, it is checked whether the steps 203 and 208 result in the same signature parts.

[0242] If the hash values are identical, no tampering or attack has been detected, and step 209 follows. If the hash values do not match, a branch to step 202 is taken, and the compilation of the signature parts is restarted with a different randomness k e .

[0243] Figure 3 The illustrated choice is an extension of the integrity check: in a first loop comprising steps 202, 203, 301, 204, 205 and 206, a hash value h i is computed for each of the signature parts sig i . In a second loop comprising steps 208, 302, 209, 210 and 211, the hash value is again computed for each signature part, and compared with the previously computed hash value h i . In case of a discrepancy, the integrity of the associated signature part is compromised, and the process of compiling the signature parts is restarted.

[0244] One choice is that at least one signature part sig i is encrypted before being transmitted from the cryptographic engine 102 to the terminal 101, in combination with the method illustrated in Figure 2 or the alternative method illustrated in Figure 3 . For example, the symmetric encryption function encr and the symmetric key k j may be used to obtain the encrypted signature part sigi_enc :

[0245] sig i_enc = encr(sig i , k j )

[0246] The encrypted signature part sig i_enc is transmitted to the terminal 101. If all signature parts are transmitted to the terminal 101, the symmetric key k j can then be transmitted by the cryptographic engine 102 to the terminal 101 to enable the terminal 101 to decrypt the signature for further processing.

[0247] Thus, the terminal 101 can determine the signature of the message m by concatenating the signature parts sig i and, in this example, also apply decryption using the symmetric key k j .

[0248] This optional feature ensures that the terminal 101 is only able to decrypt the encrypted signature parts after it has received the symmetric key k j .

[0249] One option is to generate the symmetric key k j by the cryptographic engine and use it for each signature or a predetermined number of signatures. Another option is that the symmetric key k j is only used for a predetermined number of signature parts. Thus, the cryptographic engine 102 can provide at least one symmetric key, in particular several symmetric keys, to the terminal 101.

[0250] In an exemplary use case, the terminal 101 can determine whether the cryptographic engine 102 (or a consumable associated with this cryptographic engine 102) has been successfully authenticated. If this is the case, the terminal 101 can proceed and, for example, utilize resources provided by a consumable attached to the cryptographic engine 102.

[0251] Additional advantages and implementations

[0252] The examples described herein can be used in a hardware module, e.g. the cryptographic engine. The hardware module can be any hardware accelerator, such that the hardware module requires less internal memory space. The hardware module can be or comprise a secure module, e.g. an integrated secure module, also referred to as hardware security module (HSM), or a controller with or without an authentication module.

[0253] The input can flow to the hardware module. The hardware module compiles the result, preferably only storing a part of the data and / or what is needed for the computation itself. By splitting the computation into parts, the whole challenge and / or response does not have to be stored in the hardware module immediately. Instead, only parts can be stored and (sequentially) computed.

[0254] Thus, it is not necessary for the hardware module to provide a memory large enough to store the result of the whole computation.

[0255] Thus, the computation by the hardware module can be split into parts, which can be executed serially without the need that all previous or future information is available. By “previous or future information” is meant information needed for previous computations or information to be provided for future computations.

[0256] Advantageously, the result of the computation by the hardware module can be kept secret depending on a condition that is met (or not met) at the end of several computations. Only when the condition is met and a rejection criterion is not met, the (complete) result of the computation becomes apparent to the outside of the hardware module.

[0257] The outside of the hardware module can be any entity that is able to communicate with the hardware module.

[0258] The methods presented herein can be applied in combination with the Dilithium signature (see, e.g., https: / / pq-crystals.org / dilithium / data / dilithium-specification-round2.pdf) or other signature algorithms (other lattice-based algorithms submitted to the ongoing NIST competition for PQ encryption and other algorithms sharing similar structure).

[0259] The solutions described herein can be combined with the GLP protocol. In [T. Gϋneysu, V. Lyubashevsky, T. Poppelmann, H. Schoenmakers, Practical Lattice-Based Cryptography: A Signature Scheme for Embedded System, CHES 2012, LNCS 7428, pp. 530-547, 2012] a signature scheme is presented.

[0260] For example, the hardware module can be an authentication module for which the secret has to be stored outside of the module. For example, the authentication module can be integrated with a non-secure controller. The secret key can be stored encrypted in the non-secure controller for later use.

[0261] ​The described examples can be used in particular in conjunction with lattice-based cryptography. The hardware modules can require much less memory than would be required to fully compute the corresponding cryptographic operations (e.g. signatures).

[0262] Implementation examples

[0263] Figure 4 A processing device 500 is shown, comprising a CPU 501, a RAM 502, a non-volatile memory 503 (NVM), cryptographic modules 504, an analog module 506, an input / output interface 507 and a hardware random number generator 512.

[0264] In this example, the CPU 501 accesses at least one cryptographic module 504 through a shared bus 505, each cryptographic module 504 being coupled to the shared bus 505. Each cryptographic module 504 can comprise in particular one or more cryptographic cores to perform certain cryptographic operations. Exemplary cryptographic cores are:

[0265] - an AES core 509,

[0266] - an SHA core 510,

[0267] - an ECC core 511, and

[0268] - a lattice-based cryptography (LBC) core 508.

[0269] The lattice-based cryptography core 508 can be provided to perform or accelerate lattice-based cryptography.

[0270] The CPU 501, the hardware random number generator 512, the NVM 503, the cryptographic modules 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 514 to other devices, possibly similar to the processing device 500.

[0271] The cryptographic modules 504 can or can not be equipped with hardware-based security components. As an option, the cryptographic modules 504 can comprise a random number generator.

[0272] The analog module 506 is supplied with power 513 via electrical contacts and / or via an electromagnetic field. This power is provided to drive the circuits of the processing device 500 and can in particular allow the input / output interface to initiate and / or maintain a connection with other devices via the connection 514.

[0273] The bus 505 can be hidden or ordinary per se. Instructions to process the steps described herein can be stored in the NVM 503 in particular and processed by the CPU 501. Processed data can be stored in the NVM 503 or the RAM 502. Support functions can be provided by the crypto module 504 (e.g. expansion of pseudo-random data). Random numbers can be provided by the hardware random number generator 512.

[0274] The steps of the methods described herein can be performed on the crypto module 504 exclusively or at least partially. For example, the instructions can be stored in the lattice-based crypto core 508 or they can be provided by the CPU 501 via the bus 505. Data can be stored locally with any of the crypto cores 508 to 511. A further option is to store data temporarily in the RAM 502 or the NVM 503. The lattice-based crypto core 508 can further use other crypto modules to provide support functions (e.g. expansion of pseudo-random data). The lattice-based crypto core 508 can further comprise a hardware random number generator or means for generating physical and / or software random numbers.

[0275] The processing device 500 can be a chip card powered 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. field programmable gate array, FPGA). The processing device 500 can be coupled to a personal computer, a microcontroller, a FPGA or a smartphone.

[0276] Figure 5 Another example of a processing device 600 is shown. 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 with the hardware security module (HSM) 601, the RAM 609, the NVM 608 and the interface 610.

[0277] 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 exemplarily comprises an AES core 604 and a lattice-based crypto (LBC) core 605.

[0278] According to one embodiment, the HSM 601 and the application processor 607 can be tightly coupled and manufactured on the same physical chip. While the application processor can perform compute-intensive tasks (e.g., image recognition, communication, motor control), the HSM 601 delivers cryptographic services and secure key storage. The HSM 601 is only accessible by a limited interface and is considered independent from the rest of the system in a way that a security compromise of the application processor 607 has only 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 by using the controller 602, LBC 605 supported by the exemplary AES 604 and HRNG 606. It can perform the processes described herein (at least in part) controlled by the internal controller or as CMOS circuitry. Further, the application processor 607 can also perform the processes described herein (at least in part, e.g., in cooperation with the HSM 601).

[0279] The processing device 600 with the application processor 607 and the HSM 601 can be used as a central communication gateway or (electrical) motor control unit in a car or other motor vehicle.

[0280] In one or more examples, the functions described herein can be implemented at least partially in hardware, e.g., dedicated hardware components or processors. More generally, the technology can be implemented in hardware, processor, software, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media can include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer- readable media generally can correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product can include a computer-readable medium.

[0281] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, flash memory, or any other medium that can be used to store required program code in the form of instructions or data structures and that can be accessed by a computer. Additionally, any connection is properly referred to as a computer-readable medium, i.e., a computer-readable transmission medium. For example, coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of medium if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but instead refer to non-transient tangible storage media. The disks and discs used herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically reproduce data magnetically, while discs use lasers to reproduce data optically. The combination of the above media should also be included within the scope of computer-readable media.

[0282] 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 arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein can refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein can be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into combined codecs. Furthermore, the technology can be fully implemented in one or more circuit or logic elements.

[0283] The technologies disclosed herein can be implemented in various devices or apparatuses, including wireless handheld devices, integrated circuits (ICs), or a set of ICs (e.g., chipsets). Various components, modules, or units are described in this disclosure to emphasize functional aspects of a device configured to perform the disclosed technologies; however, these various components, modules, or units do not necessarily need to be implemented by different hardware units. Specifically, as described above, the various units can be combined in a single hardware unit or provided through a collection of interoperable hardware units (including one or more processors as described above) combined with suitable software and / or firmware.

[0284] While various exemplary embodiments of the present invention have been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made to achieve some of the advantages of the invention without departing from the spirit and scope of the invention. It will also be apparent to those skilled in the art that other components performing the same function can be appropriately substituted. It should be mentioned that features illustrated with reference to specific drawings can be combined with features in other drawings, even if not explicitly stated otherwise. Furthermore, the method of the present invention can be implemented using appropriate processor instructions in all software implementations, or in a hybrid implementation utilizing a combination of hardware and software logic to achieve the same result. Such modifications to the concept of the invention are intended to be covered by the appended claims.

[0285] List of references:

[0286] [NewHopeNist17]NewHope–Submission to the NIST post-quantum project.Erdem Alkim,Roberto Avanzi,Joppe Bos,Léo Ducas,Antonio de la Piedra,Thomas Peter Schwabe,Douglas Stebila.See https: / / csrc.nist.gov / Projects / Post-Quantum-Cryptography / Round-1-Submissio ns

[0287] [NewHopeSimplePaperEprint16]Erdem Alkim,Léo Ducas,Thomas Peter Schwabe:NewHope without reconciliation.IACRCryptologyePrint Archive 2016:1157(2016).

[0288] [NewHopePaperEprint16]Erdem Alkim,Léo Ducas,Thomas PeterSchwabe:Post-quantum key exchange-a new hope.IACR CryptologyePrint Archive2015:1092(2015)

[0289] [OSPG18]T.Oder,T.Schneider,T. and T.Güneysu:PracticalCCA2-Secure and Masked Ring-LWE Implementation,IACR Eprint,23Jan2018(accessed 15 June 2018),https: / / eprint.iacr.org / 2016 / 1109.pdf

[0290] [LPR10A]Vadim Lyubashevsky,Chris Peikert,Oded Regev.:On IdealLatticesand Learning with Errors Over Rings,Journal of the ACM,60(6):43:1–43:35.Preliminary version in Eurocrypt 2010.https: / / web.eecs.umich.edu / ~cpeikert / pubs / ideal-lwe.pdf

[0291] [LPR10B]Vadim Lyubashevsky,Chris Peikert,Oded Regev.:On IdealLatticesand Learning with Errors Over Rings,Slides presented at Eurocrypt2010,https: / / web.eecs.umich.edu / ~cpeikert / pubs / slides-ideal-lwe.pdf

Claims

1. A method for compiling cryptographic information, comprising: (a) Determine a first portion of the cryptographic information based on input and randomness; (b) Check whether the rejection criteria are met based on the first part of the cryptographic information; (c) If the rejection criterion is met with respect to the first part of the cryptographic information, restart step (a) using new randomness; (d) For each of the at least one subsequent portion of the cryptographic information that has not yet been determined. (d1) Based on the input and the randomness of the first part of the password information not satisfying the rejection criterion, determine the subsequent parts of the password information. (d2) Based on the subsequent portion of the password information, check whether the rejection criteria are met, and (d3) If the corresponding subsequent portion of the cryptographic information satisfies the rejection criterion, restart step (a) using new randomness; and (e) Transmit the determined first portion of the cryptographic information and each determined subsequent portion.

2. The method of claim 1, further comprising determining all subsequent portions before performing the transmission, and storing the determined first portions and the determined subsequent portions until all subsequent portions have been determined.

3. The method according to claim 1, further comprising, in the case of processing the loop determined by steps (a) to (d), storing only a portion of the password information at a time.

4. The method of claim 1, further comprising, after determining that the rejection criterion is not met for the first portion and all subsequent portions: Based on the input and the randomness of the previously determined rejection criterion for any part of the password information, the first part and one or more subsequent parts of the password information are regenerated to obtain the determined first part and one or more subsequent parts for transmission.

5. The method according to claim 4, further comprising: For each part of the cryptographic information determined by the loop through steps (a) to (d), a first hash value associated with the corresponding part of the cryptographic information is generated and stored; In the step of regenerating the first part and the one or more subsequent parts of the password information, a second hash value is generated for each part of the password information, and the first hash value associated with the same part of the password information is compared with the second hash value; as well as The corresponding part is transmitted only if the first hash value corresponds to the second hash value.

6. The method according to claim 5, wherein, If the first hash value does not correspond to the second hash value, the method further includes triggering at least one of the following actions: Issue a notification or alert; Stop the method; Enter exception handling; and Restart step (a) using different levels of randomness.

7. The method according to claim 1, wherein, The cryptographic information is at least one of the following or includes at least one of the following: a signature; pairing information; information associated with zero-knowledge proofs.

8. The method according to claim 1, wherein, Prior to step (e), the corresponding portion of the cryptographic information has been encrypted with a secret key; and the method further includes transmitting the secret key.

9. The method according to claim 8, wherein, The secret key is transmitted after the final encrypted portion of the password information has been transmitted.

10. The method according to claim 1, wherein, The input is a message.

11. The method according to claim 1, wherein, The cryptographic information is compiled based on the portion of the cryptographic information that has been transmitted.

12. The method according to claim 10 further includes authentication based on the cryptographic information.

13. The method according to claim 1, wherein, Processing the cryptographic information or a portion thereof utilizes at least one cryptographic lattice operation.

14. The method according to claim 1, wherein, The method is used on or used to operate a safety device, wherein such a safety device includes at least one of the following: integrated circuit, Hardware security module, Trusted Platform Module cryptographic unit, FPGA Processing unit Controller, and Smart card.

15. A security device for compiling cryptographic information, the security device comprising digital hardware and interface circuitry, the digital hardware and interface circuitry being configured to: (a) Determine a first portion of the cryptographic information based on input and randomness; (b) Check whether the rejection criteria are met based on the first part of the cryptographic information; (c) If the first part of the cryptographic information satisfies the rejection criterion, restart step (a) using new randomness; (d) For each of the at least one subsequent portion of the cryptographic information that has not yet been determined. (d1) Based on the input and the randomness of the first part of the password information not satisfying the rejection criterion, determine the subsequent part of the password information. (d2) Based on the subsequent portion of the password information, check whether the rejection criteria are met, and (d3) If the corresponding subsequent portion of the cryptographic information satisfies the rejection criterion, restart step (a) using new randomness; and (e) Transmit the determined first portion and each determined subsequent portion of the cryptographic information.

16. A consumable comprising the safety device according to claim 15.

17. An authentication system comprising the security device and host according to claim 15, wherein, The security device is configured to transmit the password information to the host in a corresponding part.

18. The authentication system according to claim 17, wherein, The host is configured to authenticate the security device based on portions of the received cryptographic information.

19. A non-transitory computer-readable medium having a computer program product stored thereon, the computer program product being directly loadable into the memory of a digital processing device, the computer program product performing the method according to any one of claims 1 to 14 when executed by a processor.

Citation Information

Patent Citations

  • Signature and verification method, signature generation device, and signature verification device

    US20110016325A1

  • Hash-based signature balancing

    US20180091309A1