A public / private key system with enhanced security

Abstract

Some embodiments involve a second cryptographic device (20) and a first cryptographic device (10). The first and second cryptographic devices can be configured to transmit a key seed. The key seed can be protected using a public key from one party and a private key from the other party. For example, the public key can be obtained from the private key by multiplying noise. At least one of the first and second cryptographic devices can verify the obtained public key, for example, to prevent the disclosure of the key seed or the private key.

Description

Technical Field

[0001] This invention relates to a second cryptographic device, a first cryptographic device, a public key encryption method, a private key encryption method, and a computer-readable medium. Background Technology

[0002] One way to solve the problem of key distribution is to use so-called asymmetric cryptography. In asymmetric cryptography, key pairs are used, which consist of a public key and a private key. For this reason, asymmetric cryptography is also called public-key cryptography.

[0003] Public keys may be widely distributed, but private keys are typically known only to a few parties, such as their owner. Public keys can be used to encrypt messages that can only be decrypted using the private key. In a public-key cryptography system, anyone can encrypt a message using the recipient's public key. The encrypted message can only be decrypted using the recipient's private key. Finding the private key from its corresponding public key is computationally impractical. The public and private keys are called a key pair.

[0004] Known public-key cryptosystems rely on cryptographic algorithms based on mathematical problems for which there is currently no efficient solution. For example, the RSA public-key cryptosystem relies on the difficulty of integer factorization. Elliptic curve cryptography relies on the difficulty of discrete logarithms.

[0005] Quantum computers pose a significant threat to modern cryptography. The two most widely used public-key cryptosystems, RSA and elliptic curve cryptography (ECC), will be broken by universal quantum computers. Lattice-based cryptography can be used as an alternative to quantum computer resistance. Many lattice-based cryptosystems have been proposed.

[0006] For example, one such lattice-based system is called Round5. Round5 is the second round of submissions to quantum cryptography after NIST. A description of Round5 can be found on the NIST page: https: / / csrc.nist.gov / projects / post-quantum-cryptography / round-2-submissionsThe descriptive document is titled "Round 5: KEM and PKE based on (Ring) Learning with Rounding," dated Thursday, March 28, 2019. The description of Round 5 can also be found in the Cryptology ePrint archive: Report 2018 / 725, e.g., Version: 20190126:102712. These documents are included in this document by reference. The former will be referred to as "Round 5." Other grid-based cryptography documents include FrodoKEM, "Frodo-KEM: Learning With Errors Key Encapsulation", dated March 30, 2019; NTRU, "NTRU", dated March 30, 2019; SABER, "SABER: Mod-LWR based KEM (Round 2 submission)"; NewHope, version 1.02, dated March 15, 2019; and Crystals-Kyber, "CRYSTALS-Kyber (version 2.0)", dated March 30, 2019, whose descriptions can be found on the NIST page mentioned above as second-round NIST candidates. Descriptions of these are also included in this article from the NIST second-round candidate proposals.

[0007] For example, a second cryptographic device can be configured to derive the original key using the public key of the first cryptographic device. The original key can be used to encapsulate a key seed or pre-key, which can then be used to protect communication between the first and second cryptographic devices. A grid-based system can be configured such that the two devices can derive the same original key, or at least original keys so close that they can still be used to encapsulate and recover the same key seed. Summary of the Invention

[0008] The inventors discovered that these grid-based systems suffer from weak key problems. For example, if the first public key obtained at the second cryptographic device is weak, then the key seed is not adequately protected for confidentiality. Therefore, all communications protected using that key seed are potentially compromised. For instance, sensitive communications of the second cryptographic device, intended for use with the first, could be read by an eavesdropper. Furthermore, the first public key may become weak due to accidental events (e.g., programming errors, transmission problems, or malicious intent, such as establishing plausible denial or creating problems for the second cryptographic device).

[0009] A similar problem can occur on one side of the first cryptographic device. The first cryptographic device uses the second public key of the second cryptographic device to recover the encapsulated key seed. A malicious choice of the second public key could allow some information about the first private key of the first cryptographic device to be leaked. This might go unnoticed because the second public key can be ephemeral, thus many different second public keys are expected. Therefore, it's possible that many second public keys are attempting to leak portions of the first private key without being noticed. For example, an attacker might notice whether the first cryptographic device is able to derive the shared key, or whether the shared key has changed from a previous shared key.

[0010] These and other problems are addressed by the embodiments described herein. A second cryptographic device and a first cryptographic device are provided. Using the second cryptographic device, a key seed can be transmitted to the first cryptographic device. The key seed can be used to encrypt messages. Therefore, access to the public key allows for the encryption of messages, but decryption of the encrypted messages requires access to the private key.

[0011] For example, a second cryptographic device can obtain a first public key associated with a first cryptographic device, generate a second private key, and calculate a second public key based on the second private key. Calculating the public key from the private key might involve multiplying the private key by noise with a shared object.

[0012] The first public key can be used to compute a second original shared key, which can then be used to encapsulate the key seed. Because the first cryptographic device can obtain the same or nearly identical original key, it can decapsulate the data and thus obtain the key seed. However, if the first public key is weak, the encapsulation is insufficient to mask the key seed, making it unsuitable for subsequent cryptographic use. For example, computing the original key could include a noise multiplication between the first public key and the second private key; if the first public key is less than this value, it is the original key.

[0013] For example, a first cryptographic device can receive a second public key and encapsulated data from a second cryptographic device, calculate a first original shared key from the second public key and a first private key, and use it to decapsulate the encapsulated data using at least a portion of the first original shared key. A malicious second cryptographic device might send a specially crafted second public key instead of the real public key, for example, a second public key already obtained from a randomly generated second private key. The second device might do this in the hope that this will reveal information about the first private key. For example, an attacker might use a key mismatch attack. In a key mismatch attack, by comparing whether the shared keys between two participants match, the private key can be recovered for a participant who is reusing their public key.

[0014] Therefore, both the first and second cryptographic devices are interested in avoiding the use of a public key obtained for the other party that does not correspond to a profile that one might expect from a public key. In the case of the second cryptographic device, allowing a weak first public key may result in lower confidentiality protection for the key seed and any communication dependent on it. In the case of the first cryptographic device, allowing a weak second public key may result in the unintentional disclosure of parts of the first private key, for example, by detecting the presence or absence of a key mismatch. Typically, the second cryptographic device will use a short-lived second private key and a second public key, making the issue of revealing information about the second private key less urgent. However, if it is desirable to avoid disclosing information about the second private key, for example because the key may have longer-term use, then verification of the first public key can be performed.

[0015] In an embodiment, the second cryptographic device and / or the first cryptographic device are configured to apply an authentication process to the obtained public key. It may be possible, but is not required, that both parties perform authentication on the obtained public key, as this depends on which threat has been addressed.

[0016] In the case of a second cryptographic device, it can be determined whether the public key is secure for encapsulating the key seed. If the obtained public key is unsuitable, for example because using it for encapsulation would reveal too much of the key seed, then the second cryptographic device can take appropriate action. For example, the verification process can be performed before or during encapsulation, and if the verification process fails, encapsulation can be skipped or aborted. For example, the verification process can be performed after or during encapsulation, and the encapsulation result can be discarded; for example, if the verification process fails, it is not transmitted to the first cryptographic party.

[0017] In the case of the first cryptographic device, it can be determined whether the public key is secure for decapsulating the key seed. If the obtained public key is unsuitable, for example because using it for decapsulation would reveal too much of the first private key, then the first cryptographic device can take appropriate action. For example, the verification process can be performed before or during decapsulation, and if the verification process fails, decapsulation can be skipped or aborted. For example, the verification process can be performed after or during decapsulation, and the decapsulation result can be discarded; for example, the obtained key seed can be discarded, a warning can be issued, or the second cryptographic device can be blocked, etc.

[0018] If key leakage is the goal, the bar for rejecting keys might be set relatively high, but information about devices using suspicious keys could be maintained, for example, around keys near the rejection bar. For instance, a first cryptographic device could calculate how often a particular second cryptographic device uses a suspicious key, e.g., for that key, a statistic falling outside the likely range but not outside the highly unlikely range. If an unlikely key is used frequently, such as two or more times, four or more times, etc., additional keys from that second cryptographic device might be rejected.

[0019] The weak key problem is common in many lattice-based cryptographic schemes, especially in those based on so-called noise multiplication.

[0020] For example, the shared object, the first public key, the first private key, the second public key, and the second private key can be matrices over a finite field or a ring. Noise multiplication can be matrix multiplication, for example, over a finite field or a ring. Matrix elements can be integers, such as modulo operations, or modulo polynomials and reduced polynomials. The noise multiplication may add noise to the result, for example, by scaling down the resulting matrix elements, or by generating noise and adding the noise to the resulting matrix elements.

[0021] For example, the shared object, the first public key, the first private key, the second public key, and the second private key can be polynomials over a finite field or ring. Noise multiplication can be polynomial multiplication, for example, taking the modulus of a reduced polynomial. The noise multiplication may add noise to the result, for example, by scaling down the coefficients of the resulting polynomial, or by generating noise and adding the noise to the coefficients of the resulting polynomial.

[0022] Scaling factors or elements can include multiplication with scaling factors, addition of scaling factors, and base, rounding, or ceiling operations.

[0023] In an embodiment, the key seed is random, and / or transient, and / or symmetric, and / or independent of the first public key.

[0024] In normal use, the generation of the public key is part of a random process. While various constraints can be imposed on the private key, it is generally chosen randomly, depending on the specific lattice-based cryptographic scheme, for example, randomly chosen due to design constraints. For instance, the private key can be randomly chosen to undergo balancing, have a finite (absolute) range of its value (e.g., ternary values), and / or constraints on its weights, etc. The public key can be obtained as a noise multiplication between the public key and the shared object.

[0025] Therefore, a public key that does not statistically appear to be the result of such a random process may be an erroneous result, such as a programming error, a transmission error, or it may be the result of an attack. The first and second devices can be configured to pre-check whether the public keys they generate will pass the test performed by the other device. However, in practice, this is unlikely to vary much, as the actually generated public key will pass the test with a very high probability.

[0026] The verification process can calculate a statistical metric for the public key, and reject the public key if the statistical metric is outside the expected range of the statistical metric.

[0027] A specific problem arises if the public key is much smaller than expected. For example, the verification process might include determining whether the magnitude of the obtained public key is below a threshold. For instance, one could mathematically calculate the expected range of the magnitude, such as the range in which the public key is expected to exist with a certain high probability. For example, this probability could be set to 1-10. -6 It can be higher or lower, depending on the application.

[0028] On the other hand, if the resulting raw key is used for encapsulation, the expected amount of information can be calculated. The latter approach may be preferred, but it can be more difficult to implement. However, a similar effect can be achieved by rejecting unusually small keys.

[0029] For example, the verification process may include determining whether the number of values ​​is below a first threshold in the obtained public key, and rejecting the key if the determined number is less than a second threshold. "Below the threshold" can be interpreted in absolute terms. If the public key has a value modulo p, the verification process may require that the number of elements directly below p is small; or even that the number of elements in [0, t1) ∪ [p - t2) is small, for example, below threshold t3.

[0030] Specifically, the verification process may include determining whether the obtained public key is all zeros or nearly all zeros. For example, whether the number of non-zero elements is below a threshold. A public key with many zeros may result in low confidentiality of the encapsulated key seed.

[0031] In some cryptographic schemes, the public key can be obtained in the transform domain, such as the frequency domain. For example, the transform could be a Fourier transform, such as the Discrete Fourier Transform (DFT). In this case, the verification could include determining whether the norm of the public key in the transform domain is below a threshold. This test gives an indication that the sum of squares of the entries in the original domain is small. Alternatively or additionally, one can compute a linear combination of the elements in the transform domain and verify that it is below a threshold. This test gives an indication that the sum of the entries in the original domain is small. For example, this could be used with NTT, for example, CRYSTALS-Kyber and NewHope. The linear combination of elements can be randomly selected, for example, to prevent an attacker from preparing for the test.

[0032] The verification process may include determining whether the number of public key values ​​that are equal to each other exceeds a threshold. A large number of equal values ​​may indicate a weak key. This can be particularly problematic in cryptographic schemes where the private key is balanced, for example, with a fixed weight. This problem may occur, for example, if a ternary secret key is used. For instance, in a balanced private key with a fixed-weight secret, such as the same numbers 1 and -1, the aforementioned type of key may approach zero.

[0033] In this embodiment, the verification process is performed on the public key rather than directly on the original key. This has the advantage that the test cannot reveal information about the private key because the private key does not need to participate in the check. Alternatively, one could verify whether the original key is small, but this could reveal information about the private key if the accept / reject decision is visible. In particular, this is undesirable if the private key is a long-term key. In this embodiment, the verification process for the second cryptographic device includes determining the magnitude, number of small values, etc., of the original key.

[0034] It is possible to perform a more sophisticated evaluation of the public key using more complex statistical measures. For example, the verification process may include: calculating a histogram of the values ​​in the obtained public key, and comparing the calculated histogram with an expected histogram. The expected histogram can be mathematically calculated, but it can also be empirically established.

[0035] More rigorous statistical tests, not associated with specific weaknesses (such as smallness or having many small values), have the advantage that they may also help combat future weaknesses. For example, if in the future it is discovered that a particularly clever choice of the public key, such as choosing or not choosing the private key in the first place, could lead to problems, such as weak encapsulation or potentially revealing information about the private key.

[0036] For example, the verification process may include:

[0037] - Determine whether the bins of the calculated histogram are less than a threshold, and / or

[0038] - Determine whether the bins of the calculated histogram are greater than a threshold, and / or

[0039] - Calculate the distance between the calculated histogram and the expected histogram and determine whether the distance is higher than a threshold.

[0040] Before calculating the histogram, the values ​​in the public key can be shifted up or down, for example, by half a bin size. This has the effect that values ​​with absolute values ​​close to 0 are included in the same bins of the histogram.

[0041] There are various distance measures between the histogram determined in the obtained public key and the expected histogram, such as those established mathematically or empirically. For example, a distance measure could be the squared distance, such as the sum of squares of the differences in the sizes of the corresponding bins. Other measures that can be used include the chi-square test and the KS test.

[0042] The second and first cryptographic devices can be electronic devices. For example, they can be computers or servers. They can be mobile electronic devices, such as mobile phones or smart cards. The second and first cryptographic devices can also be consumer electronic devices, such as set-top boxes or televisions. The public-key encryption device can be a sensor.

[0043] The apparatus and method according to the embodiments can be widely used in practical applications. Such practical applications include many cryptographic protocols. These applications include messaging applications, sensor networks, data communications, financial applications, and so on.

[0044] Embodiments of this method can be implemented on a computer as a computer-implemented method, or in dedicated hardware, or a combination of both. Executable code for embodiments of the method can be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transient program code stored on a computer-readable medium for executing embodiments of the method when the program product is executed on a computer.

[0045] In an embodiment, the computer program includes computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer-readable medium.

[0046] Another aspect of the invention provides a method for making a computer program available for download. This aspect is used when a computer program is uploaded to, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store and is available for download from such stores. Attached Figure Description

[0047] Further details, aspects, and embodiments of the invention will be described by way of example only with reference to the accompanying drawings. Elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. In the drawings,

[0048] Figure 1a An example of an embodiment of the first cryptographic device 100 is illustrated schematically;

[0049] Figure 1b An example of an embodiment of the second cryptographic device 200 is illustrated schematically;

[0050] Figure 1c An example of an embodiment of the cryptographic system 101 is illustrated schematically;

[0051] Figure 2a An example of public-key encryption and private-key decryption is illustrated schematically;

[0052] Figure 2b An example of public-key encryption and private-key decryption is illustrated schematically;

[0053] Figure 3 An example of public-key encryption and private-key decryption is illustrated schematically;

[0054] Figure 4 An example of public-key encryption and private-key decryption is illustrated schematically;

[0055] Figure 5 An example of a cryptographic system according to an embodiment is illustrated schematically;

[0056] Figure 6a An example of a public-key encryption method according to an embodiment is illustrated schematically;

[0057] Figure 6b An example of a private key decryption method according to an embodiment is illustrated schematically;

[0058] Figure 7a A computer-readable medium having a writable portion including a computer program, according to an embodiment, is schematically illustrated; and

[0059] Figure 7b A representation of a processor system according to an embodiment is shown schematically.

[0060] List of reference numerals in the attached figures 1a-5, 7a-7b:

[0061] 10 First Cryptographic Device

[0062] 20 Second cryptographic device

[0063] 31. Registration Phase

[0064] 32. Encryption Phase

[0065] 33 Decryption Phase

[0066] Messages on November 11th and 12th

[0067] 100 First Cryptographic Device

[0068] 130 Communication Interface

[0069] 191 Computer Networks

[0070] 192 storage interfaces

[0071] 194 processor

[0072] 196 Memory

[0073] 200 Second cryptographic device

[0074] 230 Communication Interface

[0075] 292 Storage Interfaces

[0076] 294 processor

[0077] 296 Memory

[0078] 300 First Cryptographic Device

[0079] 301 cryptosystem

[0080] 302 Public Key Repository

[0081] 305 Communication Interface

[0082] 315 Public / Private Key Generator

[0083] 320 Error Corrector

[0084] 325 Diffie-Hellman unit

[0085] 335 Reconciliation Unit

[0086] 340 Decapsulation Unit

[0087] 350 Second cryptographic device

[0088] 355 communication interface

[0089] 360 public key holder

[0090] 365 Public / Private Key Generator

[0091] 370 codeword generator

[0092] 375 Diffie-Hellman unit

[0093] 380 Reliable Bit Generator

[0094] 385 Reconciliation Data Generator

[0095] 390 package unit

[0096] 1000 computer-readable media

[0097] 1010 writable portion

[0098] 1020 Computer Program

[0099] 1110 (one or more) integrated circuits

[0100] 1120 Processing Unit

[0101] 1122 Memory

[0102] 1124 Application-Specific Integrated Circuit

[0103] 1126 Communication Components

[0104] 1130 Interconnection

[0105] 1140 Processor System Detailed Implementation

[0106] Although the invention may have many different embodiments, one or more specific embodiments are shown in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is intended to be an example of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0107] In the following description, for ease of understanding, the elements of the embodiments are described in operation. However, it will be apparent that the various elements are arranged to perform the functions performed by them.

[0108] Furthermore, the invention is not limited to these embodiments, and the invention lies in each novel feature or combination of features described herein or recited in mutually different dependent claims.

[0109] Some embodiments involve a second cryptographic device and a first cryptographic device. The first and second cryptographic devices can be configured to transmit a key seed. The key seed can be protected using a public key from one party and a private key from the other party. For example, the public key can be obtained from the private key by multiplying noise. At least one of the first and second cryptographic devices can verify the obtained public key, for example, to prevent the disclosure of the key seed or the private key.

[0110] Figure 1a An example of an embodiment of the first cryptographic device 100 is illustrated schematically. Figure 1b An example embodiment of the second cryptographic device 200 is illustrated schematically. The first cryptographic device may also be referred to as a first device or a first cryptographic device. The second cryptographic device may also be referred to as a second device or a second cryptographic device. Figure 1c An example embodiment of a cryptographic system 101 including a first cryptographic device 100 and a second cryptographic device 200 is illustrated schematically. The first cryptographic device 100 and the second cryptographic device 200 may each include one or more of storage interfaces 192, 292, processors 194, 294, and memories 196, 296. The first cryptographic device 100 is configured to generate public / private key pairs. The public and private keys may each include a public key matrix and a private key matrix. The public and private keys may each include a public key polynomial and a private key polynomial. The second cryptographic device 200 is configured to use the public key and use it to enable a key seed to be transmitted to the first cryptographic device. For example, the key seed may be used directly as the key, typically as a symmetric key, to encrypt and later decrypt messages to be transmitted from the second cryptographic device to the first cryptographic device.

[0111] The first cryptographic device can be configured to use its private key to obtain the same key seed. For example, the key seed can also be used to derive a communication key from it. For example, the key seed can be hashed, possibly along with other information, to obtain the communication key. For example, other information may include initial and / or response protocol messages exchanged between the first and second cryptographic devices.

[0112] A key seed can be used as input for further key negotiation. For example, a key seed can be combined with one or more additional key inputs to derive, for instance, a final key. This can be achieved using a key derivation function that obtains the key seed and additional key inputs. Additional key inputs may include additional key seeds derived from protocols in which the second cryptographic device and the first cryptographic device are repositioned, thus playing opposite roles in the various protocols described herein.

[0113] The first cryptographic device 100 and the second cryptographic device 200 (e.g., various devices of system 101) can communicate with each other via computer network 191. The computer network can be the Internet, an intranet, a LAN, a WLAN, etc. Computer network 191 can be the Internet. The computer network can be wholly or partially wired and / or wholly or partially wireless. For example, the computer network can include an Ethernet connection. For example, the computer network can include wireless connections, such as Wi-Fi, ZigBee, etc. These devices include connection interfaces arranged to communicate with other devices of system 101 as needed. For example, the connection interface can include connectors, such as wired connectors (e.g., Ethernet connectors) or wireless connectors (e.g., antennas, such as Wi-Fi, 4G, or 5G antennas). For example, the first cryptographic device 100 and the second cryptographic device 200 can each include communication interfaces 130 and 230, respectively. Computer network 191 can include additional components, such as routers, hubs, etc.

[0114] Execution of the first cryptographic device 100 and the second cryptographic device 200 can be implemented in a processor (e.g., processor circuitry), examples of which are shown herein. The first cryptographic device 100 (and in particular the processor of the first cryptographic device 100) can implement the functions of the first cryptographic device 10, such as... Figures 2a-2b , Figure 3 and Figure 4 As shown. The second cryptographic device 200 (in particular, the processor of the second cryptographic device 200) can implement the functions of the second cryptographic device 20 in these figures. For example, these functions can be implemented, in whole or in part, as computer instructions stored at device 100 or 200, such as computer instructions stored in the electronic memory of the device, and can be executed by the microprocessor of the device. In a hybrid embodiment, the functional units are implemented in part as hardware (e.g., as a coprocessor, such as a cryptographic coprocessor) and in part as software stored and executed on device 100 or 200.

[0115] Devices 100 and 200 may include storage interfaces for storing and / or retrieving messages (potentially encrypted messages). For example, the storage interface may be implemented locally, such as as an interface to a memory included in the device (e.g., memory 196 or 296, respectively). The storage interface may also interface with offline (e.g., non-local) storage devices (e.g., cloud storage devices), such as with a storage device located in another device, such as a memory or drive. If a cloud storage device is used, the device may also include a local storage device, such as a memory. For example, the memory may be used to store computer programming instructions, temporary storage files, etc.

[0116] In various embodiments of devices 100 and 200, the communication interface can be selected from a variety of alternatives. For example, the interface could be a network interface leading to a local area network or wide area network (e.g., the Internet), a storage interface leading to an internal or external data storage device, an application programming interface (API), etc. In embodiments, a second cryptographic device and a first cryptographic device are implemented in the same device. This is helpful for both message encryption and decryption. For example, the communication interface could be a storage interface, in which case the device can be used to store messages in encrypted form and subsequently retrieve and decrypt them.

[0117] Devices 100 and 200 may have a user interface, which may include known elements such as one or more buttons, a keyboard, a display, a touch screen, etc. This user interface may be configured to accommodate user interactions such as initiating key agreement protocols, responding to key agreement protocols, sending messages encrypted with a public key, and decrypting messages with a public key.

[0118] Storage devices can be implemented as electronic memory (e.g., flash memory) or magnetic memory (e.g., hard disk). A storage device may include multiple discrete memories that together constitute the storage device. A storage device can also be temporary memory, such as RAM.

[0119] Typically, devices 100 and 200 each include a microprocessor that executes appropriate software stored at devices 100 and 200; for example, this software may have been downloaded and / or stored in a corresponding memory (e.g., volatile memory such as RAM or non-volatile memory such as flash memory). Alternatively, devices 100 and 200 may be implemented wholly or partially as programmable logic units, such as field-programmable gate arrays (FPGAs). Devices 100 and 200 may be implemented wholly or partially as so-called application-specific integrated circuits (ASICs), such as integrated circuits (ICs) customized for their specific applications. For example, this circuitry may be implemented in CMOS using hardware description languages ​​such as Verilog, VHDL, etc.

[0120] In embodiments, devices 100 and 200 may include one or more circuits to implement one or more or all of the functions of the respective devices. The circuits may implement the corresponding functions described herein. The circuits may be processor circuits and storage circuits, with the processor circuits executing instructions electronically represented in the storage circuits.

[0121] The processor circuitry can be implemented in a distributed manner, for example, as multiple sub-processor circuits. The storage device can be distributed across multiple distributed sub-storage devices. Part or all of the memory can be electronic memory, magnetic memory, etc. For example, the storage device can have volatile and non-volatile components. Parts of the storage device can be read-only. The circuitry can also be an FPGA, ASIC, etc.

[0122] Figure 2a An example of public-key encryption and private-key decryption is illustrated. The public-key encryption side is performed by the second cryptographic device 20. The private-key decryption side is performed by the first cryptographic device 10. Figure 2a-4 The protocol can be executed by the second cryptographic device 200 and / or the first cryptographic device 100, for example, as described above.

[0123] Figure 2a-4 The symbols in the text are as follows:

[0124] • 'a' represents a common object, such as a matrix, for example, a matrix with elements in integers or rings, fields, etc., or a polynomial, for example, a polynomial with coefficient rings or fields. Elements can be integers modulo a modulus (e.g., powers of 2). We will use "value" or "element" to refer to the coefficients of a polynomial or the elements of a matrix.

[0125] • Elements of a public object can be polynomials modulo a modulo a (e.g., powers of 2) and a polynomial. A matrix public object `a` is typically a square d×d matrix. A matrix modulo a modulo a is called a non-cyclic configuration. A matrix with polynomial entries modulo a modulo a is called a modular configuration.

[0126] ·s and r represent the private keys of the first and second cryptographic devices, respectively. Like public objects, private keys can be matrices. Private keys can also be polynomials.

[0127] ·b and u represent the public key matrices of the first and second cryptographic devices, which are illustrated as a product of a*r or a*s. Like public objects, public keys can be matrices. Public keys can also be polynomials.

[0128] The asterisk (*) operation denotes a one-way function of the fundamental problem. The asterisk (*) operation derives a new mathematical object (e.g., a new matrix) from two fundamental matrices, while introducing some noise, such as a new polynomial. Noise can be explicitly introduced, for example, by adding noisy elements, or implicitly, for example, by rounding.

[0129] Examples of the star operation can be found in (R)LWE or (R)LWR or their modular versions. For example, a*r can mean Round((A*r (mod q)), p, q), such as in LWR. This means the product of r and the square matrix A modulo q. Then, the result is rounded with integers p and q by performing p / q(A*r (mod q)), where p < q. The rounding operation can be an operator In the latter formula, the angled brackets refer to the modulo operation, in this case modulo b. The floor rounding operation, in this case floor-down rounding, but this can be replaced with ceiling or true rounding operations. The value h can be used, for example, to reduce the bias. For example, one can use h = a / 2b. Generally, we have b < a. In an embodiment, both a and b are powers of 2.

[0130] · c represents the encapsulation key seed K

[0131] · encapsulate(k, K) means encapsulating the key seed K with k. For example, if k exists in Z_q, then K can also be represented in Z_q. If k exists in Z_2, then this may be XOR. Encapsulation can be done element-wise, for example, interpreting k and K as matrices as follows:

[0132] c = k + K*(q / 2) (mod q).

[0133] For example, the encapsulation function can use the key k to mask the key seed K such that errors in k have a limited effect on m, such as a linear effect. For example, the bits in the key seed K can be mapped to Z_q, for example, by multiplying the elements in K by an element in Z_q; if q is even, then q / 2 is a good choice. Next, the elements of the key k, which may also be elements of Z_q, are added to the mapped elements of K. The encapsulation of K can be considered as encrypting K with the key k, but where small errors in the key k, for example, a small number of bit errors, still allow successful decryption of K from c. Note that in the above example encapsulation, not all k values need to be used. For example, if k is a matrix or polynomial, a subset of its values, or even parts of the values, such as multiple bits from multiple values, can be used.

[0134] · decapsulate(k, c) means using the key k, which returns a bit string, to decapsulate the ciphertext c.

[0135] References:

[0136] RLWE: "On Ideal Lattices and Learning with Errors Over Rings" by Vadim Lyubashevsky, Chris Peikert and Oded Regev,

[0137] RLWR: "PseudorandomFunctions and Lattices" by Abhishek Banerjee, Chris Peikert, and Alon Rosen,

[0138] LWE: "On Lattices, Learning with Errors, Random LinearCodes, and Cryptography" by Oded Regev, LWR: "Pseudorandom Functions and Lattices" by Abhishek Banerjee, Chris Peikert, and Alon Rosen,

[0139] Hila5: "HILA5: On Reliability, Reconciliation, and Error Correction for Ring-LWE Encryption" by Markku-Juhani O. Saarinen.

[0140] The asterisk operation can be a noisy matrix multiplication, for example, a regular matrix multiplication followed by noise, or a regular polynomial multiplication followed by noise. Adding noise can also be integrated with multiplication. Adding noise in the asterisk operation can be done in several ways. One example of adding noise is by adding explicit noise (e.g., by generating and adding a noise matrix or polynomial). The advantage of adding explicit noise is that the noise is under the complete control of the cryptographer and can be finely tuned to, for example, obtain precise control over the system's failure rate relative to the system's security. Furthermore, the advantage of adding explicit noise is that all matrices or polynomials can be on the same ring or field, thereby simplifying analysis.

[0141] Another example of adding noise is scaling down. For example, matrices a, r, and s can have elements modulo q (e.g., integers or polynomials modulo q); for example, by multiplying by p / q and rounding (e.g., rounding up or down or rounding to the nearest integer, etc.), the asterisk operation can round the result of a matrix operation from modulo q down to modulo p.

[0142] In this application, lowercase letters will be used for matrices or polynomials. It should be understood that matrix transposition may be necessary whenever required (e.g., as required by the dimension of the matrix and the requirement that the original keys on both sides should be approximately equal). Typically, there is more than one way to do this; for example, alternative working embodiments can be obtained by transposing all matrices in the embodiments. Using polynomials has the advantage that multiplication is commutative, making transposition operations unnecessary.

[0143] Below is an example where matrix objects are given in uppercase letters, and where the transpose is included. The secret key is defined as a matrix. and Note that such a secret key matrix actually contains... and Independent secret key vectors. The original key matrix is ​​equal to S. T A T R and In addition to errors introduced by noise multiplication, B most significant bits are extracted from each entry of the original key, making it possible to generate a length... The total original key. The original key is called "original" because there is a possibility that the original key derived at the second cryptographic device and the first cryptographic device are not exactly the same. An example using a matrix is ​​given below:

[0144] In registration phase 31:

[0145] The first cryptographic device selects a public matrix object A and a first private key matrix S.

[0146] For some error matrix E, the first cryptographic device calculates the first public key matrix B = AS + E.

[0147] The first cryptographic device sends: A, B.

[0148] In encryption phase 32:

[0149] The second cryptographic device selects the second private key matrix: R

[0150] The second cryptographic device calculates the second public key matrix: U = A T R+E'; for some error matrices E'

[0151] The second cryptographic device calculates the second original key B. T R, note B T R = S T A T R+E T R;

[0152] The second cryptographic device generates the key seed K and calculates the encapsulated key seed as follows: For example, the key seed can have {0, 1, ..., 2}. B Entries in -1}

[0153] The second cryptographic device sends: U, C.

[0154] In encryption phase 32, the second cryptographic device can apply a verification procedure to the received public key. This can be referred to as Validate(B) and can be implemented as part of encryption phase 32. Validate(B) can be performed before, after, or during encapsulation, but if the result of the validate(B) procedure is unsuccessful, for example, B is not validated, then the encapsulation result C is not transmitted to the first cryptographic device. An example of the verification procedure is given in this document. For example, Validate(B) can verify that B is not zero. If B is zero, then the result will be unsuccessful, for example, no validation.

[0155] In decryption phase 33:

[0156] The first cryptographic device calculates the first raw key S. T U, note S T U = S T A T R+S T E'.

[0157] The first cryptographic device calculates CS. T U is used to decapsulate and the result is rounded to the nearest integer. The key seed K can then be obtained from rounding, for example, by dividing by a multiple of 1 / 2.

[0158] In decryption phase 33, the first cryptographic device may apply a verification process to the received public key. This may refer to Validate(U) and can be implemented as part of decryption phase 33. Validate(U) may be performed before, after, or during encapsulation, but if the validate(U) process is unsuccessful, for example, U is not verified, then the encapsulation result C is not decapsulated, or the decapsulation result (e.g., K) is discarded.

[0159] In the example above, matrices A, B, S, U, and R can be on Z_p. Exponent 2 B The value B in the formula indicates the number of most significant bits taken from the original key to encapsulate K. In this example, the remaining less significant bits can be used for reconciliation data. For example, B = 4 bits can be used for encapsulation. The modulus can be chosen as p = 2. 12The key seed can be encoded as a matrix whose entries are in Z_2^B, for example, selected from {0, 1, ..., 2^B-1}. Matrices E and E' can be matrices whose entries are modulo p. For example, they can be selected from the following set:

[0160] {0,1,…,w-1}∪p-(w-1),p-(w-1)+1,…,p-1

[0161] The value of w is small. The size of w is chosen to balance system security and system failure rate. A low value of w will reduce the system failure rate.

[0162] Matrix C can be computed modulo p. For bandwidth efficiency, the second cryptographic device can compute and transmit it by dividing t by p. When recovering K, the private key decryption device calculates... In this scenario, the original key uses fewer bits for reconciliation data than the available bits. Typically, the lower significant bits have a smaller impact on the probability of failure.

[0163] Instead of using an error matrix, the example can be modified to scale down the asterisk operation to add noise, rather than adding explicit noise. Scale-down has the advantage of reducing bandwidth. Instead of using a matrix, the example can be modified to use a polynomial.

[0164] Return to Figure 2a The diagram illustrates registration phase 31, in which the first cryptographic device 10 generates its private and public key matrix and makes the public key available to the public key encryption device 20. For example, the public key can be sent to device 20. Alternatively, the public key can be stored in a public key database from which device 20 can retrieve it. For example, devices 10 and 20 can be different devices or the same device.

[0165] During registration phase 31, device 10 generates a first private key matrix(s) and calculates a first public key matrix(b) based on the first private key matrix(s). For example, device 10 can generate a public matrix(a) and calculate the first public key matrix(b) as a noise matrix multiplication between the first private key matrix(s) and the public matrix(a). The transmission of the first public key matrix(b) from the first cryptographic device to the second cryptographic device 20 is arranged. For example, the first public key matrix(b) can be sent from the first cryptographic device to device 20 in message 11.

[0166] The public matrix (a) is shared between the second cryptographic device and the first cryptographic device, and the first public key matrix (b) is associated with the public matrix (a). For example, the public matrix is ​​transmitted to device 20 in the same manner as the public key matrix (b). Typically, matrix a is pseudo-randomly generated based on a seed. This matrix can be shared by sending the seed.

[0167] Encryption phase 32 can be later than registration phase 31, or even much later. In encryption phase 32, device 20 generates a key seed (K), generates a second private key matrix (r), and computes a second public key matrix (u) based on the second private key matrix (r). For example, device 20 can obtain a public matrix (a) associated with a first public key matrix (b), and compute the second public key matrix (u) as a noise matrix multiplication between the second private key matrix and the public matrix (a). The public matrix can be obtained in the form of a seed from which the public matrix is ​​generated. In embodiments, the public matrix is ​​obtained from different sources. For example, both device 10 and device 20 can obtain the public matrix from a third party.

[0168] The key seed can be generated randomly.

[0169] Device 20 is configured to: calculate a second original shared key (k*) based on a second private key matrix (r) and a first public key matrix (b), wherein calculating the second original shared key includes matrix multiplication between the second private key matrix (r) and the first public key matrix (b); encapsulate a key seed (K) using at least a portion of the second original shared key by applying an encapsulation function to obtain encapsulated data (c); and transmit the second public key matrix (u) and the encapsulated data (c) to a first cryptographic device. For example, the second public key matrix (u) and the encapsulated data (c) can be sent to the first cryptographic device in message 12.

[0170] Note that this allows the key seed to be independent of the original key. This enhances the ability to resist active attacks.

[0171] After the first cryptographic device receives the second public key matrix (u) and the encapsulated data (c) from the second cryptographic device, the first cryptographic device can continue in the decryption phase 33 to calculate the first original shared key (k') based on the second public key matrix (u) and the first private key matrix (s). Calculating the first original shared key includes matrix multiplication between the second public key matrix (u) and the first private key matrix (s), and decapsulating the encapsulated data (c) using at least a portion of the first original shared key (k') to obtain the key seed.

[0172] Interestingly, in this embodiment, the second public key matrix (u) has fewer matrix elements than the first public key matrix (b). If all matrices were square and had the same dimensions, the second public key matrix (u) and the first public key matrix (b) would have the same number of elements, but this is unnecessary. This would then mean that the public keys would contribute equally to messages 11 and 12. However, the environments in which these messages are sent and the devices that send them can be quite different. By choosing a size smaller than the first public key matrix (b), the bandwidth requirement for message 12 is reduced, while the bandwidth requirement for message 11 increases.

[0173] In this embodiment, the public matrix a is a square matrix of dimension d×d. The first private key matrix s and the first public key matrix b have dimension d×d. The second private key matrix r and the second public key matrix u have dimensions. For example, people can use But this is not necessary. Interestingly, the security of a system is thought to depend more on the system dimension d and the product. Instead of depending on and The individual size of B. The latter indicates the length (in bits) that can be used to derive the original key. The former affects the size of the basic lattice and thus the difficulty of the underlying cryptographic problem. The probability of decryption failure in this scheme depends in part on the value of B. A higher value of B increases the failure rate and adversely affects the security of the PKE scheme against adaptive active attacks. Typically, B is fixed, for example, in the form of a normalized set of parameters.

[0174] Interestingly, it is not necessary to pre-determine the second dimension of the second public key matrix (u). It can be chosen independently of the selection made for the first private and public keys. In particular, it can be independent of dimensions. To select. In the embodiment, the second dimension. This can be configured at the second device 20. Many examples of matrix or polynomial dimensions are given in Round 5. For example, one can use: (See Round 5, Table 14, page 58)

[0175]

[0176] In the table above:

[0177] n: Indicates the order of the polynomials in the private and / or public matrices. A value of n = 1 indicates the use of an integer modulo the modulus. This value n can be referred to as the "ring dimension," for example, the order of the chosen polynomial ring.

[0178] d indicates the system dimension, for example, the number of columns and rows in the common matrix a.

[0179] μ indicates the number of elements in the original key matrix used to encapsulate the key seed. These elements can be predetermined (e.g., normalized), randomly selected, or intentionally chosen, such as as reliable elements. The shared secret key length is therefore μB; in the example above, this is 192 × 1 = 192.

[0180] In an embodiment, more sophisticated encapsulation functions (such as Algorithm 9) from Hayo Baan et al.'s "Round 2: KEM and PKE based on GLWR" can be used to further enhance active security. If so, the ciphertext may include a hash g, which can be computed by a second cryptographic device by hashing the public key of the private key decryption device. This hash can be used to ensure that the final shared secret includes contributions from both the first and second cryptographic devices. For example, the Fujisaki-Okamoto transform can be used. The hash can be, for example, the size of the shared secret, which is 256 bits in this example.

[0181] As noted above, a key seed can be used to encrypt message m. For example, a second cryptographic device can be configured to encrypt message (m) using the key seed and transmit the encrypted message to a first cryptographic device. The first cryptographic device can receive the encrypted message (e.g., along with a second public key matrix and the encapsulation date) from the second cryptographic device and decrypt the encrypted message using the key seed.

[0182] In this embodiment, the key seed is independent of the first public key matrix (b). For example, the key seed K can be generated without using the first public key matrix (b), for example, the key seed can be generated randomly and / or generated before the first public key matrix (b) is received at device 20.

[0183] Similarly, the key seed can be independent of the second private key matrix (r). The key seed can be computationally independent of the second private key matrix (r), the second public key matrix (u), and the encapsulated data (c). Computational independence means that, within the attacker's computational capabilities, knowledge of the second private key matrix does not provide information about the key seed.

[0184] The key seed K is typically used temporarily; for example, it can be short-lived, used only to encrypt a single message m, or a single session, protocol, handshake, etc. The key seed K can be a symmetric key, for example, used as a key in a block cipher.

[0185] For example, device 20 can be configured to remove the key seed and / or second private key matrix used to encrypt the message after encapsulating the key seed. For instance, the key seed and / or second private key matrix can be removed before sending the encapsulated data to device 10. Similarly, device 10 can remove the key seed after decrypting the message.

[0186] In this embodiment, the second private key matrix is ​​derived from a key seed. For example, the key seed can be randomly generated (it can be real or fake) and then used as input to a key derivation function (e.g., a hash function) to derive the seed; additional inputs may also be available, such as a message, the first public key matrix, etc. The seed is then used to generate the second private key matrix, for example, as a deterministic pseudo-random function dependent on the seed. Preferably, the key derivation function is chosen such that the key seed cannot be computed from the second private key matrix.

[0187] This has the following effects: After device 10 derives the key seed, device 10 can, for example, reconstruct the second private key matrix based on the key seed by applying the same key derivation function and calculating the second private key matrix according to that key derivation function. Next, device 10 can verify whether the second public key and / or the encapsulated data has been correctly calculated. The advantage of this is that proactive attacks are much more difficult to carry out. If device 10 detects an anomaly, such as a difference between the received data and the recalculated second public key and / or the recalculated encapsulated data, device 10 can take appropriate action, such as generating a warning signal, suspending the decryption of the second message, etc.

[0188] Deriving a second private key matrix from the key seed has the advantage of increasing security towards a CCA-secured system. This is advantageous, especially if the first public key matrix is ​​generated once and used for many messages.

[0189] In this embodiment, the processor of the second cryptographic device is configured to compute helper data to reduce the error rate of obtaining the key seed at the first cryptographic device. The essence of public-key encryption based on noise matrix multiplication is that there is a chance that reconstructing the key seed on the side of the private key decryption key may fail. The probability of failure can be reduced in various ways, one of which is to compute and send helper data that helps the private key decryption device reach the correct key seed.

[0190] For example, the first cryptographic device can be configured to receive helper data from the second cryptographic device and apply the helper data to reduce the error rate of obtaining the key seed at the first cryptographic device.

[0191] Several types of helper data exist that can be used. In the example given above, one method was used, known as reconciliation data. A portion of the second original key can be used to encapsulate the key seed, and a portion of that can be used as reconciliation data.

[0192] For example, in one embodiment, the second original key is a matrix, and encapsulating the key seed (K) may include: adding bits of the key seed to the most significant portion of at least a portion of the elements of the second original key matrix, and discarding zero or more least significant bits of at least a portion of the elements of the second original key matrix. In one embodiment, all bits not added to the key seed for encapsulation can be used as reconciliation data. However, to reduce bandwidth, one or more least significant bits may be discarded. Note that not all matrix elements of the original key matrix must be used. Unused elements can be discarded entirely. At device 10, decapsulating the encapsulated data may include: discarding zero or more least significant bits of at least a portion of the elements of the first original key matrix, subtracting at least a portion of the elements of the first original key matrix from the encapsulated data, and rounding the result of the subtraction. Interestingly, helper data can be easily integrated into the encapsulation key seed.

[0193] In this embodiment, the second cryptographic device is configured to perform one or more of the following operations:

[0194] a) Apply a reliable bit function to the second original shared key (k*) to select a portion of the second original shared key, obtaining a reliable index indicating the element of the second original shared key (the bits used for encapsulation are derived from the indicated element); and transmit the reliable index to the first cryptographic device, and / or

[0195] b) Generate reconciliation data (h) for at least a portion of the second original shared key, the reconciliation data including information that allows reducing the differences between the first and second original keys derived at the second cryptographic device and the first cryptographic device, and transmit the reconciliation data (h) to the first cryptographic device, and / or

[0196] c) Generate parity bits for the key seed. The key seed and parity bits form a codeword based on the error correction code. Encapsulating the key seed includes the encapsulation codeword.

[0197] Similarly, the first cryptographic device can be configured to perform one or more of the following operations:

[0198] a) Receive a reliable index from the second cryptographic device, thereby selecting a portion of the first original shared key indicated by the reliable index.

[0199] b) Receive reconciliation data (h) for at least a portion of the first original shared key (k'), the reconciliation data including information allowing reduction of the differences between the first and second original keys derived at the second cryptographic device and the first cryptographic device, apply a reconciliation function to at least a portion of the first original shared key and the reconciliation data, and

[0200] c) Decapsulate the encapsulated data (c) to obtain the near codeword, and apply error correction based on the error correction code.

[0201] Figure 2b An example of public-key encryption and private-key decryption is illustrated schematically. The public-key encryption side is performed by the second cryptographic device 20. The private-key decryption side is performed by the first cryptographic device 10. (Reference) Figure 2b The various elements of the protocol illustrated can be implemented using the algorithms and / or formulas shown in Round 5.

[0202] Registration phase 31 may include selection, such as the random selection of a seed σ from which public objects, such as matrices or polynomials, can be derived. Similarly, a first private key S can be generated, for example, randomly. For instance, the first private key S may have elements bound by absolute values, such as the value |x|≤s, e.g., s=1. Larger values ​​of s are also possible. The latter is referred to as a ternary secret. S can be generated under other conditions, such as specific weights or weight constraints, or balancing, etc. The public key B is computed from public objects A and S using a noisy multiplication. For example, a multiplication AS can be computed, which, if desired, can be modulo-decreasing over a decreasing polynomial and / or modulus. The multiplication result may then be noisyized, for example, by applying a scaling operator. Registration phase 31 may include Algorithm 1 from Round 5.

[0203] Encryption phase 32 may include verification B, as explained further below. For example, a second private key R can be generated using the same or a similar process as that used for the first private key S. The second public key can also be computed in a similar manner. However, if matrices are used, the transpose of the public matrix A can be used. The multiplication result may be noisy, for example, by applying a scaling operator.

[0204] The key seed m can be chosen, for example, randomly.

[0205] The original key can be calculated from the second private key R and the first public key B, for example, by multiplying with noise. Here, a transpose might need to be added, for example, to B. Adding noise can be done directly after multiplication, but it can also be integrated with the remainder of the encapsulation operation. The key seed m can be encapsulated using the original key.

[0206] For example, the multiplication can be reduced as needed by modulo operations on the polynomial or integer. Depending on the result, multiple bits can be used for encapsulation. For example, one or more or all values ​​can be selected, from which one or more bits can be used. The key seed m can be encapsulated using bits obtained from the original key.

[0207] Before adding the original key (or a portion thereof), an error correction algorithm, such as the xef_ computation algorithm, can be applied to the key seed m. One way to encapsulate it is by multiplying by a factor to scale the key seed or codeword; for example, this factor could be q / 2 or q / 4, etc. Finally, scaling operators can be applied. To add noise. Encryption phase 32 may include Round 5 algorithm 2. The second public key and the encapsulated value v are transmitted to the first cryptographic device.

[0208] A communication key, or another key, or a transmission key K, can be calculated from the key seed by applying a hash to the key seed. The hash can include additional information, such as a second public key, the encapsulated key seed, etc. The communication key K can be used for other communications, not included in the key seed. Figure 2b As shown, for example, it can be used as a symmetric key, such as in block ciphers, MAC operators, etc. Encryption phase 32 may include Algorithm 2 of Round 5, such as Algorithm 5 or 8.

[0209] Decryption phase 33 may include applying the verification process to the second public key U. A second original key is computed from the second public key U and the first private key S, for example, by multiplication, possibly followed by modular arithmetic operations on integers and / or polynomial modulo. Note that no noise is needed here. The second original key is used to decapsulate the key seed m. If S is a matrix, then transposition may be required. Note that the computed original key can be combined with round constants, for example, as S. T (U+h4J). If the key seed is encapsulated as codewords, an error correction algorithm, such as xef_decoding, can be applied. Decryption phase 33 may include algorithm 3 of Round 5. Finally, the communication key K can be obtained in the same manner as the second cryptographic device. For example, decryption phase 33 may include algorithm 6 or 9.

[0210] Many variations are related to Figure 2a and Figure 2b The algorithm shown is possible; it can include various additional steps, or some of the steps shown can be omitted. For example, the reliable bit is the bit that is more likely to be calculated equally on both sides. For example, some elements of the original key matrix can be determined to be reliable, while other unreliable elements can be discarded. For the selected matrix elements, reconciliation data can be obtained. Finally, parity bits can be calculated to calculate other errors. These three types of helper data are independent because each, each two, or all three types of helper data can be used to reduce the failure rate of private key decryption.

[0211] In this embodiment, reconciliation data and parity bits can be combined, but not the reliability bits. An advantage of this method is that it does not require sharing information about the size of the elements. Helper data can be included in the encapsulation data, but can also be transmitted independently from device 20 to device 10. The reconciliation data can be easily integrated with the encapsulation key seed, for example, as illustrated herein. Figure 3 The diagram illustrates an example of an embodiment in which parity bits and reconciliation data are combined but not reliable bits.

[0212] In embodiments of the second or first cryptographic device, the reliable bit is one or more most significant bits of the indicated element, and the reconciliation data for the indicated element is one or more bits of the indicated element following the reliable bit. One or more least significant bits of the indicated element may be discarded. The indicated elements (i.e., reliable elements) can be transmitted from the second cryptographic device to the first cryptographic device, for example, their positions in a matrix.

[0213] In an embodiment of the first cryptographic device, an element in the original key indicated by a reliable index is selected and replaced with a modified element consistent with the corresponding reconciliation data. For example, the modified element may minimize the Lee distance between the selected element and the modified element. The reliable bit may be obtained as one or more most significant bits of the modified element.

[0214] In this embodiment, modified elements are determined such that they match the corresponding reconciliation data to the point that they are not discarded by the second cryptographic device. The modified elements minimize the Lee distance between the selected elements and the modified elements.

[0215] The public-key encryption according to the embodiments can be used in various existing protocols. For example, the embodiments can be integrated with protocols such as TLS, IPSec, and VPN. For example:

[0216] TLS 1.3: The client sends a `client_hello` message. `client_hello` can include the public key. Instead of having a public key, `client_hello` can include a URL indicating where the public key can be downloaded. If the server doesn't already have the public key, for example, in a cache, then the server can proceed to download the public key and store it locally. Using the public key, the server can encrypt a symmetric key or key seed and send it to the client, making it usable as a master key for deriving symmetric keys for the record layer. In this example, the client acts as the first cryptographic device.

[0217] TLS 1.2: This is another approach in this example. The client can send a request, and the server sends a URL containing the server's public key. If the public key is not yet available, the client can download it. And once the client has the public key, it can proceed to the encryption key seed, for example, for use in the record layer. In this example, the client acts as a second cryptographic device.

[0218] Note that public keys can be pre-allocated. For example, in a browser, one or more public key matrices (e.g., multiple public key matrices) can be pre-allocated. For instance, a public key ID (e.g., a hash of the key) can be used to indicate the public key, allowing software (e.g., a browser) to verify whether the public key was obtained through pre-allocation. In the case of pre-allocation, bandwidth asymmetry is an advantage. For example, if the public key matrix is ​​large during pre-allocation, this is not a problem, but the message size is reduced during use. Furthermore, in, for example, a TLS-based VPN, public keys can be pre-configured on one or both of the communicating parties.

[0219] In an embodiment, device 10 may be configured to send a first greeting message listing cryptographic information such as SSL or TLS versions, or listing cryptographic information in order of client preference, supported cipher suites, etc. In response to the first greeting message, device 20 may send a second greeting message. The second greeting message may contain similar details. Device 20 may also send its digital certificate in the second greeting message. Device 10 may verify the certificate. The first and / or second greeting messages may include a public key or an indication of a public key. In the second greeting message and / or subsequent messages, one or more key seeds are agreed upon. The key seeds can be used to encrypt or authenticate subsequent communication between devices 10 and 20. If multiple key seeds are agreed upon, they can be combined into a single key, for example, by hashing them together or performing XOR-ed, etc.

[0220] Figure 3 An example of public-key encryption and private-key decryption is illustrated. Figure 3 The following symbols were used in the text.

[0221] Parity bits refer to the information used for error correction.

[0222] `obain_parity_bits(k)` means obtaining some parity bits for k. For example, parity bits can be generated based on error-correcting codes.

[0223] The error_correct(k, parity_bits) function means using parity_bits to correct potential errors in k or parity_bits, thereby obtaining a version of k that is more likely to be error-free.

[0224] according to Figure 3 The embodiments use different types of helper data. For example, according to an embodiment, device 20 calculates the parity bit of the key seed. For example, the parity bit, together with the key seed, can be a codeword based on an error-correcting code (e.g., a BCH code). For example, the codeword is encapsulated using the original key as described herein. If desired, the encapsulation can include reconciliation data. To decapsulate, device 10 first applies the reconciliation data to obtain a near codeword, for example, a codeword in which bit errors may exist. The near codeword can be corrected using an error-correcting algorithm associated with the error-correcting code. The use of error correction and reconciliation data increases the probability of decryption failure, thereby allowing for smaller parameters and improved performance through a smaller key size. The combination of parity bits and reconciliation data is a preferred combination, thereby allowing for a small size of the public key matrix.

[0225] In an embodiment of the protocol, the first public key contains A vector. The ciphertext includes a second public key u and encapsulated data c. The second public key matrix u can be a vector of dimension d, where the elements are in Z_p. To minimize the size of the ciphertext, we can use... This means that the original key will have at most [number of keys]. Elements. To optimize the size of the original shared secret, we will extract B bits from as many elements as possible, therefore using The encapsulated data c is encrypted with the key seed, and may have... There are elements that allow a key seed of length κ = μB to be encapsulated. B is the number of bits extracted from each vector entry. (No further information is needed.) For example, one that may have For example

[0226] The first public key matrix may include A vector of length d. This allows for the encapsulation of... Where κ is the key seed length, and there is a parity_bits_length bit used as a parity check bit.

[0227] Because additional parity bits need to be transmitted, the vector c will become longer than parity_bits_length × log2 t. However, due to these parity bits, the scheme handles decryption errors better, allowing for the selection of smaller values ​​for q and p. Since p is smaller, d can also be reduced, as we are able to maintain the same level of security. In summary, by adding error-correcting codes in this way, we can further reduce the size of the ciphertext, even at the cost of a longer public key. Choosing B=1 is effective, and using it, we then need...

[0228] Parity bits allow for the correction of bit errors. For example, the error-correcting code XEf can be used, which allows for 3-bit error correction. Xef is described in "Round 5: Compact and Fast Post-Quantum Public-Key Encryption" by Sauvik Bhattacharya et al. The advantage of using XEf is that decoding can be completed efficiently in constant time, thus avoiding timing attacks.

[0229] In this embodiment, the ciphertext size will be slightly larger than 1KB. This means that such a construction enables a non-circular configuration that does not require ciphertext fragmentation. It is important to reduce the ciphertext size to below approximately 1.5kb, as this avoids fragmentation in packet-based communication, where packets used, such as those on the Internet, are approximately 2kb.

[0230] Note that the amount of noise introduced by scaling is relatively high. In the example above, the 16 bits of the secret matrix elements are reduced to 8 bits of the common matrix elements; a reduction of 50%. Compared to the previous example where the parity bit was not given, reducing 14 bits to 12 bits is a reduction of approximately 15%. Similarly, the difference between the bit length of the secret bits and the bit length of the common bits has increased from 2 bits to 8 bits. The higher noise allows for higher efficiency in the lattice portion of the protocol, but at the cost of a higher failure rate. The parity bit is then used to reduce the latter.

[0231] In an embodiment, and For example, where κ ≥ 128. For example, the number of parity bits can be chosen such that they can correct at least 3 errors. In the embodiments, log2p / log2q ≤ 0.85, or ≤ 0.72, or ≤ 0.7, or ≤ 0.6, or even ≤ 0.5 as in the embodiments above, or even smaller. Note that since all elements of the original shared key are used, for example, Therefore, so-called reliable bits are not used. Such high noise can be combined with low... (especially with) or Combined with, etc.

[0232] Figure 4 An example of public-key encryption and private-key decryption is illustrated. Figure 4 The implementation includes three different error correction sources: security bits, reconciliation data, and parity bits.

[0233] exist Figure 4 middle:

[0234] •h represents helper data, which includes account balances.

[0235] The `get_reconciliation(k)` function returns the reconciliation value from `raw_key k`.

[0236] The function `reconciliate(k, h)` reconciles the raw key `k` given the reconciliation bit `h`.

[0237] The `safe_bits()` function returns two values: (i) the actual reliable value; and (ii) the position of the critical bit. Because the obtained value is far from the quantization boundary, the position of the critical bit can cause a lower probability of failure. The actual value returned by `safe_bits()` is later used, for example, in encapsulation. The positions are exchanged with the other party so that the other party knows which positions are needed.

[0238] Interestingly, these three information sources can be used to reduce the probability of failure when exchanging codewords and randomly generated keys from them. Furthermore, the ability to randomly generate codewords enhances active security. Note that a second private key matrix can be derived from the codewords to further improve active security. The codewords can include a key seed and parity bits. These sources include the use of reliable bits, reconciliation data extracted for the coefficients of the original key, and error-correcting redundancy information (e.g., parity bits) that is part of the codewords.

[0239] It should be emphasized that there is no need to combine different methods to reduce the probability of failure. For example, the use of the safety bit or the reliable bit is entirely optional.

[0240] For example, in an embodiment, devices 10 and 20 can agree on a raw key, such as a matrix key k* with n coefficients in Z_q. For example, elements in the raw key matrix can be mapped to portions of the key seed, such as being mapped to one or more bits. For example, half of the values ​​in Z_q can be mapped to 0, and half of them can be mapped to 1, for example, B = 1. The selection of reliable bits can be accomplished by selecting, for example, a number (e.g., mu) of coefficients furthest from the decoding boundary, thereby reducing the probability of errors.

[0241] Key reconciliation data can be information extracted by a second cryptographic device, for example, for the selected reliability coefficients (e.g., the selected mu coefficients) of the original key (e.g., a matrix key). The reconciliation information helps the first cryptographic device make the same decision: whether to map specific coefficients of the original key to which parts of the codeword. This operation is not limited to the selected reliability coefficients, meaning less work is required.

[0242] Error correction information can be parity bits. Parity bits can be extracted from the randomly generated binary key K, message m, or pre-key, giving the information encapsulated by the second device some redundancy. In this way, device 10 can correct errors even if they occurred previously. Therefore, if the key K to be transmitted is kappa bits long and there are (mu–kappa) parity bits, these parity bits help device 10 ensure that the kappa bits of key K are correct.

[0243] The problem with many quantum-resistant public-key cryptosystems is that they have a certain probability of failure. For example, a first and second cryptographic device initially agree on a noisy original key, and then reconcile the noisy original key, for example, by reconciling reconciliation data. A reliable bit function allows the second cryptographic device (e.g., the one that first derived the original key) to identify which bits of the original key the first cryptographic device is more likely to have derived in the same way and which bits of the original key are less likely to be the same.

[0244] A direct implementation of the reliable bit function defines two or more center points for the coefficients to be sampled to obtain the coefficient bits. (E.g., based on a threshold) Coefficients that are too far from the center point can be discarded, while the rest can be sampled to the value associated with the center point. For example, the number of center points can be a power of 2. For example, matrix elements can be taken from various different rings, etc.

[0245] Reliable bit sampling uses the assumption that the key does not require all the bits given by the ring dimension. Typically, the dimension y of the underlying matrix is ​​much larger than the required key length. For example, a second cryptographic device can choose the m indices in y that are most likely to agree. These security coefficients can be those closest to the center point of the range of coefficients mapped to zero or one bit (k=0 and k=1). For example, in a ring modulo q, if the coefficients are in the range... If the coefficient is within the range, then the coefficient can be mapped to 0; if the coefficient is within the range... If the value is within a certain range, the coefficient can be mapped to 1, and vice versa. If the coefficient is not within either of these ranges, it is not a reliable bit. The value b partially determines the reliability of the bit. For example, in this case, it could be chosen as q / 8; smaller values ​​for b provide higher reliability but fewer key bits. In this case, the center point could be q / 4 or 3q / 4, or their rounded results.

[0246] The second cryptographic device, applying the above procedure, obtains the reliable bits and their corresponding key bit indices. The reliable indexes can be passed to the first cryptographic device, but the reliable key bits cannot. The first cryptographic device can then obtain the key bits based on the bits at the index indicated by the second cryptographic device. Because these bits are more reliable, the error rate will be lower.

[0247] Other implementations of the reliable bit function can be found in article Hila 5, which is incorporated herein by reference. For example, the algorithm in Chapter 3 can be applied. The inventors have found that the reliable bit function can be applied to a variety of situations, such as (especially on matrices) cases with different underlying rings or objects.

[0248] In this embodiment, the two parties generate two original keys, for example, matrices that are approximately but not exactly equivalent. To achieve precise reconciliation, specific reconciliation data is sent. A scheme for doing so is described in patent application No. 16197277.3 filed with the European Patent Office on November 4, 2016 (titled “REACHING AGREEMENT ON A SECRET VALUE”); for example, in this embodiment, reconciliation can be performed using the method described on pages 7-10. Variations disclosed elsewhere in the cited patent application may also be employed.

[0249] In this application, we will use the following symbols for the following three functions:

[0250] 1. Rounding function For q, b h ,B∈Z,b h ≥1,B <log2 q-b h ,make

[0251] So,

[0252]

[0253] Intuitively, extract The B most significant bits, where the second component is a rounding factor to ensure unbiased rounding errors. B indicates the number of bits extracted from the symbol v, and b h Indicates the number of helper data bits. In an embodiment, q can be a power of 2.

[0254] 2. Cross-rounding function For q, b h ,B∈Z,b h >1,B <log2 q-b h ,make

[0255] So,

[0256]

[0257] Intuitively, Extract (B+b) of v hb in the most significant bits h The least significant bit.

[0258] 3. Reconciliation function rec(w,b):

[0259] For q, b h ,B∈Z,b h ≥1,B <log2 q-b h ,w∈Z q ,

[0260]

[0261] Among them, v is the element closest to w, such that The nearest element w can be obtained based on the Lee distance (e.g., min(|vw|, q-|vw|)).

[0262] These three functions can be applied element-wise to a matrix. In this paper, the reconciliation functions cited above are used as examples. As mentioned above, the reconciliation methods in the cited applications can also be used. Cross-rounding functions can be applied to obtain reconciliation data, and rounding functions can be applied to obtain reconciled data (e.g., reliable bits). When the reconciliation data is used later in the reconciliation function, the reconciled data will be restored. In other words: Assume that v and w are within a threshold distance of each other.

[0263] The weak public key B is considered a security vulnerability because, if not rejected by the second cryptographic key, the weak public key B (say, having a value of 0) could even allow a passive eavesdropper to read session traffic.

[0264] As explained above, many grid-based public-key encryption schemes, such as those considered in the NIST PQC standardization project, involve a key generation phase where the public key components are generally calculated as B = AS + E, where A is a public parameter and S and E are secret. A first cryptographic device sends (A, B) to a second cryptographic device, etc. Next, these schemes may require the second cryptographic device to encapsulate a message m, such as a key seed, like something like v = BR + E' + q / 2m. The second cryptographic device sends back U = AR + E' and v, etc., to the first cryptographic device.

[0265] Examples of such grid-based public-key encryption schemes include Round5 (e.g., page 17 of the specification, algorithms 1 and 2), FrodoKEM (page 17 of the specification, algorithms 9 and 10), NewHope (page 7, algorithms 1 and 2), SABER (page 7, algorithms 1 and 2), or Kyber (page 9 of the specification, algorithms 4 and 5).

[0266] If the second public key B has an outlier, then this may be insecure. For example, if B is outlier, then v leaks the encapsulated message m. This is because BR+E” is small compared to q / 2m. The second public key may be small for any reason, such as accidentally, like a programmer error, or as part of an attack, making subsequent denial possible.

[0267] Similarly, a specially crafted public key U can reveal information about the private key. This problem is most apparent for the party using a long-term private key, such as the first cryptographic device. For example, this problem may occur with a small, specially crafted key U or one with many zero components. An example of an attack of this nature is given in the paper “An Efficient Key Mismatch Attack on the NIST Second Round Candidate Kyber” (Yue Qin, Chi Cheng, Member, IEEE and Jintai Ding, Cryptology ePrint Archive: Report 2019 / 1343), which is included in this paper by reference.

[0268] Below are several examples of authentication procedures that can be applied to public keys. One or both of the first and second cryptographic devices can be configured with authentication procedures.

[0269] Upon receiving the public key B (or U), the cryptographic device can check whether the values ​​of the public key follow a corresponding probability distribution. This can be done by performing statistical tests, such as the chi-square test, binomial test, or multinomial test; see, for example, David Diez et al., 4th edition, "Open Intro Statistics". For instance, in the case of a noncyclic parameter set, the values ​​of the public key can be tested against the probability distribution of the public parameters B and / or U. and Each component performs these tests.

[0270] Chi-square tests can be used to verify whether B and / or U are uniformly distributed. For example, a cryptographic device can be configured to: (i) compute a histogram of common parameters, such as B or U, (ii) compute its chi-square statistic, and (iii) compare it to a fixed pre-computed value. The critical value can be determined by the degrees of freedom, such as the number of bins - 1 and the P-value. The P-value can be chosen as a target failure probability less than the Round 5 parameter set. Preferably, for a chi-square test, the number of expected elements per bin is at least 10. Furthermore, the test tends to be more accurate for a larger number of bins. In an embodiment, the number of bins can be set to... Or set to Or approximately.

[0271] In this embodiment, the test is performed twice: once on the histogram version derived from public key B and / or U, and once on the histogram derived from the public key after shifting the public key components. For example, the public key components can be shifted by k / 2, where k is the bin size. This has the advantage of better detecting non-uniform distributions of values ​​close to the minimum and maximum values ​​of consecutive bins.

[0272] The binomial test can be used to verify whether a certain value (such as zero) frequently occurs unexpectedly. Given the expected probability of a value or a set of values, we can obtain a threshold such that the tail of the binomial distribution (indicating how likely it is that one or more values ​​will occur more frequently than the threshold) is less than the target failure probability of the Round5 parameter set.

[0273] In an embodiment, the check is performed over the entire range of possible values ​​for the components of public key B and / or U. This is particularly advantageous when using a balanced secret, such as in Round 5. The test can be performed directly on B and U. The binomial test can also be performed on a histogram derived from the public key. This has the advantage of reducing memory requirements. As for the chi-square test, it is advantageous to perform the test on both non-moving and moving histograms; that is, the histogram obtained from the received public key and the histogram obtained after moving the public key components. For example, the public key components can be moved by k / 2, where k is the bin size.

[0274] Chi-square and binomial tests may involve two thresholds. To obtain the chi-square threshold, or critical value (CV), one can find the minimum CV where the upper-regularized incomplete gamma function is less than the target failure probability. In other words, one can calculate the minimum CV where the integral of the upper part of the cumulative distribution function is less than the target failure probability.

[0275]

[0276] Where Γ() is the Gamma function, and DF refers to the degrees of freedom. Similarly, the threshold for the binomial distribution can be determined as a minimum value c, such that:

[0277]

[0278] in:

[0279]

[0280] For example, the parameter set R5ND_1CPA_0d for Round 5 can be used for the chi-square and binomial tests using the following two thresholds: 297 and 43. The first value considers a histogram version of the exchange parameter set using a bin size of 32. The second threshold assumes that each of the p potential values ​​for each component of B or U has been checked. The table below includes C code containing the function checkPublicParameter(), which performs the Chi-square and binomial tests on the input public parameters according to the above description. In this table, PARAMS_D is the number of components of B, and PARAMS_P refers to the size of each component. If the number of bins is a power of 2, the table gives an optimized implementation.

[0281]

[0282]

[0283]

[0284]

[0285] For example, in Round5, Saber, and Frodo, the public key values ​​are uniformly distributed across Z_p (Z_q in Frodo). A histogram with k bins can be computed, e.g., k > 2, and the distribution of elements in B across p / k bins can be calculated. For example, k can be chosen such that p / k is small, e.g., p / k = 4. Larger values ​​for p / k are also possible. In this embodiment, k is a power of 2. For example, since Round5, Saber, and Frodo have p (and / or q) that are powers of 2, powers of 2 are also used for values ​​of k.

[0286] If we consider p / k bins, then the probability of a value less than k is equal to k / p. The probability that exactly c values ​​in d are less than k can be calculated as:

[0287]

[0288] The above formula holds for every k, without requiring k to be a power of 2. The probability that there are more than d-c_max distinct values ​​less than v can be calculated as p(d,dc) and c from 0 to excluding c_max. Therefore, one can calculate the maximum value c that is very small in probability that the public key has so many small entries.

[0289] For example, consider a public key with d values, such as a polynomial public key of degree d-1. For d = 700, p = 256, and k = 256 / 4 = 64, the probability of finding a public key B such that at most 6 terms are greater than 64 is less than 2^{-256}. Using this, suppose the verification process for the above values ​​is as follows:

[0290] k = p / 4

[0291] Distribution [p / k] = {0, 0, 0, 0}

[0292] For i = 0 to d, the distribution is [(B[i] >> logk)]++}

[0293] If distribution [0] > d-6, then {reject the public key}

[0294] The algorithm described above can be executed upon receiving public key B or U. The receiving device first sets a suitable value for k, as described above. Then, it initializes an array called the distribution, where p / k = 4 bins are set to 0. Next, in example B above, the receiving device cycles through the coefficients of the received public key. For each coefficient, it performs a shift of log k bits to the right, i.e., log p – 2 bits, such that only the two most significant bits are retained, and these two bits are used to increment the corresponding bin in the distribution array. In the last row, if the first bin has a value greater than d – 6, then public key B is rejected. The test can be modified or extended by rejecting other elements in the distribution array.

[0295] For example, this check can be applied to the cryptographic protocols described herein, such as Round5, SABER, Frodo, etc. Note that the above implementation assumes that k and p are powers of 2 and are categorized into p / k bins. However, this is not necessary; for example, if p is not a power of 2, one can check how many values ​​are less than k. It should also be noted that if the key has too many entries close to 0, but also close to p-1, or close to both, it can be tested.

[0296] A particularly important specific case among all candidates is checking that B is not equal to 0. Another potentially weak B value is one that makes all values ​​equal or nearly equal; the latter is especially important for schemes using balanced ternary secrets (such as Round 5).

[0297] Schemes such as NewHope or Kyber perform polynomial multiplication in the transform domain (in this case, the NTT domain) to speed up computation. However, verifying the public key remains possible. For example, one can directly apply the techniques described in this paper by first transforming the public key back to the transform domain and then to the ordinary domain. However, some tests can be performed directly in the transform domain. For example, one can check whether a linear combination of the products of coefficients in the transform domain (which can be mathematically represented as equal to the Euclidean norm of the public key in the original domain) has an unlikely value, especially a unlikely small value.

[0298] For example, NewHope operates using symbolic strings from {0, 1, ..., q-1}, where q = 12289 of length n is equal to 512 or 1024. The theoretical transformation (NTT) of such a string g is defined as G = (G0, G1, ..., C...). n-1 =NTT(g0,g1,..,g) n-1 ) = NTT(g), where, Here, ω is the primitive nth root of unity in Z_q, and γ 2 =ω.

[0299] According to Table 2 in the NewHope specification, if n = 512, then γ = 10968, and if n = 1024, then γ = 7. NTT is invertible; if G = NTT(g), then Here, n -1 Is Z_q such that n·n -1 Integers ≡ 1 mod q. If f and g are sequences of length n, and e i =f i g i γ i (For 0≤i≤n-1), then it can be expressed mathematically as follows:

[0300]

[0301] In particular, if f i =g i ω -i ,So

[0302] By direct calculation Makes the following true:

[0303]

[0304] Therefore, suppose we have a threshold denoted as "normal_threshold" that is suitable for checking public keys in the transform domain, for example, NewHope as follows:

[0305] Normal = 0

[0306] For j = 0 to n, {normal += B[i] * B[n-1-i]}

[0307] Normal = Normal * n^(-1) mod q.

[0308] If normal < normal_threshold {reject public key}

[0309] In the first line, it will be initialized normally to 0. In the second line, it takes the coefficient of the received public key and calculates the (**) value. In the third line, it is multiplied by n -1 The module q is then reduced to obtain the norm. If the norm is less than a threshold, the public key is rejected.

[0310] This is effective because it successfully detects very small keys B and U. Since the norm is calculated modulo q, it is possible for some large keys B and U to be misclassified.

[0311] Therefore, instead of outright rejection, one can use the algorithm described above as an indicator to request the execution of a more expensive operation, namely, to perform a transformation back to the normal domain, and then perform any of the other checks listed in this paper.

[0312] An additional check is to see if the linear combination of coefficients corresponding to the sum of entries in the original domain is below a threshold. In practice, f is taken in (*). i =ω -i We discovered By direct calculation Here, we use ω n =1 and γ 2 =ω, such that γ n = -1. Therefore, the test for public key B in the NTT domain is if The modulus of q is below the threshold, or it is in the set of the form [0,t1)∪[q-t2,q-1].

[0313] An attack using a public key with special properties against a long-term private key may require multiple calls to the decapsulation algorithm before the attacker gains a useful amount of information. An attacker can bypass the verification process by tuning their public key so that it doesn't trigger an alarm (e.g., the public key u used for the attack has 7 non-zero elements instead of just 6), but at the cost of requiring more calls. This can be addressed by including a state integrity verification process, for example, by maintaining the state of previously exchanged messages. An alarm might be triggered if more than x deviate from a standard. For example, if a first threshold is passed, the public key might be rejected or an alarm might be generated directly, but if a less stringent second threshold is passed, a count could be incremented against the private key or the cryptographic device or combination sending the public key. If the count exceeds the threshold, the public key is rejected, or a less stringent test can be used instead of a more stringent one.

[0314] For example, a strict threshold could be 6 non-zero coefficients (or fewer), and a less strict threshold could be 7 non-zero coefficients. A public key with 6 or fewer non-zero coefficients is rejected. If a public key has 7 non-zero coefficients, the count increases. If the count exceeds the threshold (which might only be 2), the public key is still rejected. For example, if two public keys with 7 non-zero coefficients are received, the latter is rejected; furthermore, from that point onward, 7 non-zero coefficients might be sufficient to reject the public key.

[0315] Figure 5 An example of a cryptographic system 301 according to an embodiment is illustrated schematically. System 301 includes a first cryptographic device 300, a second cryptographic device 350, and an optional public key repository 302. For example, the first device 300 and the second device 350 may be implemented on devices such as first devices 10, 100 and / or second devices 20, 200. Cryptographic system 301 may be implemented as follows: Figure 4 The illustrated public-key encryption system. Cryptographic system 301 can be adapted to other embodiments as needed (e.g., by omitting elements not used in the described embodiment).

[0316] First device 300 and second device 350 are configured to execute cryptographic protocols. They have the ability to securely transfer data from one device to another. Various cryptographic protocols can use this same capability. As an example, two protocols using this capability are described.

[0317] For example, the first and second devices can be configured for public-key encryption (e.g., designed to allow other devices (e.g., second device 350) to encrypt the message (m)), enabling a specific device (e.g., first device 300) to decrypt the encrypted message. However, the content of the public-key encrypted message cannot be obtained by any other device besides the encryption and decryption devices (e.g., second device 350 and first device 300). In the case of public-key encryption, multiple second devices can send encrypted messages to the first public device using the same public key of the first device (e.g., the same first public key and public object). Even if the second devices use the same public key to encrypt the message, they cannot decrypt the communication of another device.

[0318] The first device 300 and the second device 350 each include communication interfaces 305 and 355. The communication interfaces are configured to communicate with each other. Examples of communication interfaces, such as those via wired or wireless networks, are described herein.

[0319] The first device 300 includes a public / private key generator 315 configured to generate a first private key(s) and a first public key(b) derived from the first private key. The public key derived from the private key may use a public object(a), such as a public matrix or a public polynomial. For example, generating the public key may involve multiplying with a public object and / or introducing some type of noise, such as scaling down the multiplication result, adding noise terms, etc. The private key and the public object may be matrices, such as matrices over finite fields or rings.

[0320] A first private key and a first public key can be generated ephemerally. For example, the latter can be performed against a key negotiation protocol, particularly when the first and second devices authenticate each other using additional authentication mechanisms (e.g., out-of-band mechanisms, such as certificate-based authentication). Alternatively, a first private key and a first public key can be generated for long-term use. For example, the first public key can be stored in an external public key repository 302. The public key repository 302 can also store a public object (a) or a seed for the public object (a). The public key repository 302 can be configured to perform a public key verification process on received public keys. For example, the public key repository 302 can reject keys that fail the verification process. For example, a public key that is too small (e.g., has too many small elements) might be rejected. Small elements can be determined as those whose absolute value is less than a limit.

[0321] The first public key is transmitted from the first device 300 to the second device 350, for example, via communication interfaces 305 and 355. This can be accomplished through direct communication or indirectly, for example, through a public key repository 302. If necessary, a public object (a) can also be transmitted along with the first public key. For example, the public object can be transmitted by sending a seed from which a public object (a) can be generated.

[0322] The second device 350 may include a public key obtainr 360, which is configured, for example, to retrieve a first public key from a public key repository 302. This type of acquisition is suitable for public key encryption, for example. However, the public key may also be obtained directly from the first device, which could be out of bounds, for example, in an email. The public key may be stored until a public key encryption exchange is required. However, the first public key may also be received for immediate use, such as for key sharing operations; in this case, the first public key and / or public object may be briefly generated. The public key obtainr 360 may be configured to perform a public key verification process.

[0323] The second device 350 may include a public / private key generator 365 configured to generate a second private key (r) and a second public key (u) based on the second private key (r). The second private key (r) and the second public key (u) may be smaller than the first private key (s) and the first public key (b), for example, having fewer entries.

[0324] The second public key uses the same public object as when the first public key was generated. The first and second private keys are the private keys for their respective devices. They can be shared with trusted parties if needed, such as for backups, key escrow, etc. Public keys and public objects are not necessarily secret for security purposes; however, one or more of them can still be private to both the first and second devices if desired. For example, the first public key can only be shared with the second device, and vice versa.

[0325] The second device 350 may include a codeword generator 370. The codeword generator 370 is configured to generate codewords based on error-correcting codes. The error-correcting codes can be linear or non-linear codes. For example, error-correcting codes can be BCH codes, Reed-Solomon codes, Hadamard codes, etc. Multiple codes can be concatenated. Concatenated codes are error-correcting codes constructed from two or more simpler codes to achieve good performance with reasonable complexity. For example, Hadamard codes can be concatenated with BCH codes.

[0326] Encoded in a codeword is the data used for encapsulation. For example, a codeword can be divided into a data portion (e.g., data bits) and a parity portion (e.g., parity bits). For example, the data used for encapsulation can be included within the data bits. One method for generating a codeword is to generate the data portion and compute the parity bits based on that data portion. For example, a data vector with data bits can be matrix-multiplied with a parity matrix to obtain the parity bits, or even the complete codeword. Codewords can be obtained by combining the data used for encapsulation with the parity bits. For example, the data portion and the parity portion can be concatenated, but any arrangement of data bits and parity bits can be used to generate a valid codeword based on the corresponding error-correcting code. For example, data bits and parity bits can be alternated. Note that reconciliation data is typically computed on a single q-ary symbol, but parity data is typically computed over multiple bits; note that q is much greater than 2.

[0327] The codeword can be used in various ways. Public key encryption can also be obtained by encrypting the message (m) at a second device 350 (e.g., with a symmetric key (e.g., randomly generated for this purpose)) and encoding the encryption symmetric key in the codeword. Additional key derivation steps can be used. For example, a random pre-key can be encoded in the codeword, and the encryption key can be derived from the pre-key. For example, the derivation can use a Key Derivation Function (KDF), such as a hash function. For example, in the latter case, the encrypted message can be sent from the second device to the first device along with the data required to decrypt that data (e.g., the second public key and other data, as discussed below). The key seed can be directly encoded in the codeword or derived from the codeword.

[0328] Interestingly, the codewords are generated independently of the first private key, first public key, second private key, and second public key. Therefore, this protocol improves resistance to active attacks. An attacker has a low probability of influencing the shared key because they cannot affect the key by choosing the first and second private keys. In this embodiment, the second private key matrix is ​​derived from the codewords or from the key seed.

[0329] For example, in the case of messages, if the message is generated based on an application independent of public-key encryption (e.g., a financial or communications application), independent generation can be achieved. For instance, independent generation can be achieved through random generation. For example, the key or pre-key in the codeword can be generated independently, for example, using a genuine random number generator or a pseudo-random number generator (which uses a seed independent of the first and second private keys; for example, it is itself randomly generated or predetermined). For example, the codeword can be generated at a second device even before the first public key is received and / or before the second private key is generated; this also ensures independence.

[0330] The second device 350 includes a Diffie-Hellman unit 375. The Diffie-Hellman unit 375 is configured to generate a second original shared key (k*) based on a first public key (b) and a second private key (r). For example, the Diffie-Hellman unit 375 can be configured to apply a Diffie-Hellman function to the first public key and the second private key. For example, the Diffie-Hellman function can be multiplicative. The second device 350 is configured to transmit its second public key to the first device 300. The first device 300 includes a Diffie-Hellman unit 325. The Diffie-Hellman unit 325 is configured to generate a first original shared key (k') based on the second public key (u) and the first private key (s), for example, by applying the same Diffie-Hellman function. Unfortunately, for some types of Diffie-Hellman functions, the first and second original keys may be close to each other, but are not necessarily the same. The specific probability of this occurring depends on the underlying Diffie-Hellman function. In most applications, some probability of different raw keys is acceptable; however, how high this probability is will depend on the application. Generally, however, a lower probability is preferred. The raw key can have the same mathematical type as the private and public keys, for example, a matrix.

[0331] The second device 350 includes a reliable bit generator 380 and a reconciliation data generator 385. The reliable bit generator 380 is configured to apply a reliable bit function to a second original shared key (k*) to obtain a reliable index and reliable bits derived from indicated coefficients. The reliable index indicates the coefficients of the original shared key. For example, the reliable bit generator 380 can determine which coefficients in the original key are close to the sampling boundary and which are not. For example, coefficients in the original key that are within a threshold of the sampling boundary can be considered unreliable and discarded. The remaining reliable coefficients can be indicated by the reliable index. Reliable bits can be obtained by sampling the reliable coefficients.

[0332] If the remaining coefficients are insufficient, there are several probabilities, such as terminating the protocol, restarting the protocol using a new first private key and / or a second private key and / or a new public object, deriving a shorter key, or discarding fewer coefficients. Instead of selecting all coefficients within a threshold, a predetermined number of coefficients (e.g., mu coefficients) can be selected, and the most reliable coefficients (e.g., the first mu most reliable coefficients) can be chosen.

[0333] One approach to implementing reliable bits is to use one or more (e.g., B) most significant bits of the coefficients. For example, the number of reliable bits for each selected coefficient can be 1 or 2. In some embodiments, such as when using large matrices, the number of coefficients is large, which allows for high reliability, such as low values ​​of B. For other embodiments, such as for IoT devices, larger values ​​of B can be used. The calculations in the finite ring can be performed on a finite ring of integers modulo 2. The advantage of the latter choice is a more uniform distribution of reliable bits.

[0334] Reconciliation data generator 385 is configured to generate reconciliation data (h) for the indicated coefficients of the original shared key. The reconciliation data includes information that allows for reducing the differences between the first and second original keys derived at the first and second devices. For example, applying the reconciliation data can reduce the differences (e.g., Lee distance) between the coefficients of the original keys at the first and second devices, thereby increasing the probability that both will produce the same reliable bits. Both the parity bit in the codeword and the reconciliation data are used to reduce noise; however, the parity bit is calculated over multiple data bits, while the reconciliation data is calculated over the coefficients in the original shared key. The reconciliation data further improves the reliability of the reliable bits.

[0335] One method for implementing reconciliation data is to use one or more bits of the coefficient immediately following the considered reliable bit (e.g., b). h (B) bits. For example, these bits could be b that immediately follows these B bits in terms of validity. hUnits. For example, the number of reconciliation digits for each selected coefficient can be, say, 1 or 2. Smaller reconciliation digits have the advantage of reducing communication overhead. However, a larger number of reconciliation digits is also possible.

[0336] The second device 350 may include a packaging unit 390. The packaging unit 390 is configured to encapsulate a codeword using reliable bits by applying a packaging function, such as XOR. This packaging may be a one-time pad package. In embodiments, the packaging function achieves perfect security in the sense that zero information about the codeword can be obtained from the encapsulated codeword without knowing the reliable bits. For example, an XOR function may be used on one of the other packaging functions described herein.

[0337] Please note that encapsulation applies to the entire codeword, including both data bits and parity bits, not just the parity bits. Furthermore, encapsulation applies to the generated data (e.g., messages, keys, pre-keys, etc.), but not to data derived from one or more of the first public key, second public key, first private key, or second private key.

[0338] The second device is configured to transmit a second public key (u), reconciliation data (h), encapsulated data (c), and a reliable index to the first device. This transmission may, for example, respond to the receipt of the first public key in the case of key negotiation, or, for example, not respond to the receipt of the first public key in the case of public key encryption.

[0339] The first device 300 is configured to receive a second public key (u), reconciliation data (h), encapsulation data (c), and a reliability index from the second device. The first device 300 can be configured to perform a public key verification process on the public key (u). The first device 300 includes a reconciliation unit 335, which is configured to apply the reconciliation data (h) from the reconciliation function to coefficients in the first original shared key (k') indicated by the reliability index (safe_bits), thereby obtaining the reliability bits (k). For example, the reconciliation bits can be used to reconcile coefficients indicated as reliable, and then sampled to obtain the reliability bits.

[0340] The first device 300 includes a decapsulation unit 340 configured to decapsulate the encapsulated data (c) to obtain a near codeword using reliable bits. The reason for not directly obtaining the codeword from the second device is that even with reliable bits and reconciliation, the differences between the original keys cannot be resolved. The first device 300 includes an error corrector 320 configured to apply an error correction function to the near codeword to obtain the codeword.

[0341] Finally, the codeword can be decoded to obtain, for example, the data portion, thereby obtaining the message (m), the key (K), or a pre-key, such as a key seed. In the first case, some measures can be taken based on the message; for example, the message can be displayed in a communicator application. In the second case, the key can be used for further protected communication, etc. In the third case, a key derivation function can be applied to the pre-key to obtain a shared key.

[0342] In some embodiments, the processor of the second cryptographic device is configured to derive a final key based at least on a key seed, encrypt a message using the final key, and transmit the encrypted message to the first cryptographic device. In some embodiments, the processor of the first cryptographic device is configured to receive an encrypted message from the first cryptographic device, derive a final key based at least on a key seed, and decrypt the encrypted message using the final key.

[0343] For example, in an embodiment, the second cryptographic device and / or the private key decryption device may derive the final key at least in part based on applying a cryptographic hash function to the key seed. As an illustrative example, the final key can be derived from the key seed K by applying a cryptographic hash function to the key seed and optionally some or all of the public key (e.g., G = H(m||pk)). Such a cryptographic hash G can be used directly as the final key, or optionally, at least a portion of such a cryptographic hash, such as L||rest = G, can be further hashed, for example, using a masked key seed c, to obtain the final key, for example, k = H(L||c).

[0344] Figure 6a An example of a second cryptographic method (400) according to an embodiment is illustrated schematically. Method 400 includes:

[0345] - Establish communication with the first cryptographic device (410),

[0346] - Obtain (420) the first public key (b) associated with the first cryptographic device,

[0347] - Generate a second private key (r) (430), and calculate a second public key (u) based on the second private key (r).

[0348] - Calculate the second original shared key (k*) based on the second private key (r) and the first public key (b), the calculation of the second original shared key includes noise multiplication between the second private key (r) and the first public key (b),

[0349] - By applying a sealing function to seal at least a portion of the second original shared key to obtain the sealed data (v), and

[0350] - The second public key (u) and the encapsulated data (v) are transmitted (460) to the first cryptographic device, and

[0351] - Apply the (405) verification process to the obtained public key (b) to determine whether the public key is secure for encapsulating the key seed, wherein if the verification process fails, the key seed is not encapsulated or the encapsulated data (v) is not transmitted.

[0352] Verification process 405 can be performed between obtaining 420 and encapsulating 450. Verification process 405 can also be performed after encapsulating 450, in which case the encapsulation can be discarded, for example, before transmitting 460.

[0353] Figure 6b An example of a first cryptographic method 500 according to an embodiment is illustrated schematically. Method 500 includes:

[0354] - Establish communication with the second cryptographic device (510),

[0355] - Generate (520) a first private key(s) and calculate a first public key(b) based on the first private key(s), and allow the first public key(b) to be transmitted to a second cryptographic device.

[0356] - Receive (530) the second public key (u) and encapsulated data (v) from the second cryptographic device.

[0357] - Calculate the first original shared key (k') based on the second public key (u) and the first private key (s). Calculating the first original shared key includes multiplying the noise between the second public key (u) and the first private key (s).

[0358] - Use at least a portion of the first original shared key (k') to decapsulate (550) the encapsulated data (v) to obtain the key seed, and

[0359] - Apply a verification process (505) to the obtained public key to determine whether the public key is secure for decapsulating the key seed, wherein if the verification process is unsuccessful, the key seed is not decapsulated or the decapsulated data (v) is not used.

[0360] As will be apparent to those skilled in the art, there are many different ways to perform this method. For example, the steps can be performed in the order shown, but the order of the steps can also be changed, or some steps can be performed in parallel. Furthermore, other method steps can be inserted between the steps. The inserted steps may represent, for example, an improvement on the method described herein, or they may be unrelated to the method. In addition, a given step may not be fully completed before the next step can begin.

[0361] Embodiments of the method can be executed using software, which includes instructions for causing a processor system to perform methods 400 and / or 500. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored on a suitable storage medium (e.g., hard disk, floppy disk, memory, optical disk, etc.). The software may be transmitted as a signal along a wire, wirelessly, or using a data network (e.g., the Internet). The software may be made available for download on a server and / or for remote use. Embodiments of the method can be executed using a bitstream arranged to configure programmable logic units (e.g., field-programmable gate arrays (FPGAs)).

[0362] It will be appreciated that the invention also extends to computer programs suitable for practicing the invention, particularly computer programs on or within a carrier. Such programs may be in the form of source code, object code, intermediate source code, and object code, such as in a partially compiled form, or any other form suitable for use in the implementation of embodiments of the method. Embodiments relating to the computer program product include computer-executable instructions corresponding to each processing step of at least one of the methods described. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to the computer program product includes computer-executable instructions corresponding to each unit of at least one of the systems and / or products described.

[0363] It should be noted that the embodiments mentioned above are illustrative and not limiting of the invention, and those skilled in the art will be able to devise many alternative embodiments.

[0364] In the claims, any reference numerals within parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of other elements or steps not mentioned in the claims. The words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. When preceding a list of elements, expressions such as "at least one of..." indicate the selection of all elements or any subset of elements from that list. For example, the expression "at least one of A, B, and C" should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all A, B, and C. The invention can be implemented by means of hardware comprising several different elements, or by means of a suitably programmed computer. In device-type claims enumerating several units, several of these units can be embodied by the same piece of hardware. The fact that certain measures are recited in dissimilar dependent claims does not mean that combinations of these measures cannot be used advantageously.

[0365] In the claims, the references enclosed in parentheses refer to the reference numerals in the drawings illustrating the embodiments or the formulas of the embodiments, thereby improving the comprehensibility of the claims. These references should not be construed as limiting the claims.

Claims

1. A second cryptographic device (20), comprising: - A communication interface configured to communicate with the first cryptographic device (10), - The processor, which is configured as follows: - Obtain the first public key (b) associated with the first cryptographic device. - Generate a second private key (r), and calculate a second public key (u) based on the second private key (r). - Calculate the second original shared key (k*) based on the second private key (r) and the first public key (b). Calculating the second original shared key includes multiplying the second private key (r) by noise between the first public key (b). - By applying a sealing function to seal at least a portion of the second original shared key to the key seed (m), sealed data (v) is obtained, and - The second public key (u) and the encapsulated data (v) are transmitted to the first cryptographic device, wherein, -The processor is also configured to: - Apply the verification process to the obtained first public key (b) to determine whether the first public key is secure for encapsulating the key seed, wherein if the verification process fails, the key seed is not encapsulated or the encapsulated data (v) is not transmitted.

2. The second cryptographic device according to claim 1, wherein, - The first public key, the first private key corresponding to the first public key, the second public key, and the second private key are matrices over a finite field or a ring, or - The first public key, the first private key corresponding to the first public key, the second public key, and the second private key are polynomials over a finite field or ring.

3. The second cryptographic device according to claim 1, wherein, The verification process includes determining whether the magnitude of the obtained first public key is below a threshold.

4. The second cryptographic device according to claim 1, wherein, The verification process includes determining whether the number of values ​​below a first threshold in the obtained first public key is less than a second threshold.

5. The second cryptographic device according to claim 1, wherein, The verification process includes: - Calculate a histogram of the values ​​in the first public key obtained and compare the calculated histogram with the expected histogram.

6. The second cryptographic device according to claim 5, wherein the verification process includes: - Determine whether the bins of the calculated histogram are less than a threshold, and / or - Determine whether the bins of the calculated histogram are greater than a threshold, and / or - Calculate the distance between the calculated histogram and the expected histogram and determine whether the distance is higher than a threshold.

7. The second cryptographic device according to claim 1, wherein, The verification process includes: - Calculate a histogram of the values ​​in the obtained first public key and apply statistical tests to the calculated histogram. - Move the first public key obtained and calculate another histogram of the values ​​in the moved first public key and apply a statistical test to the calculated another histogram.

8. The second cryptographic device according to claim 1, wherein, The verification process includes determining whether the obtained first public key is all zeros or almost all zeros.

9. The second cryptographic device according to claim 1, wherein, The verification process includes determining whether the number of identical values ​​of the first public key exceeds a threshold.

10. The second cryptographic device according to claim 1, wherein, The first public key is obtained in the transform domain, and the verification process includes determining whether the norm of the first public key in the transform domain is less than a threshold.

11. The second cryptographic device according to claim 1, wherein, - The processor of the second cryptographic device is configured to derive a symmetric encryption key from the key seed (m), encrypt a message using the derived key, and transmit the encrypted message to the first cryptographic device, and / or The processor of the first cryptographic device is configured to derive a symmetric encryption key from the key seed (m), receive an encrypted message from the second cryptographic device, and decrypt the encrypted message.

12. A first cryptographic device (10), comprising: - A communication interface configured to communicate with a second cryptographic device (20), - The processor, which is configured as follows: - Generate a first private key(s) and calculate a first public key(b) based on the first private key(s), and allow the first public key(b) to be transmitted to the second cryptographic device. - Receive the second public key (u) and encapsulated data (v) from the second cryptographic device. - Calculate a first original shared key (k') based on the second public key (u) and the first private key (s). Calculating the first original shared key includes a noise multiplication between the second public key (u) and the first private key (s). - The encapsulated data (v) is decapsulated using at least a portion of the first original shared key (k') to obtain a key seed, wherein, -The processor is also configured to: - Apply the verification process to the received second public key to determine whether the second public key is secure for decapsulating the key seed, wherein if the verification process is unsuccessful, the key seed is not decapsulated or the decapsulated data (v) is not used.

13. The first cryptographic device according to claim 12, wherein, - The first public key, the first private key, the second public key, and the second private key corresponding to the second public key are matrices over a finite field or a ring, or - The first public key, the first private key, the second public key, and the second private key corresponding to the second public key are polynomials over a finite field or ring.

14. The first cryptographic device according to claim 12, wherein, The verification process includes determining whether the magnitude of the received second public key is below a threshold.

15. The first cryptographic device according to claim 12, wherein, The verification process includes determining whether the number of values ​​below a first threshold in the received second public key is less than a second threshold.

16. The first cryptographic device according to claim 12, wherein, The verification process includes: - Calculate a histogram of the values ​​in the received second public key and compare the calculated histogram with the expected histogram.

17. The first cryptographic device according to claim 16, wherein the verification process includes: - Determine whether the bins of the calculated histogram are less than a threshold, and / or - Determine whether the bins of the calculated histogram are greater than a threshold, and / or - Calculate the distance between the calculated histogram and the expected histogram and determine whether the distance is higher than a threshold.

18. The first cryptographic device according to claim 12, wherein, The verification process includes: - Calculate a histogram of the values ​​in the received second public key and apply statistical tests to the calculated histogram. - Move the received second public key and calculate another histogram of the values ​​in the moved second public key, and apply a statistical test to the calculated another histogram.

19. The first cryptographic device according to claim 12, wherein, The verification process includes determining whether the received second public key is all zeros or almost all zeros.

20. The first cryptographic device according to claim 12, wherein, The verification process includes determining whether the number of identical values ​​of the second public key exceeds a threshold.

21. The first cryptographic device according to claim 12, wherein, The second public key is received in a transform domain, and the verification process includes determining whether the norm of the second public key in the transform domain is less than a threshold.

22. The first cryptographic device according to claim 12, wherein, - The processor of the second cryptographic device is configured to derive a symmetric encryption key from the key seed (m), encrypt a message using the derived key, and transmit the encrypted message to the first cryptographic device, and / or The processor of the first cryptographic device is configured to derive a symmetric encryption key from the key seed (m), receive an encrypted message from the second cryptographic device, and decrypt the encrypted message.

23. A second cryptographic method (400) for a second cryptographic device, comprising: - Establish communication with the first cryptographic device (410), - Obtain (420) the first public key (b) associated with the first cryptographic device, - Generate a second private key (r) (430), and calculate a second public key (u) based on the second private key (r). - Calculate (440) a second original shared key (k*) based on the second private key (r) and the first public key (b). Calculating the second original shared key includes multiplying the second private key (r) by noise between the first public key (b). - By applying a sealing function to seal at least a portion of the second original shared key to obtain (450) the key seed (K;m), the sealed data (v) is obtained, and - The second public key (u) and the encapsulated data (v) are transmitted (460) to the first cryptographic device, and - Apply the verification process (405) to the obtained first public key (b) to determine whether the first public key is secure for encapsulating the key seed, wherein if the verification process is unsuccessful, the key seed is not encapsulated or the encapsulated data (v) is not transmitted.

24. A first cryptographic method (500) for a first cryptographic device, comprising: - Establish communication with the second cryptographic device (510), - Generate (520) a first private key(s) and calculate a first public key(b) based on the first private key(s), and allow the first public key(b) to be transmitted to the second cryptographic device. - Receive (530) the second public key (u) and encapsulated data (v) from the second cryptographic device. -Calculate (540) a first original shared key (k') based on the second public key (u) and the first private key (s), the calculation of the first original shared key includes a noise multiplication between the second public key (u) and the first private key (s). - The encapsulated data (v) is decapsulated (550) using at least a portion of the first original shared key (k') to obtain a key seed, and - Apply the verification process (505) to the received second public key to determine whether the second public key is secure for decapsulating the key seed, wherein if the verification process is unsuccessful, the key seed is not decapsulated or the decapsulated data (v) is not used.

25. A transient or non-transient computer-readable medium (1000) comprising data (1020) representing instructions for causing a processor system to perform the method according to claim 23 or 24.

Images