RU2787692C2 - Key encapsulation protocols - Google Patents

Abstract

FIELD: cryptographic devices.

SUBSTANCE: reliable bit function can be applied to the second unprocessed shared key to obtain reliable indices indicating coefficients of the unprocessed shared key and reliable bits derived from the specified coefficients. Coherence data can be formed for the specified coefficients of the unprocessed shared key. A code word can be encapsulated using reliable bits by use of an encapsulation function to obtain encapsulated data, which can be transmitted.

EFFECT: increase in security of data transmission.

14 cl, 16 dwg

Description

FIELD OF TECHNOLOGY

The invention relates to a cryptographic device, a cryptographic method and a computer-readable medium.

BACKGROUND OF THE INVENTION

In cryptography, a pre-shared key protocol is a protocol by which two or more parties that may not yet share a pre-shared key can agree on such a key. Preferably, both parties can influence the result so that neither party can force the choice of a key. An attacker who intercepts the communication between two parties need not know anything about the key. However, while an attacker who sees the same communication learns little or nothing, the parties themselves can obtain the shared key.

Pre-shared key protocols are useful, for example, for securing communications, such as for encrypting and/or authenticating messages between parties.

Practical protocols for deriving a public key were introduced in 1976 when Whitfield Diffie and Martin Hellman introduced the concept of public key cryptography. They proposed a system for deriving a shared key between two parties that exploits the apparent complexity of computing logarithms over a finite field GF(q) of q elements. Using this system, two users can generate a common symmetric key. The symmetric key is then used, say, for encrypted communication between two parties.

Modern methods of deriving a shared key when a party does not yet have a shared secret, such as deriving a shared Diffie-Hellman method, require resource-intensive mathematical operations. For example, the Diffie-Hellman algorithm requires exponentiation operations to be performed on a finite field. Both the exponent value and the field size can be large. Because of this, pre-shared key derivation protocols are less suitable for devices with low resources. On the other hand, pre-shared key derivation protocols will be very useful in devices with limited resources. For example, in applications such as the Internet of Things (IoT), self-organizing wireless networks, etc., the generation of a shared key would be useful for securing communication lines between devices. Another example is communication between a reader and an electronic tag, say a card reader and a smart card, or a tag reader and a tag, such as an RFID tag or an NFC tag. It would be useful to have a protocol for deriving a shared key that places less of a burden on at least one of the two parties, such as an electronic tag.

To facilitate secure communication between parties, pre-shared key derivation protocols are sometimes further subdivided into cryptographic key exchange (KEX) and cryptographic key encapsulation (KEM) schemes. Cryptographic key encapsulation (KEM) schemes use asymmetric cryptography to establish a shared secret between two parties using a commonly known value (eg, public key) and a value kept secret (eg, secret key) for each party.

KEX schemes involve the exchange of public keys by each party, which are then independently used by the other party, along with its own private key, to calculate a common shared key. A well-known example of a KEX scheme is the Diffie-Hellman key exchange mentioned above, whose security is based on solving the discrete logarithm problem. An interesting feature of some KEX schemes is that the parties never exchange the actual final shared secret, even in encrypted form, and the two parties compute it independently at each end. As a result, a desired property, known as forward secrecy, is achieved, which ensures that even an attacker's discovery of a party's long-term secret key in the future does not compromise the secrecy of encrypted messages exchanged in the past.

KEM schemes establish a shared secret between two entities or parties by using one party, usually the initiator of the exchange, to use asymmetric cryptography to encrypt (using the other party's public key) and transmit the shared key to another party, called the responder, who can then decrypt it ( using your private key) and then used for secure data exchange with the initiating party. KEM schemes cannot achieve forward secrecy because any attacker who breaks a party's secret key for a past session and records all the messages exchanged by the parties in that session can recover the shared secret for that particular session.

With the growing demand for security in the Internet of Things, key exchange schemes must also achieve high performance (eg, minimum data exchange or bandwidth requirements) while remaining robust against classical as well as quantum-capable attackers.

Cited Literature:

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

RLWR: "Pseudorandom Functions and Lattices", by Abhishek Banerjee, Chris Peikert, and Alon Rosen,

LWE: "On Lattices, Learning with Errors, Random Linear Codes, and Cryptography", by Oded Regev.

LWR: "Pseudorandom Functions and Lattices", by Abhishek Banerjee, Chris Peikert, and Alon Rosen,

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

Round2: "Round2: KEM and PKE based on GLWR", by Hayo Baan, Sauvik Bhattacharya, Oscar Garcia-Morchon, Ronald Rietman, Ludo Tolhuizen, Jose-Luis Torre-Arce, and Zhenfei Zhang

This literature is incorporated herein by reference.

DISCLOSURE OF THE INVENTION

It would be useful to have improved cryptographic devices that solve these and other problems. The first and second cryptographic devices are presented.

The second cryptographic device may include a communication interface configured to communicate with the first cryptographic device. The second cryptographic device may include a processor. The processor may be configured to do one or more of the following:

- obtaining the first public key for the first cryptographic device,

- generating a second private key, a code word in accordance with the error correction code and generating a second public key from the second private key,

- generating a second raw public key from the first public key and the second private key,

- applying the reliable bits function to the second raw public key to obtain reliable indices indicating the coefficients of the raw public key, and reliable bits derived from the indicated coefficients,

- generating matching data for said coefficients of the raw shared key, wherein the matching data contains information to reduce differences between the first and second raw keys output on the first and second device,

encapsulating the codeword using reliable bits by applying the encapsulation function to obtain encapsulated data, and

- transmitting the second public key, agreement data, encapsulated data and trusted indexes to the first device.

The first cryptographic device may include a communication interface configured to communicate with the second cryptographic device. The first cryptographic device may include a processor. The processor may be configured to do one or more of the following:

- obtaining the first private key and the first public key derived from the first private key, transmitting the first public key to the second device,

- receiving from the second device the second public key, agreement data and encapsulated data and reliable indexes,

- generating the first raw public key from the second public key and the first private key,

applying the matching data in the matching function to the coefficients in the first raw shared key indicated by the reliable indexes to obtain reliable bits,

- decapsulation of encapsulated data to obtain an almost codeword using reliable bits,

- applying the error correction function to the near-codeword to obtain the codeword.

Interestingly, encapsulation is applied to both data bits and parity bits, not just parity bits. Moreover, encapsulation is applied to the codeword, which may be partially formed data, such as a message, a key, and/or a pre-shared key. Encapsulation is not applied to data that is derived from private keys or even from public keys. This improves resistance to active attacks. It should be noted that the code word does not depend on private keys and even on public keys.

In an embodiment, the shared key is derived from at least the data portion of the codeword. It should be noted that in an implementation, none of the safe bits are used to derive a key from them, but instead they are used for encapsulation, they may be ignored or used for other purposes, such as deriving an unbound form of the key.

In an embodiment, the first and second cryptographic devices are configured for a pre-shared key protocol. For example, a common cryptographic key may be derived from at least the data encoded in the codeword. In this case, the first private key may be generated briefly to form a shared key. The second private key can also be generated for a short time.

In an embodiment, the first and second cryptographic devices are configured for public key encryption. For example, a message can be encoded in a code word. The message may be received by the first cryptographic device. For example, the message may be encrypted with a shared symmetric key derived from at least the data encoded in the codeword. The encrypted message may be sent with the second public key from the second device to the first device. A plurality of second cryptographic devices may use the same public information, such as the first public key, to encrypt messages for the first cryptographic device.

Interestingly, these three sources of information can be used to reduce the probability of failure in the exchange of a code word and a randomly generated key from it. In addition, since the code word can be randomly generated, active protection is achieved. These sources include the use of reliable bits, matching data allocated to raw key coefficients, and redundant error correction information that is part of the codeword, such as parity bits.

For example, in an embodiment, the first and second cryptographic devices may agree on a raw key, say a polynomial key k* with n coefficients in Z_q. For example, n can be the size of a polynomial ring. For example, the coefficient in the raw key may be mapped to a portion of the final key or pre-key, such as one or more bits. For example, half of the values in Z_q can be mapped to 0 and half of the values can be mapped to 1. The choice of reliable bits can be done by choosing, for example, some number, say mu, of the coefficients that are furthest from the decoding boundary, so that the probability of doing errors are low.

The key agreement data may be information that is extracted by the second cryptographic device, for example, for selected strong coefficients, say, selected mu coefficients, raw key, say, polynomial key. The negotiation information helps the first cryptographic device to come to the same decision whether a particular coefficient of the raw key is mapped to a particular part of the codeword. It should be noted that this should only be done for selected reliable coefficients, i.e. less work required.

The error correction information may be parity bits. The parity bits can be extracted from the randomly generated binary key K, the message m, or the pre-key, so that the information that the second device encapsulates is somewhat redundant. Thus, even if mistakes are made before, the first device can correct them. Therefore, if a key K of length kappa bits needs to be transmitted and there are (mu-kappa) parity bits, these parity bits help the first device to verify that the kappa bits of key K are correct.

The first and second cryptographic devices may be electronic devices. For example, they may be computers. They may be mobile electronic devices such as a mobile phone, a smart card. The first and second cryptographic devices may be consumer electronics such as a set-top box, television.

Devices and methods in accordance with the implementation option can be applied to a wide range of areas of practical application. These practical applications include a number of cryptographic protocols. Such practical applications include messaging applications, sensor networks, data exchange, financial applications, etc.

An embodiment of the method may be implemented on a computer as a computerized method, or in specialized equipment, or a combination of both. The executable code for the method implementation may be stored in the computer program product. Examples of computer program products include storage devices, optical storage devices, integrated circuits, servers, interactive software, and the like. Preferably, the computer program product comprises non-transitory program code stored on a computer-readable medium for carrying out an embodiment of the method when the program product is executed on a computer.

In an embodiment, the computer program comprises computer program code configured to perform all or part of the steps of the method embodiment when the computer program is executed on the computer. Preferably, the computer program is implemented on a computer-readable medium.

According to another aspect of the present invention, a method for making a downloadable computer program is provided. This aspect is used when the computer program is downloaded from, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store, or when the computer program is available for download from such a store.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details, aspects and embodiments will be described by way of example only with reference to the drawings. Elements in the figures are shown for simplicity and clarity and are not necessarily drawn to scale. In the figures, elements that correspond to elements already described may have the same reference numerals. Content of drawings:

in FIG. 1 schematically shows an example of the KEX protocol,

in FIG. 2 schematically shows an example of a KEM protocol,

in FIG. 3 schematically shows an example of a KEM protocol,

in FIG. 4 schematically shows an example of a KEM protocol,

On FIG. 5a schematically shows an example implementation of a Public Key Encryption (PKE) protocol,

in FIG. 5b schematically shows an example implementation of the KEM protocol,

in FIG. 6 schematically shows how the implementations can be based on each other;

On FIG. 7a schematically shows an exemplary embodiment of a first side device 100,

On FIG. 7b schematically shows an exemplary embodiment of the second side device 200,

On FIG. 7c schematically shows an exemplary embodiment of the cryptographic system 101.

in FIG. 8a schematically shows a computer readable medium having a writable portion containing a computer program according to an embodiment,

in FIG. 8b is a schematic representation of a processor system according to an embodiment.

in FIG. 9 schematically shows an example of generating a secret in accordance with an implementation variant,

in FIG. 10 schematically shows an example of a cryptographic system according to an embodiment,

in FIG. 11a schematically shows an example of a cryptographic method according to an embodiment,

in FIG. 11b schematically shows an example of a cryptographic method according to an embodiment.

Appendix A, which is part of this specification, provides schematic mathematical descriptions of implementation examples.

List of reference items:

10 - first side

20 - second side

100 - first party device

130 - communication interface

191 - computer network

192 - storage interface

194 - processor

196 - memory

200 - second party device

230 - communication interface

292 - storage interface

294 - processor

296 - memory

300 - the first cryptographic device

301 - cryptographic system

302 - public key depository

305 - communication interface

315 - public/private key generator

320 - Error Corrector

325 - Diffie-Hellman block

335 - matching block

340 - decapsulation block

350 - second cryptographic device

355 - communication interface

360 - recipient of public keys

365 - public/private key generator

370 - code word generator

375 - Diffie-Hellman block

380 - reliable bit generator

385 - agreement data generator

390 - encapsulator

1000 - computer readable medium

1010 - writable portion

1020 - computer program

1110 - integrated circuit(s)

1120 - processing unit

1122 - memory

1124 - ASIC

1126 - communication element

1130 - interconnect

1140 - processor system

IMPLEMENTATION OF THE INVENTION

While the present invention may be embodied in many different forms, one or more specific embodiments are shown and will be described in detail in the drawings, with the understanding that the present description is to be considered as exemplifying the principles of the present invention and is not intended to limit the invention to the specific embodiments shown and described. implementation options.

In the following, for purposes of understanding, the elements of the embodiments are described at runtime. However, it is obvious that the respective elements are configured to perform the functions described as being performed by them.

In addition, the present invention is not limited to these embodiments, and the invention lies in each of the new features or combination of features described herein or set forth in mutually different dependent claims.

We present a KEM protocol that uses a KEX key k to encapsulate a random key K defined by the second part as well as parity bits in K. Implementations use KEX for encapsulation and a reliable bits function to reduce failure probability. Since the KEX key is used for encapsulation, ancillary data can be exchanged, which imposes low bandwidth requirements and reduces the chance of failure. Through encapsulation, active protection can be achieved. Since the parity bits are also encapsulated, again, a better failure probability can be achieved. In the implementations below, we will refer to the safe_bits function, but it can be any safe bits function.

The problem with many quantum-resistant key exchange protocols is that they have some probability of failure. For example, the first party and the second party initially generate a common noisy raw key, which is then negotiated, eg, through the negotiation data. The reliable bits function allows a second party, such as the party that first outputs the raw key, to identify which bits in the raw key are most likely to be output in the same way by the first side, and which bits in the raw key are less likely to be output by the first side.

In a direct implementation, the reliable bits functions define two or more center points for the coefficients that are sampled to produce the key bits. Coefficients that are too far away from these center points, for example in accordance with a threshold value, may be discarded, while the rest may be selected for the value associated with the center point. For example, the number of center points can be a power of 2. For example, the coefficients can be polynomial coefficients or matrix elements, possibly over very different rings, and the like.

намного больше требуемой длины ключа. Например, вторая сторона может выбрать m индексов в

, которые, скорее всего, будут согласованы. Эти безопасные коэффициенты могут быть коэффициентами, наиболее близкими к центральным точкам диапазонов коэффициентов, которые отображаются в нулевой бит или в единичный бит; k = 0 и k = 1. Например, в кольце по модулю q коэффициент

может быть отображен в 0, если

находится в диапазоне

, и в 1, если

находится в диапазоне

находится в диапазоне

, или наоборот. Если

не находится ни в одном их этих двух диапазонов, он не является надежным битом. Значение

определяет, в частности, надежность битов. Например, в этом случае оно может быть выбрано как

; меньшие значения для

обеспечивают более высокую надежность, но меньше битов ключа. В данном случае центральными точками могут быть

и

или их округленные значения.When choosing reliable bits, the assumption is made that not all bits given by the dimension of the ring are needed for the keys. Typically, the dimension of the underlying polynomials/matrices

much larger than the required key length. For example, the second party can choose m indices in

which are likely to be agreed upon. These safe coefficients may be the coefficients closest to the center points of the coefficient ranges that map to a zero bit or a one bit; k = 0 and k = 1. For example, in a ring modulo q, the coefficient

can be mapped to 0 if

is in the range

, and in 1 if

is in the range

is in the range

, or vice versa. If

is not in either of those two ranges, it is not a reliable bit. Meaning

defines, in particular, bit reliability. For example, in this case it could be chosen as

; smaller values for

provide higher security but fewer key bits. In this case, the central points can be

and

or their rounded values.

The second party, which applies the above procedure, obtains the safe bit indices and the key bits that correspond to them. Trusted indexes can be communicated to the first party, but trusted key bits cannot. The first party can derive the key bits from the bits with indexes specified by the second party. Because these bits are more reliable, the error rate will be lower.

Further implementations of the trusted bits functions can be found in the Hila 5 article incorporated herein by reference. For example, the algorithms of Section 3 can be applied. The inventors have found that the reliable bit functions can be applied in a number of situations, for example, with different underlying rings or entities, such as polynomials or matrices.

There are a number of different key exchange and key encapsulation mechanisms, which are illustrated with reference to the figures.

On FIG. 1 schematically shows an example of a KEX protocol. An example of this protocol is spKEX or Frodo.

On FIG. 2 schematically shows an example of a KEM protocol. An example of this protocol is the CPA-PKE version of Round2 or NewHope Simple.

On FIG. 3 schematically shows an example of a KEM protocol with error correction.

On FIG. 4 schematically shows an example of a KEX that uses a KEX key to encapsulate the key and includes error correction. An example of this protocol is HILA5.

The following symbols are used in the figures:

- a represents the master copy of the secret, such as a polynomial in the given ring (eg, as in RLWE or RLWR) or a matrix with entries in integers (eg, as in LWE or LWR).

- r and s represent the secrets of the first side and the second side.

- b and u represent the "open" common parts of the first side and second side key, shown as the product of a*r or a*s . This representation of an operation actually means a one-way function of the underlying task. The asterisk (*) operation outputs a new math object from the two original objects, while introducing some noise. For example, the asterisk operation can be a polynomial or matrix product; for example, noise can be introduced by adding noise elements or implicitly, such as by rounding off. Examples of the asterisk operation can be found in what could be (R)LWE or (R)LWR or their modular version. For example, a*r can mean Round( (A*r (mod q)), p, q), such as in LWR. This means the product of r, which is a vector of length n, by an n×n square matrix A modulo q. The result is then rounded to integers p and q, where p < q, by doing p/q (A*r (mod q).

- c represents the ciphertext.

- h represents ancillary data containing justification bits.

- parity_bits refers to information used for error correction.

- get_reconciliation(k) is a function that returns the reconciliation bits from the raw key k.

- reconciliate(k,h) is a function that reconciles the raw key k given the reconciliation bits h.

- encapsulate(m,k) means that message m is encapsulated with k. For example, if k belongs to Z_q, then m can also be represented in Z_q. If k belongs to Z_2, then this is equivalent to XOR. Encapsulation can be done component by component as follows:

c = k + m*(q/2) (mod q).

For example, the encapsulation function may mask message m with key k such that an error in k has a limited effect on m, such as a linear effect.

- decapsulate(c,k) means that the ciphertext c is decapsulated from k, which returns a bit string.

- obtain_parity_bits(k) means get some parity bits k. For example, the parity bits may be generated in accordance with the error correction code.

- error_correct(k, parity_bits) means that parity bits are used to correct potential errors in either k or parity bits to produce a version of k that is most likely error-free.

- safe_bits() returns two values: (i) the actual safe values and (ii) the key bit positions, which may result in a lower failure probability as the resulting values are further from the quantification bounds. The actual values returned by Safe_bits() are used later, for example for encapsulation. Positions are exchanged with the other party so that it knows which positions are needed.

The KEX in Figure 1 allows the first party and the second party to generate a shared key. This key has a low failure probability because the first party and the second party exchange some handshake bits. The problem with KEX (FIG. 1) is that it only allows one error correction step, namely the use of key negotiation. Another problem with KEX is that keys are only defined by r and s. As a result, KEX cannot achieve active protection for messages that need to be protected.

KEM in Fig. 2 allows the second party to encapsulate a random key of its choice, given the public key b of the first party. This allows you to achieve active protection. The problem with KEM (Fig. 2) is that it has only one step to reduce errors, usually by changing the compression factor in the ciphertext c. It is desirable to compress in such a way that the bandwidth requirements are lower, for example, if the elements to be encapsulated belong to Z_q, then these elements can be moved to Z_t (where t > q). However, if t is very small, the probability of error increases.

KEM in Fig. 3 allows the second side to include parity bits in the key it wants to encapsulate. Thus, the first party can correct errors that may occur. This reduces the chance of failure. The difference between error-correcting KEM (Figure 3) is that, compared to KEX, the encapsulated keys belong to Z_q or Z_t, so KEM effectively encapsulates the actual key defined by the second party. However, this also means that KEM will always have more overhead than KEX.

The protocol shown in Fig. 4 is a KEX that uses a KEX key along with error correction. The good thing about this design is that it allows you to add error-correcting code that, as in the protocol shown in FIG. 3, reduces the chance of failure. Since this is a KEX, it can also use the safe_bits() function, which returns k* public key bits, resulting in a lower failure rate. The problem with the protocol shown in FIG. 4 is that it does not enable active protection. The reason is that the key is only determined by r and s.

On FIG. 4 schematically shows an implementation of the KEM protocol, where the encapsulation function may be, for example, c = encapsulate () = (k1 | parity_bits(k1)) XOR (k2). An example of parameters for use in the protocol shown in FIG. 4, which uses the above encapsulation function:

- k1 has a kappa bit length, eg 256 bits;

- parity bits are, for example, 121 bits;

- k2 has a length of mu bits, for example 121;

- C has a length of parity_bits bits, for example 121;

- H has a length of (kappa + parity_bits)b_h bits, e.g. 256 + 121.

On FIG. 5a schematically shows an example implementation of the PKE protocol. In the PKE protocol shown in FIG. 5 use key negotiation, error correction, and secure bits.

Fig. 5a refers to the algorithms in Appendix A for specific implementation examples. However, it should be noted that Algorithms 1, 2, and 3 describe a specific implementation that may be partially implemented, for example, using primitives similar to those in RLWR. However, the protocol shown in FIG. 5a is more general because the operations a*s, a*r, b*s, u*r represent many different underlying cryptographic problems such as LWR, MLWR, RLWR, LWE, MLWE, or RLWE.

The encapsulation function could be, for example, c = encapsulate () = (K | parity_bits(K)) XOR (k*). With this choice, the following examples of parameters can be used:

- K has a kappa bit length, eg 256 bits;

- parity bits are, for example, 121 bits;

- K* has length mu = kappa + parity_bits bits, eg 256 + 121;

- c has a length of mu bits, for example 256 + 121;

- H has a length of (kappa + parity_bits)b_h bits, e.g. 256 + 121.

- Safe_bits: n bits.

In the public key encryption protocol shown in FIG. 5a, the first side 10 may generate a random object a and r, such as a polynomial or a matrix. The corresponding public key contains their product b, obtained using the asterisk operation. The object a may be shared between the two parties in another way, but in an implementation, both a and b are part of the public key. To encrypt the message m, the second party 20 may generate a short-lived private key s and from it determine the corresponding public key containing u. In PKE, the first party 10 can reuse its public key, such as a and b. The same a and b can be used by multiple parties 20 to encrypt messages for the first party 10. It should be noted that the transfer of a common object can be done by sending a seed from which a can be formed, eg, in a pseudo-random manner.

To use such a protocol as KEM, public keys can be generated randomly on both sides. Such a protocol is shown in Fig. 5b.

We present a KEM protocol that uses the KEX key k to encapsulate the random key K defined by the second part, as well as the parity bits in K. Since the key used for encapsulation comes from KEX, the safe_bits() function can be used to reduce the probability . Since this key used for encapsulation comes from KEX, ancillary data can be exchanged, which imposes low bandwidth requirements and reduces the chance of failure. By encapsulating the protocol as a whole, active protection can be achieved. Since the parity bits are also encapsulated, a better failure probability can be achieved.

This schema has the following properties:

- As in the protocols shown in FIG. 1 or Fig. 4 is KEX, so no big overhead from key encapsulation in Z_t is required.

- As in the protocols shown in FIG. 1 or Fig. 4 is KEX, so to perform key negotiation and reduce the chance of failure, justify bits are appended.

- As in the protocols shown in FIG. 3 and FIG. 4, this allows parity bits to be embedded, so that the probability of a failure is further reduced.

- Encapsulation occurs in Z_2, so the overhead for encapsulation is minimized.

For example, the following advantages are achieved compared to:

- Protocol in Fig. 1 is that the new protocol enables active protection and introduces error correction to reduce the likelihood of failure/bandwidth requirements.

- Protocol in Fig. 2 is that the new protocol allows safe bit selection and error correction.

- Protocol in Fig. 3 is that the new protocol allows you to select safe bits.

- Protocol in Fig. 4 is that the new protocol makes active protection possible.

The inventors found this approach to be more efficient than the protocol shown in FIG. 3.

, но также к ключу K. Например, ключ может быть сформирован на второй стороне. Пример такого применения показан на Фиг. 5b. Вариант реализации, например, показанный ниже на Фиг. 5b, может содержать следующие части:The protocol shown in Fig. 5a can be applied to messages

, but also to the key K. For example, the key can be generated on the second side. An example of such an application is shown in Fig. 5b. An embodiment such as shown below in FIG. 5b may contain the following parts:

- 1: The first party receives the private key r, the public parameter a, and the common part b of their public key.

- 2: The first side sends a and b. The first party may also instead send a seed to receive a.

- 3: The second party receives its secret key s, the second party randomly receives the key K, which the second party also wants to encapsulate. The second party then receives the common part u of its public key and the master key k*. The second side performs a safe bit function on k* to get the bits in k* that are the best fit, in other words, that are likely to result in fewer failures because their values are farther from the decision boundaries. Next, it uses the get_reconciliation() function to get the key agreement material for the selected secure bits. Thereafter, the second side receives the parity bits for the generated K. The parity bits are obtained using the selected error correction method. The second side then proceeds to encapsulate a binary bitstring containing (eg, consisting of) the key K and parity bits with the key k coming from the key exchange. In this case, encapsulation means applying the bitwise XOR operation, since the elements of the key belong to Z_2. This is the ciphertext c.

- 4: The second party must send the public key part u, the ancillary data h, and the ciphertext c to the first party. The other side must also enable secure bits.

- 5: The first party proceeds to receive K by first obtaining its raw key k'. It then negotiates the key given the raw key, ancillary data, and the location of the secure bits. With this information, the first party can now decapsulate and obtain a score (K|Parity_bits(K)), to which it applies the error_correct() error correction function to remove potential errors. The first side gets K.

See FIG. 6. Note that, given this building block, you can:

- Set on its basis indCPA-KEM by hashing K. This can be done in the same way as in Round2.

- Define indCCA-KEM based on it by applying a standard transformation such as the Fujisaki-Okamoto (FO) transformation. This is identical to what they do in Round2.

On FIG. 9 schematically shows an example of generating a secret in accordance with an embodiment.

In some protocols it is advantageous when secrets, such as one or both private keys, are ternary, because then calculations can be performed faster using only simple additions and subtractions, as is the case with Round2. For example, private key coefficients can be limited to -1, 0, or 1.

On the other hand, it is sometimes advantageous to use secrets that have slightly larger components (not just -1 and 1), as this makes it easier to deal with a hybrid attack, for the reason that the total entropy is higher. In an implementation, the secrets are rooted in one, since this property may allow the increase in noise to be reduced.

сконфигурирован с несколькими параметрами, таким как длина

секрета

, диапазон элементов в

и распределение элементов в

. Генератор может содержать генератор истинно случайных чисел, обычно на аппаратной основе, который используют для получения случайной затравки, применяемой для формирования псевдослучайной последовательности. Вместо генератора истинно случайных чисел могут быть использованы псевдослучайные числа.The following describes a system and methods for generating suitable secrets, such as a first and/or second private key. The system is shown in Fig. 9 where the secret generator

configured with several parameters such as length

secret

, the range of elements in

and distribution of elements in

. The generator may include a true random number generator, usually in hardware, that is used to generate a random seed that is used to generate the pseudo-random sequence. Instead of a true random number generator, pseudo-random numbers can be used.

, содержащий входные элементы, в которые будет входить

. С учетом псевдослучайной последовательности генератор получает еще один набор

, содержащий элементы в

, которые будут объединены с элементами в

.Given input parameters, the generator receives a set

A that contains the input elements that will include

. Given the pseudo-random sequence, the generator gets another set

, containing the elements in

, which will be merged with the elements in

.

может быть сохранен в памяти. Генератор может выполняться на ЦП компьютера.Received secret

can be stored in memory. The generator can run on the computer's CPU.

Deterministic way

так, что

. Например, пользователь может сконфигурировать его с использованием значения

, которое определяет длину

.The generator can be configured, for example, by the user, using a scale

so

. For example, the user can configure it using the value

, which determines the length

.

компонентами будет иметь

значений

и

значений

, где

для

.Secret s

components will have

values

and

values

, where

for

.

и задается как

.The number of nonzero elements in s is called

and is given as

.

и содержит значения

.The sequence of non-zero elements is called

and contains the values

.

значений 0, где

.Also, s will have

values 0, where

.

можно использовать

, и в этом случае

предпочтительно достаточно большое, так что

.goes to note that instead of

can be used

, and in this case

preferably large enough so that

.

размерности

нулями.The generator initializes the vector

dimensions

zeros.

генератор случайным образом формирует последовательность

с ровно

разными целыми числами в диапазоне от

до

. Затем генератор присваивает значения в

s в соответствии со значениями в

:Given the values

generator randomly generates a sequence

from exactly

different integers ranging from

before

. The generator then assigns values to

s according to the values in

:

в

позициям вектора в

, индексированным первыми

значениями в

,meaning

in

vector positions in

, indexed first

values in

,

в

присваивают позициям вектора в

, индексированным следующими

значениями в

,meaning

in

are assigned to the positions of the vector in

, indexed by the following

values in

,

…

в

присваивают позициям вектора в

, индексированным следующими

значениями в

,meaning

in

are assigned to the positions of the vector in

, indexed by the following

values in

,

в

присваивают позициям вектора в

, индексированным следующими

значениями в

,meaning

in

are assigned to the positions of the vector in

, indexed by the following

values in

,

в

присваивают позициям вектора в

, индексированным следующими

значениями в

,meaning

in

are assigned to the positions of the vector in

, indexed by the following

values in

,

…

значений

в качестве индекса в

, и присвоят значение

в

.etc. until the last one is used.

values

as an index in

, and will assign a value

in

.

Probabilistic method

так, что

. Это распределение может быть обобщено до большего количества весов, как в предыдущем разделе.Generator can be configured using scales

so

. This distribution can be generalized to more weights, as in the previous section.

генератор сначала вычисляет

и определяет последовательность

с

значениями «

» и

значениями «

». Значения

также могут быть обобщены до других значений, например,

, где

положительное целое число.Given the secret of length

generator first calculates

and determines the sequence

With

values "

" and

values "

". Values

can also be generalized to other meanings, for example,

, where

positive integer.

размерности

нулями.The generator initializes the vector

dimensions

zeros.

генератор случайным образом формирует набор

с

случайными значениями в диапазоне от

до

. Затем генератор последовательно берет элемент

в

и элемент

в

и назначает

.Taking into account

the generator randomly generates a set

With

random values ranging from

before

. The generator then sequentially takes the element

in

and element

in

and appoints

.

обновляют в соответствии со следующим псевдокодом.Vector

updated according to the following pseudocode.

Table 1. Pseudocode for the second method seed = obtain_true_random_seed()
R = generate_2_h1_pseudo_random_values(seed);
s = 0;
// first part in set P
For i = 0 to h1-1 {
s [R[i]] = s [R[i]] + 1;
}
// second part in set P
For i = 0 to h1-1 {
s [R[i+h1]] = s [R[i+h1]] - 1;
}

Deterministic way leading to binomial distribution

In this third embodiment

векторов

, каждый длины

с коэффициентами {0,1}, причем каждый вектор ровно с

ненулевыми элементами, где p является вероятностью того, что коэффициент равен 1. Для этого можно случайным образом выбрать

разных значений в [0, n - 1], которым будет присвоено значение 1.calculate

vectors

, each length

with coefficients {0,1}, and each vector with exactly

non-zero elements, where p is the probability that the coefficient is 1. To do this, you can randomly choose

different values in [0, n - 1], which will be assigned the value 1.

длины

с коэффициентами {0,1}, причем каждый вектор ровно с

ненулевыми элементами, где p является вероятностью того, что коэффициент равен 1. Для этого можно случайным образом выбрать

разных значений в [0, n - 1], которым будет присвоено значение 1.compute k/2 vectors

length

with coefficients {0,1}, and each vector with exactly

non-zero elements, where p is the probability that the coefficient is 1. To do this, you can randomly choose

different values in [0, n - 1], which will be assigned the value 1.

коэффициентами, где

коэффициент вычисляют следующим образом:calculate the secret vector s with

coefficients, where

coefficient is calculated as follows:

при

имеют вероятность

равенства

. В этом варианте реализации значения 1 в векторах

соответствуют набору

, а значения в диапазоне от 0 до

, которым присвоено значение 1, соответствуют набору

. Получающий в результате секрет имеет нуль в единице, поскольку количество 1 в каждом векторе

одинаковое, и мы складываем

векторов и вычитаем

векторов.This corresponds to a distribution that is binomial centered at 0. It is binomial because the coefficients

at

are likely

equality

. In this implementation, the values 1 in the vectors

match the set

, and values in the range from 0 to

, which are assigned the value 1, correspond to the set

. The resulting secret has zero at one because the number of 1s in each vector

the same and we add

vectors and subtract

vectors.

не должны быть разными, так что их проще формировать. Также следует отметить, что элементы в

не нужно вычислять заблаговременно, а они могут быть вычислены по ходу дела. Если целые числа в

разные, детерминистический и вероятностный способы дают один и тот же секрет s. Следует отметить также, что определение последовательности значений в P (значений, которые выделены секрету) не обязательно должно выполняться явно, а оно может оставаться неявным в коде, как это показано в таблице 1.It should be noted that in the probabilistic method (c) the integers in

should not be different, so that they are easier to form. It should also be noted that the elements in

do not need to be calculated ahead of time, but can be calculated as you go. If the integers are

different, deterministic and probabilistic methods give the same secret s . It should also be noted that the definition of the sequence of values in P (the values that are allocated to the secret) does not have to be done explicitly, but can be left implicit in the code, as shown in Table 1.

In embodiments, the two parties form two raw keys, such as polynomials or matrices, that are approximately, but not exactly, equal. To generate an accurate pre-shared key, some handshake data is sent. The scheme for this is explained in the same applicant's patent application titled "REACHING AGREEMENT ON A SECRET VALUE" filed with the EPO on November 4, 2016, application number 16197277.3; for example, the method on pages 7-10 can be used to negotiate across implementations. Variants disclosed elsewhere in the cited patent application may also be adopted.

In this application, we will use the following notation for the following three functions:

: Для

пусть 1. Rounding function

: For

let

. Тогда

. Then

выделяет

старших значащих битов

, где второй компонент является коэффициентом округления для обеспечения несмещенных ошибок округления. B указывает количество битов, выделяемых из символа

, а

указывает количество битов вспомогательных данных. В варианте реализации

может быть степенью 2.It is intuitively clear that

highlights

most significant bits

, where the second component is a rounding factor to ensure unbiased rounding errors. B indicates the number of bits to extract from a character

, a

indicates the number of bits of ancillary data. In the implementation

can be degree 2.

: Для

пусть 2. Cross round function

: For

let

. Тогда

. Then

выделяет

младших значащих битов из

старших значащих битов

.It is intuitively clear that

highlights

least significant bits of

most significant bits

.

: 3. Matching function

:

,For

,

. Ближайший элемент

может быть взят в соответствии с расстоянием Ли, например,

where v is the closest element to w so that

. nearest element

can be taken according to the Lie distance, for example,

в предположении, что

и

находятся в пределах порогового расстояния друг от друга.These three functions can be applied coefficient-wise to polynomials or matrices. The above negotiation function is used as an example in this document. As noted, matching methods in the scope cited above can also be used. The cross rounding function can be used to obtain matching data, and the rounding function to obtain data that matches, such as reliable bits. When the matching data is subsequently used in the matching function, the matching data is restored. In other words:

on the assumption that

and

are within a threshold distance from each other.

In an embodiment, the first and second public keys, the first and second private keys, and the raw key are a set of polynomials over a finite field or ring, with the public key derived from the private key by noisy multiplication by the set of common polynomials (a). For example, a set of polynomials can be used in modular lattices in which the elements of the lattice are polynomials.

On FIG. 7a schematically shows an exemplary embodiment of the first side device 100. On FIG. 7b schematically shows an exemplary embodiment of the second side device 200. On FIG. 7c schematically shows an exemplary embodiment of a cryptographic system 101 comprising a first device 100 and a second device 200. The first device 100, the second device 200 may comprise one or more of a storage interface 192, 292, a processor 194, 294, and a memory 196, 296, respectively.

The first device 100 and the second device 200, such as different devices of the system 101, may communicate with each other over the computer network 191. The computer network may be the Internet, an intranet, a LAN, a WLAN, and so on. Computer network 191 may be the Internet. The computer network may be wholly or partially wired and/or wholly or partially wireless. For example, a computer network may contain Ethernet connections. For example, a computer network may contain wireless connections such as Wi-Fi, ZigBee, and the like. The devices comprise a connection interface that is configured to communicate with other devices of the system 101 as needed. For example, the connection interface may comprise a connector, such as a wired connector, such as an Ethernet connector, or a wireless connector, such as an antenna, such as a Wi-Fi, 4G or 5G antenna. For example, the first device 100 and the second device 200 may include a communication interface 130, 230, respectively. Computer network 191 may include additional elements such as a router, hub, and so on.

The execution of the first device 100 and the second device 200 may be implemented in a processor, such as in a processor circuit, examples of which are shown herein. The first device 100, in particular the processor of the first device 100, may implement the functions of the first side 10. The second device 200, in particular the processor of the second device 200, may implement the functions of the second side 20. For example, these functions may be fully or partially implemented in computer instructions that are stored on the device 100 or 200, such as in the device's electronic memory, and are executable by the device's microprocessor. In hybrid implementations, the functional blocks are implemented partly in hardware, such as coprocessors, such as crypto processors, and partly in software, stored and executed on device 100 or 200.

Devices 100 and 200 may include a storage interface for storing and/or retrieving messages, possibly encrypted messages. For example, the storage interface may be implemented locally, eg, as an interface with the memory contained in the device, eg, memory 196 or 296, respectively. The storage interface may also be an interface with offline, eg, non-local, storage, eg, cloud storage, such as a memory or disk drive, located in another device. In the case of cloud storage, devices may also contain local storage, such as memory. For example, memory can be used to store computer program instructions, temporarily store files, and the like.

In various implementations of devices 100 and 200, the communication interface may be selected from various options. For example, the interface may be a network interface with a local or wide area network such as the Internet, a storage interface with internal or external data storage, an application interface (API), and so on.

Devices 100 and 200 may have a user interface that may include well-known elements such as one or more buttons, a keyboard, a display, a touch screen, and so on. The user interface may be configured to allow user interaction to initiate a pre-shared key protocol, respond to a pre-shared key protocol, send a message encrypted with the public key, decrypt the message with the public key, and so on.

The storage may be implemented as electronic storage, say flash memory, or magnetic storage, say hard disk, and the like. The store may contain a plurality of discrete memories that together make up the store. Storage can also be temporary storage, say RAM.

Typically, each of the devices 100 and 200 contains a microprocessor that runs the appropriate software on the devices 100 and 200; for example, this software may have been loaded and/or stored in appropriate memory, such as volatile memory such as RAM or non-volatile memory such as flash memory. In an alternative implementation, devices 100 and 200 are implemented wholly or partially in programmable logic, such as, for example, a field programmable gate array (FPGA). Devices 100 and 200 may be implemented, in whole or in part, as a so-called application specific integrated circuit (ASIC), such as an integrated circuit (IC) custom-made for its particular application. For example, the circuits may be implemented in CMOS, eg using a hardware description language such as Verilog, VHDL, etc.

In an embodiment, devices 100 and 200 may include one or more circuits for implementing one or more or all of the functions of the respective device. The circuits implement the corresponding functions described in this document. The circuits may be a processor circuit and a storage circuit, the processor circuit executing instructions electronically represented in the storage circuits.

The processor circuitry may be implemented in a distributed manner, for example, as multiple subprocessor circuits. The storage device may be distributed across multiple distributed storage subdevices. Some or all of the memory may be electronic memory, magnetic memory, and so on. For example, a storage device may have a volatile part and a non-volatile part. Part of the storage device may be read-only.

Circuits can also be FPGA, ASIC, etc.

On FIG. 10 schematically shows an example of a cryptographic system 301 according to an embodiment. System 301 includes a first cryptographic device 300, a second cryptographic device 350, and optionally a public key depository 302. For example, the first device 300 and the second device 350 on a device such as the first device 100 and/or the second device 200.

The first device 300 and the second device 350 are configured to implement a cryptographic protocol. They have the ability to securely transfer data from one device to another. This same ability can be used in various cryptographic protocols. As an example, two protocols are described that use this capability.

For example, the first and second devices may be configured for a pre-shared key generation protocol, such as being configured to generate a key, typically a symmetric key, that is shared between the two devices. The shared key can then be used by devices to secure communications, such as encrypted and/or authenticated communications, for example by using the key to encrypt messages and/or to compute an authentication label for the message. The protocol may be a public key encryption protocol, for example, configured to allow other devices, say the second device 350, to encrypt the message (m) so that a particular device, say the first device 300, can decrypt it. However, the content of messages encrypted with the public key cannot be received by devices other than the encrypting and decrypting device, such as the second device 350 and the first device 300. In the case of public key encryption, the same public key of the first device, for example, the same the first public key and the public object may be used by multiple second devices to send encrypted messages to the first open device. Even if two second devices use the same public key to encrypt a message, they cannot decrypt one another's communication.

The first device 300 and the second device 350 comprise a communication interface 305, 355, respectively. Communication interfaces are configured to exchange data with each other. Examples of communication interfaces, such as over wired or wireless networks, are described in this document.

The first device 300 includes a public/private key generator 315 configured to generate a first private key (r) and a first public key (b) derived from the first private key. When deriving a public key from a private key, the public object (a) can be used. For example, generating the public key may involve multiplying by the public object and/or introducing some sort of noise, such as downscaling the result of the multiplication, adding a noise term, and so on. The private key and public object can be a polynomial or a matrix, such as over a finite field or ring.

The first private and public keys can be generated in a short time. For example, the latter can be done for a pre-shared key protocol, in particular if the first and second devices use some other authentication mechanism, such as an out-of-band mechanism such as certificate-based authentication, etc., to authenticate each other. The first private and public keys can also be generated for longer use. For example, the first public key may be stored in an external public key repository 302 . The public key repository 302 may also store the public object (a) or seed thereof.

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 done by direct data exchange or indirectly, for example, through the public key depository 302. A public object (a) may also be passed along with the first public key, if required. For example, an open object may be communicated by sending a seed, from which an open object (a) may be formed.

The second device 350 may include a public key receiver 360, for example configured to retrieve the first public key from the public key depository 302. This type of acquisition is suitable, for example, for public key encryption. However, the public key may also be obtained directly from the first device, possibly out of band, such as in an email. The public key can be kept for as long as it is needed for the public key cipher exchange. However, the first public key may also be received for immediate use, eg for a shared key operation, eg in which case the first public key and/or public object may be generated transiently.

The second device 350 may include a public/private key generator 365 configured to generate a second private key (s) and generate a first public key (u) derived from the second private key (s). The second public key uses the same public object that was used to generate the first public key. The first and second private keys are private to their respective devices. They can be shared between trusted parties if required, such as for backup, key escrow, etc. The public keys and the public object are not necessarily secret for security purposes; however, one or more of them may still be private to the first and second devices, if desired. For example, the first public key can only be shared with the second device, and vice versa.

The second device 350 contains a generator 370 code words. The codeword generator 370 is configured to generate a codeword in accordance with the error correction code. The error correcting code may be a linear code or a non-linear code. For example, the error correcting code may be a BCH code, a Reed-Solomon code, a Hadamard code, and the like. Multiple codes can be concatenated. Concatenated codes are error-correcting codes that are constructed from two or more less complex codes to achieve good performance at reasonable complexity. For example, a Hadamard code can be concatenated with a BCH code.

Encoded in the codeword is the data to be encapsulated. For example, the codeword may be split into a data part, such as data bits, and a parity part, such as parity bits. For example, the data to be encapsulated may be contained in data bits. One way to generate a codeword is to generate a data part and calculate parity bits from the data part. For example, a data vector with data bits may be a matrix multiplied by a parity matrix to obtain parity bits or even a complete codeword. The codeword can be obtained by combining the encapsulation data and parity bits. For example, the data part and the parity part can be concatenated, although any permutation of data bits and parity bits can be used to create a valid codeword according to the corresponding error correction code. For example, data bits and parity bits may be interleaved. It should be noted that the matching data is usually calculated on a single q-ary symbol, but the parity data is usually calculated from a plurality of bits; note that q is much greater than 2.

The codeword can be used in a variety of ways. For example, a message to be delivered from the second device 350 to the first device 300 may be encoded in the data portion of the codeword as data to be encapsulated. This encoding method is suitable, for example, for public key encryption. Public key encryption can also be obtained by encrypting the message (m) at the second device 350, eg with a symmetric key, eg generated randomly for this purpose, and encoding the symmetric encryption key in a codeword. An additional key derivation step may be used. For example, a random pre-key may be encoded in the codeword, and the encryption key may be derived from the pre-key. For example, the derivation may use a Key Derivation Function (KDF), such as a hash function. For example, in the latter case, the encrypted message may be sent from the second device to the first device, along with the required data to decrypt the data, such as a second public key, and other data, as described below.

Interestingly, the codeword is generated independently of the first private key, the first public key, the second private key, and the second public key. Because of this, the protocol has increased resistance to active attacks. An attacker has less ability to influence the public key, since he cannot influence the key by guessing the first and second private keys.

Independent generation can be obtained, for example, in the case of a message, if the message is generated from an application that does not depend on public key encryption, such as a financial or communications application, etc. Independent shaping can be obtained, for example, by random shaping. For example, the key or pre-key in the codeword may be generated independently, such as by a true random number generator, or by a pseudo-random number generator using a seed that is independent of the first and second private keys, such as being themselves randomly generated or preset, etc. For example, the codeword may be generated on the second device even before the first public key is received and/or before the second private key is generated; this also guarantees independence.

The second device 350 includes a Diffie-Hellman block 375. The Diffie-Hellman block 375 is configured to generate a second raw public key (k*) from the first public key (b) and the second private key (s). For example, the Diffie-Hellman block 375 may be configured to apply a Diffie-Hellman function to the first public key and the second private key. For example, a Diffie-Hellman function may be a multiplication or exponentiation, depending on the underlying mechanism. 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 block 325. The Diffie-Hellman block 325 is configured to generate the first raw public key (k') from the second public key (u) and the first private key (r), for example by applying the same Diffie-Hellman function. Unfortunately, for some types of Diffie-Hellman function, it can happen that the first and second keys are close to each other, although not necessarily identical. The practical likelihood that this will happen depends on the underlying Diffie-Hellman function. Some probability of different raw keys may be acceptable in most applications, however, how high this probability can be will depend on the application. However, in general, a lower probability will be preferred. The raw key may be of the same mathematical type, such as a polynomial or matrix, as the private and public keys.

The second device 350 includes a reliable bit generator 380 and a matching data generator 385 . The reliable bit generator 380 is configured to apply the reliable bits function to the second raw shared key (K*) to obtain reliable indices and reliable bits derived from said coefficients. Robust indexes indicate the coefficients of the raw public key. For example, reliable bit generator 380 can determine which coefficients in the raw key are close to the sample boundary and which are not. For example, coefficients in the raw key that are within a threshold value of the sample boundary may be discarded as unreliable. The remaining, reliable, coefficients can be indicated by reliable indices. Reliable bits can be obtained by sampling the reliable coefficients.

In case there are not enough strong coefficients left, there are several possibilities, such as terminating the protocol, restarting the protocol with a new first and/or 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, one can also select a predetermined number of coefficients, eg mu coefficients, and select the most reliable coefficients, eg the first mu most reliable coefficients.

, старших значимых битов коэффициентов. Например, количество надежных битов в пересчете на выбранные коэффициенты может быть, скажем, 1 или 2. В некоторых вариантах реализации, например, когда используют большие полиномы или матрицы, количество коэффициентов большое, что делает возможным высокую надежность, например низкое значение для

. Для других вариантов реализации, например для устройств IoT, для

могут быть использованы более крупные значения. Вычисления в конечном кольце могут быть выполнены в конечном кольце целых чисел по модулю степени 2. Преимущество последнего варианта заключается в более равномерном распределении надежных битов.One way to implement reliable bits is to take one or more, say,

, the most significant bits of the coefficients. For example, the number of reliable bits in terms of the chosen coefficients may be, say, 1 or 2. In some implementations, for example, when large polynomials or matrices are used, the number of coefficients is large, which allows high reliability, for example, a low value for

. For other implementations, such as IoT devices, for

larger values may be used. Calculations in a finite ring can be performed on a finite ring of integers modulo degree 2. The latter option has the advantage of a more even distribution of good bits.

The match data generator 385 is configured to generate match data (h) for specified raw shared key coefficients. The negotiation data contains information to reduce differences between the first and second raw keys outputted on the first and second devices. For example, the use of matching data may result in a decrease in the difference, eg, Lee distance, between the raw key ratio on the first and second devices, and thereby increase the likelihood of both devices generating the same reliable bit. Both the parity bits in the codeword and the matching data serve to reduce noise, however, the parity bits are calculated on a plurality of data bits, while the matching data is calculated on coefficients in the raw common key. The matching data further enhances the reliability of the reliable bits.

, битов коэффициентов, которые следуют за битами, взятыми в качестве надежных битов. Например, это могут быть

битов, которые следуют за

битами по значимости. Например, количество битов согласования в пересчете на выбранные коэффициенты может быть, скажем, 1 или 2. Преимущество меньшего количества битов согласования заключается в уменьшении служебных данных связи. Хотя возможно большее количество битов согласования..One way to implement match data is to take one or more, say,

, coefficient bits that follow the bits taken as reliable bits. For example, these may be

bits that follow

bits in order of importance. For example, the number of justification bits in terms of selected coefficients may be, say, 1 or 2. The advantage of having fewer justification bits is to reduce the communication overhead. Although more matching bits are possible..

The second device 350 may include an encapsulator 390. The encapsulator 390 is configured to encapsulate the codeword using reliable bits by applying an encapsulation function such as XOR. The encapsulation may be a one-time padding encapsulation. In an embodiment, the encapsulation function obtains perfect protection in the sense that the information in the codeword that can be obtained from the encapsulated codeword is null without knowledge of the reliable bits. For example, on one of the other encapsulation functions described herein, the XOR function can be used.

It should be noted that encapsulation is applied to the whole codeword containing data bits and parity bits, and not just to parity bits. In addition, encapsulation is applied to generated data, such as a message, key, pre-key, etc., and not to data derived from one or more of the first or second public or private keys.

The second device is configured to send the second public key (u), handshake data (h), encapsulated data (c), and trusted indices to the first device. The transmission may be in response to receiving the first public key, such as in the case of a shared key, or not, such as in the case of public key encryption.

The first device 300 is configured to receive from the second device a second public key (u), handshake data (h) and encapsulated data (c), and trusted indices. The first device 300 includes a matcher 335 configured to apply the match data (h) in the match function to the coefficients in the first raw shared key (k') indicated by safe indices (safe_bits) to obtain safe bits (k). For example, a coefficient indicated as reliable may be matched using the matching bits and then selected to obtain a reliable bit.

The first device 300 includes a decapsulation unit 340 configured to decapsulate the encapsulated data (c) into a near-codeword using reliable bits. The reason why the codeword of the second device cannot be obtained directly is that even with reliable bits and negotiation, there may still be differences between the raw keys that are not resolved. The first apparatus 300 includes an error corrector 320 that is configured to apply an error correction function to a near-codeword to obtain a codeword.

Finally, the codeword may be decoded, for example, to obtain the data part, and thereby obtain the message (m), key (K), and pre-key. In the first case, some action may be taken based on the message, for example, the message may be displayed, for example, in a communication application. In the second case, the key can be used for further secure data exchanges, and so on. In the third case, a derivation function can be applied to the pre-shared key to obtain a shared key.

и

. Запишем коэффициенты в виде пяти битовых последовательностей со старшими значащими битами слева. Например, в варианте реализации второе устройство может отбросить коэффициенты 00000, 00001, 01110, 01111, 10000, 10001, 11110 и 11111, поскольку лишь небольшое сложение с такими коэффициентами или вычитание из них приведет к смене на противоположный старшего значимого бита.Below is a small but illustrative example for reliability and consistency. Let

and

. We write the coefficients as five bit sequences with the most significant bits on the left. For example, in an embodiment, the second device may discard the coefficients 00000, 00001, 01110, 01111, 10000, 10001, 11110, and 11111, since only a slight addition to or subtraction from such coefficients will reverse the most significant bit.

The coefficients 00010, 00011, ..., 01101 and 10010, 10011, ..., 11101 will not be discarded. The coefficients in the first list will give a reliable bit of 0, and the coefficients in the last list will give a reliable bit of 1. The second bit of these sequences can be taken as the matching data . The match data of the selected coefficients is transmitted to the other device, and the reliable bits are not transmitted.

After the first device calculates its raw key, it selects the coefficients according to the coefficients indicated by the first device. Suppose, for example, that the coefficient in the raw key of the first device is 01101, and that the matching data for this coefficient is 0. Since the second bit of the coefficient on the first device is not 0, this indicates to the first device that an error has been made. The closest value to the selected factor 01101 with a second bit of 0 that was not discarded is 10010. Note that 00111 also has a second bit of 0, but is farther away from the selected factor 01101. Therefore, the first device will choose 1 as the safe bit for the selected factor .

It should be noted that if the noise was large, this correction may not be correct; it can be assumed that the second device had a factor of 00111. In this case, the wrong reliable bit is selected. Interestingly, even with moderate amounts of matching data, errors of this type are rare. This means that instead of increasing the amount of matching data to correct the remaining number of errors, it is more efficient to rely on error correction codes. Minimizing the Lee distance can be done by simply trying out the potentially changed coefficients while increasing the Lee distance until a match is found. More advanced algorithms are possible, such as those described in the art.

There is an interesting synergy between reliability and consistency. It may happen that the nearest changed coefficient with correct matching data will be discarded by the second cryptographic device. The nearest modified coefficient with correct matching data and an additional constraint that has not been discarded by the second cryptographic device may have a different reliable bit. Taking this into account further improves the performance of the matching bits. For example, continuing with the above example, let the second device receive a factor of 01100 with matching data of 0. The nearest changed factor would be 10000, but the nearest factor that was not discarded is 00111. Accordingly, the first device would recover a safe bit of 0, not 1.

On FIG. 11a schematically shows an example of a cryptographic method 400 in accordance with an embodiment. Method 400 is configured to share a codeword. Method 400 includes:

- exchange (410) data with the first cryptographic device (10),

- receiving (420) the first public key (b) from the first cryptographic device,

- generating (430) the second private key (s) and generating the second public key (u) from the second private key (s),

- generating (440) a codeword (K||parity) in accordance with the error correction code, and

- generating (450) a second public key (k*) from the first public key (b) and the second private key (s),

- applying (460) the function of reliable bits (shared_bits) to the second raw shared key (k*) to obtain reliable indices indicating the coefficients of the raw shared key, and reliable bits derived from the indicated coefficients,

generating (470) matching data (h) for said raw shared key coefficients, wherein the matching data contains information to reduce differences between the first and second raw keys outputted on the first and second devices,

encapsulating (480) the codeword with reliable bits by applying the encapsulation function to obtain encapsulated data (c),

- transmitting (490) the second public key (u), agreement data (h), encapsulated data (c) and trusted indexes to the first device.

On FIG. 11b schematically shows an example of a cryptographic method 500 in accordance with an implementation. Method 500 is configured to share a codeword, wherein method 500 includes:

- exchange (510) data with the second cryptographic device (20),

- receiving (520) the first private key (r) and the first public key (b) derived from the first private key, transmitting the first public key (b) to the second device,

- receiving (530) from the second device the second public key (u), agreement data (h) and encapsulated data (c) and reliable indexes,

- generating (540) the first raw public key (k') from the second public key (u) and the first private key (r),

applying (550) the matching data (h) in the matching function to the coefficients in the first raw shared key (k') indicated by the safe indexes (safe_bits) to obtain safe bits (k),

- decapsulation (560) of the encapsulated data (c) to obtain an almost codeword using reliable bits,

- applying (570) the error correction function to the near-codeword to obtain the codeword.

The codeword in method 400 or 500 may be used to convey a message or a key used for an encryption method, such as a public key encryption method. The code word can be used to generate a shared key.

As one of skill in the art will appreciate, many different ways of performing these methods are possible. For example, the steps may be performed in the specified order, but the order of the steps may also change, or some steps may be performed in parallel. In addition, other method steps may be introduced between the steps. The steps introduced may represent improvements to the method, such as those described herein, or may not be relevant to the method. For example, some parts may be executed, at least in part, in parallel. In addition, this part may not be fully completed before the start of the next stage.

Embodiments of the method may be executed using software that contains instructions for causing the processor system to execute the method. The software may contain only those steps that are undertaken by the system component. The software may be stored on suitable storage media such as a hard disk, floppy disk, memory, optical disk, etc. The software may be sent as a signal over or over the wire, or using a data network such as the Internet. The software may be available for download and/or remote use on a server. Embodiments of the method may be executed using a bitstream configured to configure programmable logic, such as a field programmable gate array (FPGA), to implement the method.

It is understood that the invention also extends to computer programs, in particular to computer programs on or in a carrier capable of practicing the invention. The program may be in source code, object code, intermediate source code, and object code, such as partially compiled form, or any other form suitable for use in carrying out an embodiment of the method. An embodiment relating to a computer program product comprises executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or stored in one or more files, which may be linked statically or dynamically. Another embodiment related to a computer program product comprises executable instructions corresponding to each of the means of at least one of the described systems and/or products.

On FIG. 8a shows a computer-readable medium 1000 having a writable portion 1010 comprising a computer program 1020, the computer program 1020 including instructions for causing the processing system to execute a pre-shared key generation method, or a public key encryption method, or a public key decryption method, in accordance with with implementation. The computer program 1020 may be implemented on the computer readable medium 1000 in the form of physical marks or by magnetizing the computer readable medium 1000. However, any other suitable implementation is possible. Further, it will be understood that although the computer readable medium 1000 is shown here in the form of an optical disc, the computer readable medium 1000 may be any suitable computer readable medium such as a hard disk, solid state memory, flash memory, etc., and may be configured without being able to recording or recordable. The computer program 1020 includes instructions for causing the processor system to perform a pre-shared key generation method, or a public key encryption method, or a public key decryption method.

On FIG. 8b shows a schematic representation of a processor system 1140 in accordance with an embodiment of a device, such as a device for deriving a shared key, or a device for encrypting or decrypting a public key. The processor system includes one or more integrated circuits 1110. The architecture of one or more integrated circuits 1110 is shown schematically in FIG. 8b. Circuitry 1110 includes a processing unit 1120, such as a CPU, for executing computer program components to implement the method of the embodiment and/or implement modules or blocks thereof. Circuit 1110 includes memory 1122 for storing program code, data, and so on. Portion of memory 1122 may be read-only. Circuitry 1110 may include a coupling element 1126, such as an antenna, connectors, or both, and the like. Circuit 1110 may include an ASIC 1124 to perform some or all of the processing defined in the method. The processor 1120, memory 1122, ASIC 1124, and coupler 1126 may be connected to each other via an interconnect 1130, say, a bus. Processor system 1110 may be configured to communicate contactlessly and contactlessly using an antenna and/or connectors, respectively.

For example, in an embodiment, the processor system 1140, such as a shared key generator or a public key encryption or decryption device, may comprise a processor circuit and a memory circuit, the processor being configured to execute software stored in the memory circuit. For example, the processor scheme may be an Intel Core i7 processor, ARM Cortex-R8, etc. In an embodiment, the processor circuitry may be an ARM Cortex M0. The memory circuitry may be a ROM circuitry or non-volatile memory circuitry such as flash memory. The memory circuit may be a volatile memory circuit such as SRAM. In the latter case, the device may comprise a non-volatile software interface, such as a hard drive, a network interface, etc., configured to be provided with software.

The following numbered paragraphs are not claims, but contain proposed implementation options. Applicant hereby acknowledges that such claims and/or combinations of such claims and/or features taken from the description or claims may be subject to new claims, for example, during litigation of this application or any further application received from her.

1. The second cryptographic device (20), containing:

- a communication interface configured to exchange data with the first cryptographic device (10),

- a processor configured to:

- obtaining the first public key (b) for the first cryptographic device,

- generating a second private key (s), a code word in accordance with the error correction code and generating a second public key (u) from the second private key (s),

- generating a second raw public key (k*) from the first public key (b) and the second private key (s),

- applying the reliable bits function to the second raw public key (k*) to obtain reliable indices indicating the coefficients of the raw public key and reliable bits derived from the indicated coefficients,

generating matching data (h) for said raw shared key coefficients, wherein the matching data contains information to reduce differences between the first and second raw keys output on the first and second devices,

- encapsulating the codeword using reliable bits by applying the encapsulation function to obtain encapsulated data (c),

- transmitting the second public key (u), handshake data (h), encapsulated data (c) and trusted indices to the first device.

2. The first cryptographic device (10), containing:

- a communication interface configured to exchange data with the second cryptographic device (20),

- a processor configured to:

- obtaining the first private key (r) and the first public key (b) derived from the first private key, transmitting the first public key (b) to the second device,

- receiving from the second device the second public key (u), agreement data (h) and encapsulated data (c) and reliable indexes,

- generating the first raw public key (k') from the second public key (u) and the first private key (r),

- applying the matching data (h) in the matching function to the coefficients in the first raw shared key (k') indicated by the reliable indices, obtaining reliable bits (k),

- decapsulation of the encapsulated data (c) using reliable bits (k) to obtain an almost code word,

- applying the error correction function to the near-codeword to obtain the codeword.

3. A cryptographic method (400) for sharing a code word, including:

- exchange (410) data with the first cryptographic device (10),

- receiving (420) the first public key (b) for the first cryptographic device,

- generating (430) the second private key (s) and generating the second public key (u) from the second private key (s),

- generating (440) a code word in accordance with the error correction code, and

- generating (450) a second raw public key (k*) from the first public key (b) and the second private key (s),

- applying (460) the function of good bits to the second raw public key (k*) to obtain good indices indicating the coefficients of the raw common key and good bits derived from said coefficients,

generating (470) matching data (h) for said raw shared key coefficients, wherein the matching data contains information to reduce differences between the first and second raw keys outputted on the first and second devices,

encapsulating (480) the codeword using reliable bits by applying the encapsulation function to obtain encapsulated data (c),

- transmitting (490) the second public key (u), agreement data (h), encapsulated data (c) and trusted indexes to the first device.

4. A cryptographic method (500) for sharing a code word, including:

- exchange (510) data with the second cryptographic device (20),

- receiving (520) the first private key (r) and the first public key (b) derived from the first private key, transmitting the first public key (b) to the second device,

- receiving (530) from the second device the second public key (u), agreement data (h) and encapsulated data (c) and reliable indexes,

- generating (540) the first raw public key (k') from the second public key (u) and the first private key (r),

applying (550) the matching data (h) in the matching function to the coefficients in the first raw common key (k') indicated by the reliable indexes to obtain reliable bits (k),

- decapsulation (560) encapsulated data (c) using reliable bits to obtain almost a code word,

- applying (570) the error correction function to the near-codeword to obtain the codeword.

It should be noted that the foregoing embodiments are illustrative, and not limiting, of the present invention, and that those skilled in the art are able to develop many alternative implementations.

In the claims, any position numbers given in parentheses should not be construed as limiting the claim. The use of the verb "comprises/includes" and its conjugations does not preclude the presence of other elements or steps other than those specified in a claim. The singular grammatical means used with an element does not preclude the presence of a plurality of such elements. The present invention can be implemented by means of equipment containing several different elements, and by means of an appropriately programmed computer. In a device-specific clause listing multiple features, some of those features may be implemented by the same piece of equipment. The mere fact that certain measures are set forth in mutually distinct dependent claims does not mean that a combination of these measures cannot be used effectively.

In the claims, references in parentheses refer to reference numbers in the drawings showing exemplary embodiments or to formulas in embodiments to make the claim more understandable. These references are not to be construed as limiting the claim.

APPENDIX A

Schematic mathematical descriptions of implementation examples.

The algorithms describe a public-key CPAPKE encryption scheme that is INDCPA-resistant (Indistinguishability under chosen-plaintext attack). CPAKEM can be built from CPAPKE as a black box, and the INDCCA2 secure key encapsulation mechanism CCAKEM can be built from CPAPKE, for example by applying the Fujisaki-Okamoto transformation.

CPAPKE uses public parameters, which are integers n; q; p; bh; κ; μ , and algorithms for key generation, encryption and decryption. Ds is a distribution from which the secret key coefficients can be extracted and is parameterized by η. For example, if Ds is a distribution of sparse ternary vectors, then η represents the Hamming weight of the vectors. fr is a deterministic function that, given a seed ρ, selects a fresh secret key from the distribution Ds . Acts on a polynomial of degree at most n . The SafeBits function selects μ≤ n coefficients that result in the minimum overall decryption failure probability, according to positive positions/indices, for example, in a vector representing μ of selectable coefficients.

CPAKEM is a passive secret key encapsulation mechanism built using CPAPKE as a black box. It reuses the key generation algorithm of the CPAPKE scheme and additionally contains the encapsulation and decapsulation algorithm, the parameters of the previous scheme, and the hash function H of * bits to κ bits.

CCAKEM can be obtained by applying the Fujisaki-Okamoto transform on CPAPKE and can use hash functions H as defined in CPAKEM and optionally hash function G of * bits times 3 κ bits.

Claims (57)

1. Cryptographic device (20) containing: communication interface configured to exchange data with the first cryptographic device (10), a processor configured to: receiving the first public key (b) for the first cryptographic device from the first cryptographic device, wherein the first public key (b) is generated from the short-term generated first private key, generating a second private key (s), a code word in accordance with the error correction code at least partially randomly; a private key and a second public key, forming the second raw public key (k*) from the first public key (b) and the second private key (s), while the first and second public keys, the second private key, and the second raw public key are a matrix over a finite field or ring, with the second public key derived from the second private key by noise multiplication by the overall matrix (a), encapsulating the codeword using the second raw public key by applying the encapsulation function to obtain encapsulated data (c), deriving a common cryptographic key from at least the data (K) encoded in the codeword, transmitting the second public key (u) and the encapsulated data (c) to the first device. 2. Cryptographic device according to claim 1, in which: the processor is configured to: obtaining a codeword by obtaining data to be encapsulated and generating parity bits for the encapsulation data, the codeword being obtained by combining data to encapsulate and parity bits. 3. Cryptographic device (10), containing: communication interface configured to exchange data with the second cryptographic device (20), a processor configured to: briefly generating a first private key (r) to generate a shared key, deriving the first public key (b) from the first private key, and transmitting the first public key (b) to the second device, receiving from the second device the second public key (u) and encapsulated data (c), generating the first raw public key (k') from the second public key (u) and the first private key (r), while: the first and second public keys, the first private key, and the raw key are a matrix over a finite field or ring, where the first public key is obtained from the first private key by noisy multiplication by the common matrix (a), decapsulating the encapsulated data (c) using the first raw public key to obtain an almost codeword, regardless of the first private key, the first public key and the second public key, applying an error correction function to an almost codeword to obtain a codeword, and deriving a common cryptographic key from at least the data (K) encoded in the code word. 4. A cryptographic device according to any one of the preceding claims, configured for a public key encryption protocol, wherein the message (m) is encrypted with a common symmetric key derived from at least data (K) encoded in the codeword, the encrypted message being sent along with second public key (u) from the second device to the first device. 5. A cryptographic device according to any one of the preceding claims, wherein the raw public key is obtained by multiplying the received public key by the private key. 6. A cryptographic device according to any one of the preceding claims, wherein the handshake data is obtained from at least a plurality of raw key coefficients, wherein the handshake data is received, sent, received and/or applied for less than all of the raw key coefficients. 7. Cryptographic device according to any one of paragraphs. 1 or 2 or 4-6 depending on claim 1 or 2, in which the processor of the second device is configured to applying the reliable bits function to the second raw public key to obtain reliable indices indicating coefficients of the raw public key and reliable bits derived from said coefficients, generating matching data for said raw shared key coefficients, wherein the matching data contains information to reduce differences between the first and second raw keys output on the first and second devices, the codeword encapsulating using reliable bits, and transmitting the matching data and reliable indices to the first device . 8. Cryptographic device according to claim. 3 or according to any one of paragraphs. 4-6 depending on claim 3, in which the processor of the cryptographic device is configured to receiving matching data and reliable indices from the second device, applying the matching data in the matching function to the coefficients in the first raw shared key indicated by the reliable indices to obtain reliable bits, wherein decapsulation of the encapsulated data uses reliable bits. 9. Cryptographic device according to claim 8, in which: the reliable bits are one or more most significant bits of the specified coefficients, the matching data for the specified coefficients is one or more bits of the specified coefficients following the reliable bits in significance, while it is possible to discard one or more least significant bits of the specified coefficients. 10. The cryptographic device according to claim 8 or 9, in which the processor is configured to select the coefficients in the raw key indicated by reliable indexes, replace the selected coefficients with modified coefficients consistent with the corresponding matching data and minimize the Lee distance between the selected coefficients and the modified coefficients, with obtaining reliable bits in the form of one or more most significant bits of the modified coefficients. 11. The cryptographic device of claim 10, wherein the processor is configured to determine modified coefficients consistent with corresponding matching data that has not been discarded by the second device and which minimizes the Lee distance between the selected coefficient and the modified coefficient. 12. A cryptographic method (400) for sharing a code word, including: exchange (410) data with the first cryptographic device (10), receiving (420) the first public key (b) for the first cryptographic device from the first cryptographic device, wherein the first public key (b) is generated from the short-term generated first private key, generating (430) a second private key (s) and generating a second public key (u) from the second private key (s), generating (440) a codeword in accordance with the error correction code at least partially randomly, wherein the codeword is generated independently of the first public key, the second private key, and the second public key, and generating (450) a second raw public key (k*) from the first public key (b) and the second private key (s), wherein the first and second public keys, the second private key, and the second raw public key are a matrix over a finite field or ring, the second public key being derived from the second private key by noise multiplication by the overall matrix (a), encapsulating (480) the codeword using the second raw public key by applying the encapsulation function to obtain encapsulated data (c), deriving a common cryptographic key from at least the data (K) encoded in the code word, transmitting (490) the second public key (u) and the encapsulated data (c) to the first device. 13. A cryptographic method (500) for sharing a code word, including: exchange (510) data with the second cryptographic device (20), briefly generating a first private key (r) to generate a shared key, deriving the first public key (b) from the first private key, and transmitting the first public key (b) to the second device, receiving (530) from the second device the second public key (u) and encapsulated data (c), generating (540) the first raw public key (k') from the second public key (u) and the first private key (r), wherein the first and second public keys, the first private key, and the raw key are a matrix over a finite field or ring, the first public key being derived from the first private key by noise multiplication by the common matrix (a), decapsulating (560) the encapsulated data (c) using the first raw public key to obtain an almost codeword regardless of the first private key, the first public key and the second public key, applying (570) an error correction function to a near-codeword to obtain a codeword, and deriving a common cryptographic key from at least the data (K) encoded in the codeword. 14. A computer-readable medium (1000) containing transient or non-transitory data (1020) representing instructions whose execution by the processor system causes it to perform the method of claim 12 or 13.

Images