Public / private key system with reduced public key size

Abstract

Some embodiments are directed to a public key encryption device (20) and a private key decryption device (10). The public key encryption device is configured to calculate a second public key matrix (u) having fewer matrix elements than a first public key matrix (b) of the private key decryption device. This reduces computational requirements and bandwidth requirements on the public key encryption device side.

Description

Technical Field

[0001] The present invention relates to a public key encryption device, a private key decryption device, a public key encryption method, a private key decryption method and a computer-readable medium. Background Art

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

[0003] While public keys can be widely distributed, private keys are typically known only to a limited number of parties, for example, only to their owner. Public keys can be used to encrypt messages that can only be decrypted with the private key. In a public-key cryptosystem, anyone can encrypt a message using the recipient's public key. Encrypted messages can only be decrypted using the recipient's private key. Finding a private key from its corresponding public key is computationally impractical. A public and private key are called a key pair.

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

[0005] Quantum computers pose a significant threat to modern cryptography. Universal quantum computers could break the two most widely adopted public-key cryptosystems: RSA and elliptic curve cryptography (ECC). Lattice-based cryptography could be an alternative to quantum computers. Unfortunately, lattice computing requires large public keys to ensure its security.

[0006] Joppe Bos et al., "Frodo: Take off the ring! Practical, Quantum-Secure KeyExchange from LWE" (International Association for Cryptologic Research, Vol. 20170227:170204, February 27, 2017, pp. 1-26), develop a secure, practical key exchange protocol that can be used to secure internet traffic in the presence of anticipated quantum adversaries. The key exchange protocol developed in the article, called "Frodo," combines an efficiently sampled noise distribution with efficient and dynamic generation of public parameters, where the LWE public matrix A is generated for each key exchange from a small random seed.

[0007] European patent application EP 3364596 A1 (Royal Philips) discloses a first electronic network node configured for a key exchange (KEX) protocol. The first network node is configured to: obtain a shared matrix (A) shared with a second network node, wherein entries in the shared matrix A are selected modulo a first modulus q; generate a private key matrix (SI), wherein the absolute values ​​of entries in the private key matrix are bounded by (one or more) boundaries; and generate a public key matrix (PI) by calculating a matrix product between the shared matrix (A) and the private key matrix (SI) modulo the first modulus q and reducing the entries in the matrix product to a second modulus (p). Summary of the Invention

[0008] These and other problems are addressed by the embodiments described herein. A public key encryption device and a private key decryption device are provided. Using the public key encryption device, a transmission key can be transferred to the private key decryption device. The transmission key can be used to encrypt a message. Thus, access to the public key allows encryption of a message, but decryption of the encrypted message requires access to the private key.

[0009] The public key encryption device may be configured to obtain a first public key matrix associated with the private key decryption device and generate a second public key matrix having fewer matrix elements than the first public key matrix.

[0010] Because the second public key matrix has fewer matrix elements than the first public key matrix, overhead (e.g., overhead required to send the transmission key) during the encryption phase (e.g., when encrypting a message) is reduced, particularly relative to the registration phase (e.g., where the first public key is obtained via a public key encryption device). In particular, the first public key can be obtained in a different manner than the second public key is transmitted; in particular, the first public key can be pre-distributed, for example, with software (e.g., with browser software). This is particularly advantageous because bandwidth is more readily available during pre-distribution than when public key encryption is required.

[0011] Various embodiments can be used for various purposes. As a first example, temporary key exchanges can be used, for example, over the Internet. Embodiments can be used to minimize the total bandwidth overhead (e.g., (public key + ciphertext)). Note that this equation is significantly affected by the fact that the public key may or may not already be available. As another example, the ciphertext can be minimized, for example, for use in messaging applications such as email. Even if minimizing the size of the ciphertext implies a longer public key, this is not a concern since the public key is only sent once.

[0012] Before transmitting the transport key, the two devices negotiate which public key to use. For example, if the key is pre-assigned, the public key encryption device may prefer to use the pre-assigned key. For example, if the public key is not pre-assigned, the public key encryption device may prefer to obtain a smaller public key. If two public keys are available, the public key encryption device may prefer the larger key because this reduces the bandwidth required to transmit the encrypted message.

[0013] Interestingly, the size of the second public key can be determined at the time of encryption (e.g., during the encryption phase) rather than during, for example, the registration phase. This has the advantage that the size of the second public key can be selected based on the size of the transport key to be transmitted along with the second public key. For example, for high-security applications, the transport key may have more bits than for lower-security applications. In the latter case, the overhead of transmitting the transport key may be lower.

[0014] In an embodiment, the second public key matrix has a first system dimension and a second dimension, the first public key matrix has a first system dimension and a second dimension, and the second dimension of the second public key matrix is ​​smaller than the second dimension of the first public key matrix. In particular, the second dimension of the second public key matrix may be 1; the second dimension of the first public key matrix may be greater than 1.

[0015] In an embodiment, a high noise lattice problem is combined with parity bits to obtain a second public key that is less than 1.5 kB, thereby avoiding packet fragmentation when such an embodiment is used in a computer network.

[0016] Public key encryption (PKE) can be based on unstructured lattice problems, for example, such as in learning with errors or in learning with rounding problems or in a combination thereof. Embodiments can be optimized to ensure that the decryptor generates minimal bandwidth and computational overhead, but this will be at the expense of requiring a larger public key for the decryptor. Nevertheless, the public key only needs to be communicated once and stored. Not only can the bandwidth required for encryption be reduced, but encryption efficiency can also be improved because encryption speed will be faster and the ciphertext will be smaller. Specifically, the ciphertext of the non-ring configuration can be less than 2000B.

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

[0018] The devices and methods according to the embodiments can be widely used in practical applications. Such practical applications include many cryptographic protocols, such as messaging applications, sensor networks, data communications, financial applications, etc.

[0019] Embodiments of the method may be implemented on a computer as a computer-implemented method, or implemented in dedicated hardware, or a combination of the two. Executable code for embodiments of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, and the like. Preferably, the computer program product includes non-transitory program code stored on a computer-readable medium for performing embodiments of the method when the program product is executed on a computer.

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

[0021] Another aspect of the present invention provides a method of making a computer program available for download. This aspect is used when the computer program is uploaded to, for example, Apple's App store, Google's Play store, or Microsoft's Windows store and can be downloaded from such stores. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0023] Figure 1a Schematically illustrating an example of an embodiment of a private key decryption device 100,

[0024] Figure 1b Schematically illustrating an example of an embodiment of a public key encryption device 200,

[0025] Figure 1c Schematically illustrating an example of an embodiment of a cryptographic system 101,

[0026] Figure 2a Schematically shows an example of public key encryption and private key decryption,

[0027] Figure 2b Schematically shows an example of public key encryption and private key decryption,

[0028] Figure 2c An example of a handshake is schematically shown,

[0029] Figure 3 Schematically shows an example of public key encryption and private key decryption,

[0030] Figure 4 Schematically shows an example of public key encryption and private key decryption,

[0031] Figure 5 schematically illustrates an example of a cryptographic system according to an embodiment,

[0032] Figure 6a Schematically illustrating an example of a public key encryption method according to an embodiment,

[0033] Figure 6b Schematically illustrates an example of a private key decryption method according to an embodiment,

[0034] Figure 7a schematically illustrates a computer-readable medium having a writable portion comprising a computer program according to an embodiment,

[0035] Figure 7b Schematically shown is a representation of a processor system according to an embodiment.

[0036] List of reference numerals 1a-5, 7a-7b:

[0037] 10 Private key decryption device

[0038] 20 Public Key Cryptography Devices

[0039] 31 Registration Phase

[0040] 32 Encryption Phase

[0041] 33 Decryption Phase

[0042] 11-16 News

[0043] 100 Private key decryption device

[0044] 130 Communication Interface

[0045] 191 Computer Networks

[0046] 192 Storage Interface

[0047] 194 processors

[0048] 196 Memory

[0049] 200 Public Key Cryptography Device

[0050] 230 Communication Interface

[0051] 292 Storage Interface

[0052] 294 processors

[0053] 296 memory

[0054] 300 Private key decryption device

[0055] 301 Cryptography System

[0056] 302 Public Key Repository

[0057] 305 Communication Interface

[0058] 315 Public / Private Key Generator

[0059] 320 Error Corrector

[0060] 325 Diffie-Hellman units

[0061] 335 Reconciliation Unit

[0062] 340 Decapsulation Unit

[0063] 350 Public Key Cryptography Device

[0064] 355 communication interface

[0065] 360 Public Key Obtainer

[0066] 365 Public / Private Key Generator

[0067] 370 Codeword Generator

[0068] 375 Diffie-Hellman units

[0069] 380 Reliable Bit Generator

[0070] 385 Reconciliation Data Generator

[0071] 390 package units

[0072] 1000 Computer readable medium

[0073] 1010 Writable part

[0074] 1020 Computer Programs

[0075] 1110(s) integrated circuit(s)

[0076] 1120 processing units

[0077] 1122 Memory

[0078] 1124 ASIC

[0079] 1126 Communication Components

[0080] 1130 Interconnect

[0081] 1140 processor system DETAILED DESCRIPTION

[0082] While the invention is susceptible of embodiment in many different forms, one or more specific embodiments are shown in the drawings and will be described in detail herein, it being understood that this disclosure is considered to be an exemplification of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0083] Hereinafter, for ease of understanding, the elements of the embodiment are described in operation. However, it is obvious that the various elements are arranged to perform the functions described by them.

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

[0085] Figure 1a An example of embodiment of a private key decryption device 100 is schematically shown. Figure 1b Schematically, an example of an embodiment of a public key encryption device 200 is shown. A private key decryption device may also be referred to as a first device or a first cryptographic device. A public key encryption device may also be referred to as a second device or a second cryptographic device. Figure 1c An example embodiment of a cryptographic system 101 is schematically shown, comprising a private key decryption device 100 and a public key encryption device 200. The private key decryption device 100 and the public key encryption device 200 may each include one or more of the following: a storage interface 192, 292, a processor 194, 294, and a memory 196, 296. The private key decryption device 100 is configured to generate a public / private key pair. The public key and the private key comprise a public key matrix and a private key matrix, respectively. The public key encryption device 200 is configured to use the public key matrix and use it to enable a transmission key to be transmitted to the private key decryption device. For example, the transmission key can be used as a key, typically a symmetric key, to encrypt and later decrypt a message, which is then transmitted from the public key encryption device to the private key decryption device. The private key decryption device is configured to use the private key matrix to obtain the same transmission key. Alternatively, the transport key can be used as an input for additional key negotiation, e.g., the transport key can be combined with one or more additional key inputs to derive a final key, e.g., by using a key derivation function that employs the transport key and the additional key inputs. The additional key inputs can include a derived additional transport key obtained from a protocol in which a public key encryption device and a private key decryption device switch positions, thereby playing opposite roles in the various protocols described herein.

[0086] The private key decryption device 100 and the public key encryption device 200 (e.g., various devices of the system 101) can communicate with each other via a computer network 191. The computer network can be the Internet, an intranet, a LAN, a WLAN, etc. The computer network 191 can be the Internet. The computer network can be fully or partially wired and / or fully or partially wireless. For example, the computer network can include an Ethernet connection. For example, the computer network can include a wireless connection, such as Wi-Fi, ZigBee, etc. These devices include a connection interface that is arranged to communicate with other devices of the system 101 as needed. For example, the connection interface can include a connector, such as a wired connector (e.g., an Ethernet connector) or a wireless connector (e.g., an antenna, such as a Wi-Fi, 4G, or 5G antenna). For example, the private key decryption device 100 and the public key encryption device 200 can include communication interfaces 130 and 230, respectively. The computer network 191 can include other elements, such as routers, hubs, etc.

[0087] The execution of the private key decryption device 100 and the public key encryption device 200 may be implemented in a processor (e.g., a processor circuit), examples of which are shown herein. The private key decryption device 100 (particularly the processor of the private key decryption device 100) may be implemented as follows: Figures 2a-2c 、 Figure 3 and Figure 4 The functions of the private key decryption device 10 shown in the figures are shown. The public key encryption device 200 (particularly the processor of the public key encryption device 200) can implement the functions of the public key encryption device 20 in these figures. For example, these functions can be implemented in whole or in part as computer instructions stored at the device 100 or 200, such as computer instructions stored in the electronic memory of the device and executable by the microprocessor of the device. In a hybrid embodiment, the functional units are partially implemented in hardware (for example, as a coprocessor, such as a cryptographic coprocessor) and partially implemented in software stored and executed on the device 100 or 200.

[0088] 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, for example, as an interface to memory included in the device (e.g., memory 196 or 296, respectively). The storage interface may also interface with offline (e.g., non-local) storage (e.g., cloud storage), for example, with storage such as memory or a drive located in another device. If cloud storage is used, the device may also include local storage, such as memory. For example, the memory may be used to store computer programming instructions, temporarily store files, etc.

[0089] In various embodiments of devices 100 and 200, a communication interface can be selected from a variety of alternatives. For example, the interface can be a network interface to a local area network or a wide area network (e.g., the Internet), a storage interface to an internal or external data storage device, an application programming interface (API), etc. In an embodiment, a key encryption device and a private key decryption device are implemented in the same device. This can facilitate both encryption and decryption of messages. For example, the communication interface can be a storage interface, in which case the device can be used to store messages in encrypted form and subsequently retrieve and decrypt the messages.

[0090] Devices 100 and 200 may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, a display, a touch screen, etc. The user interface may be arranged to accommodate user interactions for initiating a key negotiation protocol, responding to a key negotiation protocol, sending a message encrypted using a public key, decrypting a message using a public key, etc.

[0091] The storage device may be implemented as an electronic memory (e.g., flash memory) or a magnetic memory (e.g., a hard disk), etc. The storage device may include a plurality of separate memories that together constitute the storage device. The storage device may also be a temporary memory, e.g., RAM.

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

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

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

[0095] Figure 2a Schematically shows an example of public key encryption and private key decryption. The public key encryption side is performed by the public key encryption device 20. The private key decryption side is performed by the private key decryption device 10. As described above, Figure 1a-4 The protocol can be executed by the public key encryption device 200 and the private key decryption device 100.

[0096] Figure 2a-4 The symbols in are as follows:

[0097] a represents a common matrix, e.g., a matrix with elements that are integers or rings, fields, etc. Elements can be integers modulo a modulus (e.g., a power of 2). Elements can be polynomials modulo a modulus (e.g., a power of 2) and a polynomial. Matrix a is typically a square d×d matrix. A matrix modulo a modulus is called an acyclic configuration. A matrix with polynomial entries modulo a polynomial and a modulus is called a modular configuration.

[0098] r and s represent the private key matrices of the private key decryption device and the public key encryption device, respectively.

[0099] b and u represent the public key matrices of the private key decryption device and the public key encryption device, and b and u are illustrated as the product a*r or the product a*s.

[0100] The operation * represents a one-way function of the underlying problem. The asterisk (*) operation derives a new mathematical object (e.g., a new matrix) from two underlying matrices, while introducing some noise. The noise can be introduced explicitly, for example, by adding a noise element, or implicitly, for example, by rounding. Examples of the asterisk operation can be found in (R)LWE or (R)LWR or their modular versions. For example, a*r can represent ((A*r(mod q)),p,q), as is the case in LWR. This means r multiplied by the product of the square matrix A modulo q. The result is then rounded with integers p and q by performing p / q(A*r(mod q), where p <q。

[0101] c represents the encapsulated transmission key K

[0102] encapsulate(k,K) encapsulates the transmission key K with k. For example, if k is in Z_q, then K can also be represented in Z_q. If k is in Z_2, then this may be XOR. Encapsulation can be performed element by element, for example, interpreting k and K as the following matrix:

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

[0104] For example, the wrapping function can mask the transmission key K with the key k so that errors in k have a limited (e.g., linear) effect on m. For example, bits in the transmission key K can be mapped to Z_q by multiplying the elements of K by the elements of Z_q; if q is even, q / 2 is a good choice. Next, the elements of the key k (which may also be elements of Z_q) are added to the mapped elements of K.

[0105] decapsulate(k,c) decapsulates the ciphertext c using the key k that returns the bit string.

[0106] References:

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

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

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

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

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

[0112] A star operation can be a noise matrix multiplication, for example, a regular matrix multiplication followed by the addition of noise. The addition of noise can also be integrated with the matrix multiplication. Adding noise to a star operation can be accomplished in a variety of ways. One example of adding noise is adding explicit noise (e.g., generating and adding a noise matrix). The advantage of adding explicit noise is that it is under the full control of the cryptographer and can be finely tuned to, for example, achieve precise control over the failure rate of a system relative to its security. Furthermore, the advantage of adding explicit noise is that all matrices are on the same ring or field, simplifying analysis. Another example of adding noise is scaling. For example, matrices a, r, and s can have elements modulo q (e.g., integers or polynomials modulo q); the star operation can round the result of the matrix operation from modulo q down to modulo p, for example, by multiplying by p / q and performing rounding (e.g., rounding up, rounding down, or rounding to the nearest integer).

[0113] In this application, lowercase letters will be used to represent matrices, but it should be understood that it may be necessary to transpose the matrices wherever necessary (e.g., depending on the matrix dimensions and the requirement that the original keys on both sides should be approximately equal). In general, there is more than one way to do this. For example, by transposing all matrices in an embodiment, an alternative working embodiment can be obtained.

[0114] An example is given below, where the matrix objects are given in uppercase letters and the transpose is included. The secret key is defined as the matrix and Note that such a secret key matrix actually contains and The original key matrix is ​​equal to S T A T R and in From each of the entries of the original key, extract the B most significant bits so that a length of The raw key is called this because there is a probability that the raw keys derived at the public key encryption device and the private key decryption device are not exactly equal.

[0115] In registration phase 31:

[0116] The private key decryption device selects the public matrix A and the first private key matrix R

[0117] The private key decryption device calculates the first public key matrix B = AR + E for some error matrix E

[0118] Private key decryption device sends: A, B

[0119] In encryption phase 32:

[0120] The public key encryption device selects the second private key matrix: S

[0121] The public key encryption device calculates a second public key matrix for some error matrix E': U = A T S+E′

[0122] The public key encryption device calculates the second original key B T S, please note that B T S=S T A T R+E T R

[0123] The public key encryption device generates a transmission key K and calculates the encapsulated transmission key together with the reconciliation data as

[0124] Public key encryption device sends: U, C

[0125] In decryption stage 33:

[0126] The private key decryption device calculates the first original key S T U, please note, S T U=S T A T R+S T E′

[0127] The private key decryption device calculates CS T U to unpack and round the result to Next, we can, for example, divide by To obtain the transmission key K according to rounding

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

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

[0130] where w is small. The value of w is chosen to balance system security with system failure rate. A lower value of w reduces the system failure rate.

[0131] The matrix C can be calculated modulo p. For bandwidth efficiency reasons, the public key encryption device can calculate and send When restoring M, the private key decryption device calculates In this case, the original key has fewer bits used as reconciliation data than the number of available bits. Generally, less significant bits have less impact on the probability of failure.

[0132] Instead of using an error matrix, the example can be modified to scale down in the star operation to add noise, rather than adding explicit noise. Scaling down has the advantage of reducing the bandwidth.

[0133] return Figure 2a A registration phase 31 is shown, in which private key decryption device 10 generates its private key matrix and public key matrix and makes the public key available to public key encryption device 20. For example, the public key can be sent to device 20. For example, the public key can be stored in a public key database, from which device 20 can retrieve the public key. For example, devices 10 and 20 can be different devices or the same device.

[0134] During the registration phase 31, the device 10 generates a first private key matrix (r) and calculates a first public key matrix (b) based on the first private key matrix (r). For example, the device 10 may generate a public matrix (a) and calculate the first public key matrix (b) as a noise matrix multiplication between the first private key matrix (r) and the public matrix (a). The first public key matrix (b) is arranged to be transmitted from the private key decryption device to the public key encryption device 20. For example, the first public key matrix (b) may be sent from the private key decryption device to the device 20 in a message 11.

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

[0136] The encryption phase 32 may be later than the registration phase 31, or even much later than it. In the encryption phase 32, the device 20 generates a transmission key (K), generates a second private key matrix (s), and calculates a second public key matrix (u) based on the second private key matrix (s). For example, the device 20 may obtain a public matrix (a) associated with the first public key matrix (b), and calculate the second public key matrix (u) as a noise matrix multiplication between the second private key matrix and the public matrix (a). The public matrix may be obtained in the form of a seed from which the public matrix is ​​generated. In an embodiment, the public matrix is ​​obtained from different sources. For example, both the device 10 and the device 20 may obtain the public matrix from a third party.

[0137] The generation of the transmission key can be done randomly.

[0138] The device 20 is configured to: calculate a second original shared key (k*) based on the second private key matrix (s) and the first public key matrix (b), the calculation of the second original shared key comprising matrix multiplication between the second private key matrix (s) and the first public key matrix (b); encapsulate the transmission key (K) with at least a portion of the second original shared key by applying an encapsulation function to obtain encapsulated data (c); and transmit the second public key matrix (u) and the encapsulated data (c) to the private key decryption device. For example, the second public key matrix (u) and the encapsulated data (c) may be sent to the private key decryption device in a message 12.

[0139] Note that this allows the transmitted key to be independent of the original key. This provides increased resistance to active attacks.

[0140] After the private key decryption device receives the second public key matrix (u) and the encapsulated data (c) from the public key encryption device, the private key decryption device is able to proceed in the decryption phase 33 to calculate the first original shared key (k') based on the second public key matrix (u) and the first private key matrix (r), and calculating the first original shared key includes matrix multiplication between the second public key matrix (u) and the first private key matrix (r), and using at least part of the first original shared key (k') to decapsulate the encapsulated data (c) to obtain the transmission key.

[0141] Interestingly, in an embodiment, the second public key matrix (u) has fewer matrix elements than the first public key matrix (b). If all matrices are square and have the same dimension, the second public key matrix (u) and the first public key matrix (b) will have the same number of elements. The inventors' insight is that this is not necessary. This in turn means that the contributions of the public keys to messages 11 and 12 will be equal. However, the environments in which these messages are sent and the devices that send the messages may be very different. By selecting the size of the second public key matrix (u) to be smaller than the size of the first public key matrix (b), the bandwidth requirement for message 12 will be reduced, while the bandwidth requirement for message 11 will be increased.

[0142] One way to make the size of the second public key matrix (u) smaller than the number of matrix elements of the first public key matrix (b) is to select a suitably smaller second private key matrix. In particular, the second private key matrix (s) can be selected to have fewer matrix elements than the first public key matrix (b). This may mean that the second public key matrix (u) also has fewer matrix elements than the first private key matrix (r).

[0143] For example, in an embodiment, a system dimension (d) is selected. The system dimension partially determines the security of the system. Higher values ​​of n correspond to higher security. One of the multiple dimensions of each of the matrices a, r, b, s, and u is equal to the system dimension d. If error matrices are used, then the error matrices e and e' also have a dimension equal to the system dimension. If the original keys k, k' and / or the transmission key K are represented as matrices, they also have a dimension equal to the system dimension. Other dimensions of these matrices can be selected to enable compatible addition and multiplication (possibly including transposition).

[0144] In an embodiment, the public matrix a is a square matrix of dimension d×d. The first private key matrix r and the first public key matrix b have dimensions The second private key matrix s and the second public key matrix u have dimensions By dividing the second dimension of the second private key matrix s and the second public key matrix u The second dimension is chosen to be smaller than the first private key matrix r and the first public key matrix b It is ensured that the number of entries for public key u in message 12 is less than the number of entries for public key b in message 11 .

[0145] For example, by replacing the second dimension of the second public key matrix (u) with The second dimension of the first public key matrix (b) is chosen to be, for example, at most This ensures that the number of entries in the second public key matrix (u) is at most half of the number of entries in the first public key matrix (b).

[0146] The second dimension of the second private key matrix and the second public key matrix A particularly advantageous choice of is 1. This minimizes the size of the second message 12.

[0147] For example, message 11 may be sent during a registration phase, during which more bandwidth is available. For example, message 12 may be sent during active participation in a system where less bandwidth is available. For example, device 12 may be a sensor that is provided with the first public key when sufficient bandwidth is available (e.g., during production or setup), and message 12 may be sent during use of the sensor (during which bandwidth is less). Note that instead of sending message 11 over, for example, a computer network, the first public key may be obtained at device 20 by, for example, installing it on a memory device of device 20.

[0148] Interestingly, the security of the system is considered to depend more on the system dimension d and the product Rather than depending on and The latter indicates the length (in bits) that can be used to derive the original key. The former affects the size of the underlying lattice, thereby affecting the difficulty of the underlying cryptographic problem. The probability of decryption failure of this scheme depends in part on the value of B. A higher value of B will increase the failure rate and adversely affect the security of the PKE scheme against adaptive active attacks. Typically, B is fixed, for example in the form of a standardized parameter set.

[0149] Therefore, by reducing The size of the first public key is increased while the size of the first public key is increased (for example, size), it is possible to maintain the same security while reducing the bandwidth required for message 12. In particular, and The system and and The system has comparable security.

[0150] Interestingly, the second dimension of the second public key matrix (u) does not need to be determined in advance. It can be chosen independently of the choices made for the first private and public keys. In particular, it can be chosen independently of the dimension In an embodiment, the second dimension can be configured at the second device 20

[0151] In an example embodiment, B=4 may be used, B indicates the number of most significant bits used by the original key matrix entry.

[0152]

[0153] In the table above:

[0154] n indicates the order of the polynomials in the private matrix and / or the public matrix. A value of n=1 indicates that an integer modulo the modulus is used. This value n may be referred to as the "ring dimension," i.e., the order of the selected polynomial ring.

[0155] d indicates the system dimension, i.e., the number of columns and rows of the common matrix a,

[0156] μ indicates the number of elements of the original key matrix used to encapsulate the transmission key. These elements can be predetermined (e.g., standardized), or can be randomly selected, or can be intentional, such as to be reliable elements, etc. The shared secret key length is therefore μB; in the example above, this is 64×4=256.

[0157] In an embodiment, the first public key may include:

[0158] 1. A seed for regenerating the public matrix a. For example, the bit length of the seed can be chosen to be the same as the shared secret; in this example, 256 bits.

[0159] 2. Public key matrix b. The dimensions of this matrix can be d and And the elements modulo p can be selected. For example, the first secret matrix can be selected to be modulo q. In this case, noise can be added by scaling down from q to p. The public key matrix in this example can be calculated as In this example, 12×1198×64=920064 bits are encoded.

[0160] 3. Optionally, additional accounting information. For example, an identifier may be included to indicate the type of key; for example, 1 byte. For example, the identifier may indicate the regeneration method of the public matrix a. For example, the value may be included. (For example, 2 bytes). The two bytes allow selection of a larger Values, for example, in some use cases, A value of 512 is also possible. These values ​​and identifiers may be predetermined, for example, by a system designer, in which case they need not be included. However, including The value allows for dynamic shifting of bandwidth from the encryption phase to the registration phase, for example to the extent required by the application.

[0161] In this example, the total size of the public key matrix is ​​115,008 bytes. If the seed and / or identifier are included, an additional 32 or 35 bytes may be added, etc. Note that the secret key can be generated in a variety of ways. For example, the private key matrix can be completely random, but it can also be constrained, such as by a Hamming weight constraint. For example, the length d vectors in the private key matrix can have predetermined Hamming weights; for example, in this example, a Hamming weight of 574 can be selected.

[0162] In an embodiment, the ciphertext may include:

[0163] 1. The second public key matrix u. The second public key matrix may have dimensions d and And select the element modulo p. The public key matrix in this example can be expressed as In this example, 12×1198×1=14376 bits are encoded.

[0164] 2. The packed data c can be encoded as a vector with μ elements, where the elements are selected modulo t. In this example, the size of the packed data is μlog2t bits; in this example, 64×10=640 bits. This scheme can be considered to use log2t-B bits; in this case, 6.

[0165] 3. Optionally, if authenticated encryption is used for the message, an authentication tag. For example, if Galois / Counter Mode is used, the authentication tag can be an AESGCM authentication tag. It is not necessary to include the authentication tag in the public key of the PKE scheme.

[0166] 4. Optionally, For example, this could be 1 byte.

[0167] Therefore, in this example, the ciphertext size can be 12×1198×1+64×10=15016 bits, i.e., 1877 bytes. The ciphertext size does not include the size of the encrypted message. Optionally, some bits (e.g., 8 bits) can be used to transmit The PQ security of this example is estimated to be 2 233 , and the failure rate is estimated to be 2 -129 .

[0168] In an embodiment, active security can be further enhanced using a more sophisticated wrapper function (e.g., Algorithm 9) from Hayo Baan et al., "Round2: KEM and PKE based on GLWR." If so, the ciphertext can include a hash g, which can be calculated by the public key encryption device by hashing the public key of the private key decryption device. This hash can be used to ensure that the final shared secret contains contributions from both the private key decryption device and the public key encryption device. For example, a Fujisaki-Okamoto transform can be used. The hash can be, for example, the size of the shared secret, which in this example is 256 bits.

[0169] As noted above, the transmission key can be used to encrypt the message m. For example, the public key encryption device can be configured to encrypt the message (m) using the transmission key and transmit the encrypted message to the private key decryption device. The private key decryption device can receive the encrypted message (e.g., along with the second public key matrix and the encapsulated data) from the public key encryption device and decrypt the encrypted message using the transmission key.

[0170] In an embodiment, the transmission key K is independent of the first public key matrix (b). For example, the transmission key K can be generated without using the first public key matrix (b), for example, the transmission key can be randomly generated and / or generated before the device 20 receives the first public key matrix (b).

[0171] Likewise, the transmission key can be independent of the first private key matrix (r). The transmission key can be computationally independent of the second private key matrix (s), the second public key matrix (u), and the encapsulated data (c). Computationally independent means that within the computational boundaries of an attacker, knowledge of the second private key matrix does not provide information about the transmission key.

[0172] The transmission key K is usually used temporarily, for example, it can be temporary, for example, only used to encrypt a single message m or a single session, protocol, handshake, etc. The transmission key K can be a symmetric key, for example used as a key in a block cipher.

[0173] For example, device 20 may be configured to delete the transmission key and / or the second private key matrix used to encrypt the message after encapsulating the transmission key. For example, the transmission key and / or the second private key matrix may be deleted before sending the encapsulated data to device 10. Similarly, device 10 may delete the transmission key after decrypting the message.

[0174] In an embodiment, the second private key matrix is ​​derived from the transmission key. For example, the transmission key can be randomly generated (either real or pseudo) and then used as an input to a key derivation function (e.g., a hash function) to derive the seed. Other inputs are possible, such as the message, the first public key matrix, etc. The seed is then used to generate the second private key matrix, for example, as a deterministic pseudorandom function that depends on the seed. Preferably, the key derivation function is selected such that the transmission key cannot be calculated from the second private key matrix.

[0175] This has the following effect: After device 10 derives the transmission key, it can reconstruct the second private key matrix from the transmission key, for example by applying the same key derivation function and calculating the second private key matrix based on this key derivation function. Subsequently, device 10 can verify that the second public key and / or the encapsulated data were correctly calculated. This has the advantage of making active attacks more difficult to carry out. If device 10 detects an anomaly, such as a discrepancy between the received data and the recalculated second public key and / or the recalculated encapsulated data, device 10 can take appropriate measures, such as generating a warning signal, aborting decryption of the second message, etc.

[0176] The advantage of deriving the second private key matrix from the transmission key is that its security is higher than that of the CCA security system. This is advantageous, in particular, when the first public key matrix is ​​generated once and used for many messages.

[0177] In one embodiment, a processor of a public key encryption device is configured to calculate helper data to reduce the error rate when obtaining a transmission key at a private key decryption device. The nature of public key encryption based on noise matrix multiplication is that reconstruction of the transmission key on the private key decryption side may fail. This failure probability can be reduced in a number of ways, one of which is to calculate and send helper data to assist the private key decryption device in obtaining the correct transmission key.

[0178] For example, the private key decryption device may be configured to receive helper data from the public key encryption device and apply the helper data to reduce an error rate in obtaining the transport key at the private key decryption device.

[0179] Several types of helper data can be used. In the example given above, one method is used, namely, reconciliation data. Part of the second original key can be used to encapsulate the transport key, and part of the second original key can be used as reconciliation data.

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

[0181] In an embodiment, the public key encryption device is configured to perform one or more of the following operations:

[0182] a) applying a reliable bitwise function to the second original shared key (k*) to select a portion of the second original shared key, obtaining a reliable index indicating an element of the second original shared key (the bits used for encapsulation are derived from the indicated element); and transmitting the reliable index to a private key decryption device, and / or

[0183] b) generating reconciliation data (h) for at least part of the second original shared key, the reconciliation data comprising information allowing to reduce the difference between the first original key and the second original key derived at the public key encryption device and the private key decryption device, and transmitting the reconciliation data (h) to the private key decryption device, and / or

[0184] c) generating a parity bit for the transmission key, the transmission key and the parity bit forming a codeword according to the error correction code, and encapsulating the transmission key including encapsulating the codeword.

[0185] Likewise, the private key decryption device may be configured to perform one or more of the following operations:

[0186] a) receiving a trustworthy index from a public key encryption device, thereby selecting a portion of the first original shared key indicated by the trustworthy index,

[0187] b) receiving reconciliation data (h) for at least part of the first original shared key (k'), the reconciliation data comprising information allowing for reducing differences between the first original key and the second original key derived at the public key encryption device and the private key decryption device, applying a reconciliation function to the first original shared key and at least part of the reconciliation data, and

[0188] c) Decapsulating the encapsulated data (c) to obtain a near-codeword, and applying error correction according to the error correction code.

[0189] Reliable bits are bits that are more likely to be calculated equally on both sides. For example, some elements of the original key matrix can be determined to be reliable, while other unreliable elements can be discarded. Reconciliation data can be obtained for selected matrix elements. Finally, parity bits can be calculated to account for other errors. These three types of helper data are independent, as each, two, or all three can be used to reduce the failure rate of private key decryption.

[0190] In an embodiment, the reconciliation data and parity bits are combined, but not the reliable bits. An advantage of this approach is that no information about element sizes needs to be shared. The helper data may be included in the encapsulated data, but may also be transmitted independently from device 20 to device 10. The reconciliation data may be conveniently integrated with the encapsulated transport key, for example, as illustrated herein. Figure 3 An example of an embodiment in which parity bits and reconciliation data are combined but not reliable bits is illustrated in .

[0191] In an embodiment of a public key encryption device or a private key decryption device, the reliable bits are one or more most significant bits of the indicated element, the reconciliation data for the indicated element is one or more bits of the indicated element following the reliable significant bits, and one or more least significant bits of the indicated element may be discarded. The indicated elements (i.e., the reliable elements) may be transmitted from the public key encryption device to the private key decryption device, for example, to their positions in a matrix.

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

[0193] In an embodiment, the modified elements are determined so that they are consistent with the corresponding reconciliation data so that they are not discarded by the public key encryption device. The modified elements minimize the Lee distance between the selected element and the modified element.

[0194] Figure 2b An example of public key encryption and private key decryption is schematically shown. Figure 2b In the example, "ind" indicates the key size or matrix size.

[0195] Figure 2b The embodiment shown is based on Figure 2a During the registration phase 31, according to Figure 2b The device 10 can be used with Figure 2a The device 20 may be the same as the device 10. However, in the encryption phase 32, the device 20 is configured to obtain a key size for the transmission key (K) and generate the transmission key (K) based on the key size. For example, if the information to be encrypted has a higher security, the device 20 may select a 256-bit transmission key K, but if the information has a lower security, the device 20 may select a 128-bit transmission key K. The device 20 may determine a matrix size for the second private key matrix (s) to accommodate the encapsulation of the transmission key of the key size. For example, to accommodate a larger transmission key, the device 20 may select a larger (e.g., proportionally larger) second dimension

[0196] The Second Dimension can be chosen so that Equal to or at least as large as the expected bit size of the transmission key. For example, to support 256 bits instead of 128 bits, the second dimension can be chosen to be twice as large. For example, Can be 2 or 1, so Equal to 256 or 128.

[0197] Depends on the dimension selected The device 20 is based on the matrix size (for example, based on the system dimension d and the second dimension ) to generate the second private key matrix (s). Then, based on the larger matrix, the device 20 proceeds to calculate the original key and encapsulate the transmission key, for example, as indicated herein, for example, in Figure 2a However, device 20 transmits an indication of the key size and / or matrix size ind to the private key decryption device. For example, the indication ind may be the size of the transmission key, such as 256 or 128, or "large" or "small," or the size of the second public-private key matrix, such as the second dimension, such as 2 or 1. This indication may be implicit, for example, by sending a larger or smaller second public key matrix. For example, the second public key matrix may be sent in one or more computer network packets that indicate the size or end of the packet, thereby implicitly indicating the size of the second public key matrix and, therefore, the size of the second dimension, for example.

[0198] If the value is larger than that required for encapsulation, then a deliberately larger transport key may be chosen, such as one with a key size equal to The final transmission key can then be calculated from the selected transmission key, for example by means of a key derivation function, hashing or the like.

[0199] The device 10 may be, for example, as indicated herein (e.g., as in Figure 2a For example, the device 10 may use the received public key matrix to calculate the first raw key and decapsulate the encapsulated transport key. The size of the raw key may vary depending on the size of the public key.

[0200] In an embodiment, the first public key is associated with a parameter that is a parameter of the public key. are transmitted together so that the public key encryption device can determine the required For example, a public key cryptographic device can calculate Make For example, in an embodiment, the public key includes a public key matrix b, a public key matrix a and a dimension The latter may be implicit. In other words, the device 10 sends to the device 20 a set of parameters that allow a given level of security to be achieved.

[0201] Public key encryption according to the embodiments can be used in various existing protocols. For example, the embodiments can be integrated with protocols such as TLS, IPSec, VPN, etc. For example:

[0202] TLS 1.3: The client sends a client_hello message. The client_hello message can include a public key matrix. Instead of a public key, the client_hello message can include a URL indicating where to download the public key matrix. If the server does not already have the public key, for example, it can download the public key matrix and store it locally. Using the public key matrix, the server can encrypt the symmetric key sent to the client and use it as a master key from which to derive the symmetric key for the record layer. In this example, the client acts as a private key decryption device.

[0203] TLS 1.2: In this example, a different approach is used. The client can send a request, and the server sends a URL where the server's public key matrix can be obtained. If the public key is not yet available, the client can download it. Once the client has the public key matrix, it can proceed to encrypt, for example, the transport key for use in the record layer. In this example, the client acts as a public key encryption device.

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

[0205] In an embodiment, device 10 may be configured to send a first hello message that lists cipher information, such as SSL or TLS versions, or lists cipher information in the client's preferred order, supported CipherSuites, etc. In response to the first hello message, device 20 may send a second hello message. The second hello message may contain similar details. Device 20 may also send its digital certificate in the second hello message. Device 10 may verify the certificate. The first hello message and / or the second hello message may include a public key or an indication of a public key. In the second hello message and / or subsequent messages, one or more transport keys are agreed upon. The transport keys may be used to encrypt or authenticate subsequent communications between devices 10 and 20. If multiple transport keys are agreed upon, they may be combined into a single key, for example, by hashing them together or performing an XOR operation on them.

[0206] Figure 2c An example of a handshake is schematically shown. The handshake can be used in conjunction with existing protocols or can be used outside of existing protocols. Figure 2c Messages 12-16 are shown, some of which may be combined into a handshake. In particular, one or both of messages 13 and 16 may be omitted. For example, message 15 may be omitted. Time progresses toward the bottom of the figure.

[0207] Message 13 is a pre-assignment, during which device 20 obtains at least one first public key matrix (b) associated with private key decryption device 10. Subsequently, when device 20 and / or device 10 desires to participate in the handshake protocol, device 20 receives at least two identifiers from device 10 indicating at least two first public key matrices of the private key decryption device, the two first public key matrices having different sizes. For example, message 14 may be a greeting message. The ellipsis between messages 13 and 14 indicates that message 13 was sent before the handshake began. For example, device 20 may obtain the public key matrix from a public key database, etc., as part of a browser.

[0208] Device 20 selects one of the at least two first public key matrices by determining whether a key cache of a public key encryption device includes the larger of the two first public key matrices, and if so, selecting the larger first public key matrix. For example, device 20 may include a key cache in which previously obtained public key matrices are stored. The key cache may be part of a browser.

[0209] Device 20 may employ various strategies for selecting a public key. The first consideration is the size of the system dimension. The system dimension may be selected based on security considerations. A further consideration may be the desired size of the transmission key. Another consideration may be the size of the resulting message 12 to be sent from device 20 to device 10. For example, in one embodiment, device 20 may be configured to select the largest key available in the key cache.

[0210] If the desired key is not available in the key cache, and in particular if none of the public keys of the device 10 are available in the key cache, the device 20 may send a request message 15; the request message 15 requests the selected first public key matrix.

[0211] In response, the requested public key may be sent to the device 20 in a message 16. Note that the messages 103 and 16 do not necessarily have to come from the device 10, but may be obtained from, for example, a public key database or a software database or the like.

[0212] Once the selected public key is available, the device 20 can proceed to send the message 12 as described herein (e.g., by encapsulating the transmission key, etc.). The device 20 sends an indication of the selected first public key matrix to the private key decryption device. The transmission key (K) is encapsulated using the selected first public key. The device 20 can use the information about Figure 2b The described embodiments can use a larger public key to selectively encapsulate a larger or smaller transport key.

[0213] The device 10 may be configured accordingly to send a message 14 comprising at least two indications of at least two first public key matrices of a private key decryption device, the two first public key matrices having different sizes, and to receive a message 12 comprising an indication of a selected first public key matrix from a public key encryption device.

[0214] according to Figure 2c An advantage of this embodiment is that a larger key can be used if it does not incur additional bandwidth (e.g., if the keys are pre-assigned). The larger key can be used, for example, to encrypt both the larger transport key and the smaller transport key. If the keys are not pre-assigned, the system can select a smaller public key to reduce bandwidth consumption.

[0215] For example, in an embodiment, a large public key is chosen such that Where B is the number of bits of the elements taken from the original key matrix, for example, B = 1, 2, 4, etc. Keylength is the size of the transmission key, for example, its value can be 256. For example, in the case of the example value of B = 4 and the key length is 256, you can choose A small public key can be chosen so that Using the same example values, you can use This selection balances the bandwidth required between the two public keys. If the public key encryption device has access to a large key, the large key can be used to minimize bandwidth. If the public key encryption device does not have access to either key, the public key encryption device will request a smaller key to balance bandwidth. In an embodiment, the large first public key is at least 2 times larger, at least 4 times larger, or at least 8 times larger than the small first public key.

[0216] For example, a public key encryption device may receive a hello message from a private key decryption device, the hello message including, for example, (keyid101,8), (keyid102,64), which indicates that the public key encryption device has a key identifier keyid101 and The first key and has a key identifier keyid102 and If both keys are available in the key cache of the public key encryption device or only the key with ID keyid102 is available, it is possible (for example using the dimension ) chooses to use this larger key. If no key is available, the public key encryption device can request keyid 101, for example, from the private key decryption device or elsewhere. The encryption can then be used In both cases, the transport key can have the same length.

[0217] Figure 3 An example of public key encryption and private key decryption is schematically shown. Figure 3 The following symbols are used.

[0218] Parity_bits refers to the information used for error correction

[0219] obain_parity_bits(k) represents the number of parity bits obtained for k. For example, the parity bits can be generated based on an error correction code.

[0220] error_correct(k, parity_bits) means using parity_bits to correct potential errors in k or parity_bits, resulting in a version of k that is more likely to be error-free

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

[0222] In an embodiment of the protocol, the first public key comprises vectors. The ciphertext includes the second public key u and the encapsulated data c. The second public key matrix u can be a vector of dimension d with elements in Z_p. To minimize the size of the ciphertext, we can use This means that the original key will contain at most To optimize the size of the original shared key, we will take B bits from as many elements as possible, thus using The encapsulated data c encrypts the transmission key and can have elements, making it possible to encapsulate a transmission key of length κ = μ B. B is the number of bits extracted from each vector entry.

[0223] In our example, we want to minimize the ciphertext. We can gain new insights to further reduce the ciphertext size, even at the expense of a longer public key, as follows:

[0224] The first public key matrix includes a length of d vectors. This can be encapsulated where κ is the transmission key length and parity_bits_length bits are used as parity bits.

[0225] Since additional parity bits need to be transmitted, the vector c will become longer. b its length×log2t. However, due to the presence of these parity bits, the scheme is better able to handle decryption errors, allowing smaller values ​​of q and p to be chosen. Since p is smaller, d may also be reduced, since we can maintain the same level of security. In summary, by adding error correction codes in this way, we can further reduce the size of the ciphertext, even at the expense of a longer public key. The choice of B=1 is effective, and by using it, we need

[0226] In the embodiment, the following parameters are used:

[0227]

[0228] The 103 parity bits allow for bit-to-bit error correction. For example, the error-correcting code XEf can be used, which allows for 3-bit error correction. XEf is described in "Round5: Compact and Fast Post-Quantum Public-Key Encryption" by Sauvik Bhattacharya et al. The advantage of using XEf is that it can be decoded efficiently in constant time, thus preventing timing attacks.

[0229] In this embodiment, the ciphertext size will be slightly larger than 1KB. This means that such a construction enables a non-ring configuration that does not require ciphertext fragmentation. It is important to reduce the size of the ciphertext to less than approximately 1.5KB to avoid fragmentation in packet-based communications, such as the approximately 2KB packets used on the Internet.

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

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

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

[0233] exist Figure 4 middle:

[0234] h represents helper data, which includes the reconciliation bit.

[0235] get_reconciliation(k) is a function that returns the reconciliation bit from raw_key k.

[0236] reconciliate(k, h) is a function that reconciles a raw_key k given a reconciliation bit h.

[0237] safe_bits() returns two values: (i) the actual reliable value; and (ii) the location of the key bits, which can cause a lower probability of failure because the obtained value is far from the quantization boundary. The actual value returned by safe_bits() is used for packing later. The positions are exchanged with the other party so that the other party knows which positions are needed.

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

[0239] For example, in an embodiment, devices 10 and 20 may agree on an original key, such as a matrix key k* having n coefficients in Z_q. For example, elements in the original key matrix may be mapped to portions of the transmission key, such as to one or more bits. For example, half of the values ​​in Z_q may be mapped to 0, and half of them may be mapped to 1, such as B=1. Selecting reliable bits may be accomplished by selecting, for example, a certain number (e.g., mu) of coefficients that are farthest from the decoding boundary, thereby reducing the probability of error.

[0240] Key reconciliation data can be information extracted by a public key encryption device, for example, for selected reliable coefficients (e.g., selected mu coefficients) of an original key (e.g., a matrix key). The reconciliation information helps a private key decryption device make the same decision: whether to map a particular coefficient of the original key to which part of a codeword. This operation does not need to be performed only for the selected reliable coefficients, which means less work is required.

[0241] The error correction information can be parity bits. Parity bits can be extracted from the randomly generated binary key K, the message m, or the prekey, providing a degree of redundancy in the information encapsulated by the second device. This allows device 10 to correct errors even if they occurred previously. Therefore, if the key K to be transmitted is kappa bits long and has (mu–kappa) parity bits, these parity bits help device 10 ensure that the kappa bits of key K are correct.

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

[0243] A straightforward implementation of a reliable bit function is to define two or more center points for the coefficients that are sampled to obtain the coefficient bits. Coefficients that are too far from the center points can be discarded (e.g., based on a threshold), while the remaining coefficients can be sampled to values ​​associated with the center points. For example, the number of center points can be a power of 2. For example, matrix elements can be taken from various different rings, etc.

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

[0245] The public key encryption device, applying the above process, obtains the reliable bits and the corresponding key bit index. The reliable index can be communicated to the private key decryption device, but the reliable key bits cannot be communicated to the private key decryption device. The private key decryption device can then obtain the key bits based on the bits at the index indicated by the public key encryption device. Because these bits are more reliable, the error rate will be lower.

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

[0247] In one embodiment, two parties generate two original keys, for example, matrices that are approximately, but not completely, identical. To achieve exact agreement, certain reconciliation data is sent. A scheme for doing this is described in patent application number 16197277.3 filed by the same applicant with the European Patent Office on November 4, 2016 (entitled "REACHING AGREEMENT ON A SECRET VALUE"); for example, in one embodiment, the reconciliation method on pages 7-10 can be used. Variants disclosed elsewhere in the cited patent application may also be employed.

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

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

[0250] Then there is,

[0251]

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

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

[0254] Then there is,

[0255]

[0256] Intuitively, Extract v's (B+b h ) of the most significant bits b h least significant bit.

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

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

[0259]

[0260] Among them, v is the element closest to w, such that The closest element w can be obtained according to the Lee distance (eg, min(|vw|,q-|vw|)).

[0261] These three functions can be applied element-by-element to a matrix. In this article, the reconciliation function cited above is used as an example. As mentioned above, the reconciliation method in the application cited above can also be used. The cross-rounding function can be applied to obtain reconciliation data, and the rounding function can be applied to obtain reconciled data (e.g., reliable bits). When the reconciliation data is later used in the reconciliation function, the reconciled data will be restored. In other words: Assume v and w are within a threshold distance of each other.

[0262] Figure 5 An example of a cryptographic system 301 according to an embodiment is schematically shown. The system 301 includes a private key decryption device 300, a public key encryption device 350, and an optional public key repository 302. For example, the first device 300 and the second device 350 may be implemented on a device such as the first device 10, 100 and / or the second device 20, 200. The cryptographic system 301 may be implemented as follows: Figure 4 The cryptographic system 301 may be adapted to other embodiments as needed (eg, by omitting elements not used in the depicted embodiment).

[0263] The first device 300 and the second device 350 are configured to execute a cryptographic protocol. They have the ability to securely transfer data from one device to another. Various cryptographic protocols can utilize this same capability. As examples, two protocols that utilize this capability are described.

[0264] For example, the first device and the second device can be configured for public key encryption (e.g., designed to allow other devices (e.g., the second device 350) to encrypt the message (m)), so that a specific device (e.g., the first device 300) can decrypt the encrypted message. However, other devices other than the encryption device and the decryption device (e.g., the second device 350 and the first device 300) cannot obtain the content of the public key used to encrypt the message. In the case of public key encryption, multiple second devices can use the same public key of the first device (e.g., the same first public key and public object) to send encrypted messages to the first public device. Even if the second device uses the same public key to encrypt the message, it cannot decrypt the communication of another device.

[0265] The first device 300 and the second device 350 include communication interfaces 305 and 355, respectively. The communication interfaces are configured to communicate with each other. Examples of communication interfaces, such as over a wired or wireless network, are described herein.

[0266] 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. Deriving the public key from the private key can use a public object (a), such as a public matrix. For example, generating the public key can involve multiplying the public object and / or introducing some type of noise, such as scaling the multiplication result, adding a noise term, etc. The private key and the public object can be matrices, such as matrices over a finite field or ring.

[0267] The first private key and the first public key can be generated temporarily. For example, the latter can be done for a key agreement protocol, particularly when the first device and the second device authenticate each other using some other authentication mechanism (e.g., an out-of-band mechanism, such as certificate-based authentication, etc.). The first private key and the first public key can also be generated for long-term use. For example, the first public key can be stored in an external public key repository 302. The public key repository 302 can also store the public object (a) or a seed for the public object (a).

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

[0269] The second device 350 may include a public key obtainer 360, for example, configured to retrieve the first public key from the public key repository 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, such as in an email, which may be out of bounds. The public key may be stored until needed for a public key encryption exchange. However, the first public key may also be received for immediate use, such as for a key sharing operation, in which case the first public key and / or public object may be generated briefly.

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

[0271] The second public key uses the same public object used to generate the first public key. The first and second private keys are private keys for their respective devices. If necessary, they can be shared with trusted parties, such as for backups, key escrow, etc. The public key and public object do not necessarily have to be secret for security; however, if desired, one or more of them can still be private to the first and second devices. For example, the first public key can only be shared with the second device, and vice versa.

[0272] The second device 350 may include a codeword generator 370. The codeword generator 370 is configured to generate a codeword based on an error correction code. The error correction code may be a linear code or a nonlinear code. For example, the error correction code may be a BCH code, a Reed-Solomon code, a Hadamard code, or the like. Multiple codes may be concatenated. A concatenated code is an error correction code constructed from two or more simpler codes to achieve good performance with reasonable complexity. For example, a Hadamard code may be concatenated with a BCH code.

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

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

[0275] Interestingly, the codeword is generated independently of the first private key, the first public key, the second private key, and the second public key. Therefore, the protocol improves its resistance to active attacks. The probability of an attacker influencing the shared key is reduced because the attacker cannot influence the key by selecting the first and second private keys. In an embodiment, the second private key matrix is ​​derived from the codeword or from the transmission key.

[0276] For example, in the case of a message, independent generation can be achieved if the message is generated according to an application that is independent of public key cryptography (e.g., a financial or communication application, etc.). For example, independent generation can be achieved by random generation. For example, the key or prekey in the codeword can be independently generated, such as by using a true random number generator or using a pseudo-random generator (which uses a seed that is independent of the first private key and the second private key, e.g., which is itself randomly generated, or predetermined, etc.). For example, the codeword can be generated at the second device even before the first public key is received and / or before the second private key is generated; this also ensures independence.

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

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

[0279] In the event that insufficient coefficients remain, there are several possibilities, such as terminating the protocol, restarting the protocol with a new first private key and / or second private key and / or new public object, deriving a shorter key, or discarding fewer coefficients. Instead of selecting all coefficients within a threshold, a predetermined number of coefficients (e.g., mu coefficients) can also be selected, and the most reliable coefficients (e.g., the first mu most reliable coefficients) can be selected.

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

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

[0282] One way to implement reconciliation data is to use one or more bits of the coefficient that follow the bit that is considered to be reliable (e.g., b h For example, these bits may be the B bits that follow the B bits in significance. hFor example, the number of reconciliation digits for each selected coefficient can be 1 or 2. A smaller number of reconciliation digits has the advantage of reducing communication overhead. However, more reconciliation digits can also be used.

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

[0284] Note that encapsulation applies to the entire codeword, including the data bits and parity bits, not just the parity bits. Furthermore, encapsulation applies to generated data (e.g., messages, keys, prekeys, etc.), not to data derived from one or more of the first public key or the second public key or the first private key or the second private key.

[0285] The second device is configured to transmit the second public key (u), the reconciliation data (h), the encapsulated data (c), and the reliable index to the first device. The transmission can be in response to receiving the first public key, such as in the case of key agreement, or not in response to receiving the first public key, such as in the case of public key encryption.

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

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

[0288] Finally, the codeword can be decoded, for example, to obtain the data portion and, thus, the message (m), the key (K), or the prekey. In the first case, some action can be taken based on the message, for example, the message can be displayed in a communicator application. In the second case, the key can be used for further protected communications, etc. In the third case, a key derivation function can be applied to the prekey to obtain the shared key.

[0289] A small and illustrative example is given below to illustrate reliability and reconciliation. We will take =2 5 =32 and B=b h = 1. We write the coefficients as five-bit sequences with the most significant bit on the left. For example, in an embodiment, the second device may discard coefficients 00000, 00001, 01110, 01111, 10000, 10001, 11110, and 11111 because performing only a small addition or subtraction on such coefficients will flip their most significant bits.

[0290] The coefficients that are not discarded are 00010, 00011, ..., 01101 and 10010, 10011, ..., 11101. The coefficients in the first list are assigned a reliable 0, while the coefficients in the last list are assigned a reliable 1. The second bit of these sequences can be used as reconciliation data. The reconciliation data for the selected coefficients is transmitted to other devices, but the reliable bits are not.

[0291] After the first device calculates its original key, it selects a coefficient based on the coefficient indicated by the first device. For example, suppose the coefficient in the first device's original key is 01101, and the reconciliation data for this coefficient is 0. Since the second bit of the coefficient at the first device is not 0, this indicates to the first device that an error has occurred. The closest value to the selected coefficient 01101 that has a second bit of 0 and is not discarded is 10010. Note that 00111 also has a second bit of 0, but is further away from the selected coefficient 01101. Therefore, the first device will select 1 as the reliable bit for this selected coefficient.

[0292] Note that if there is significant noise, this correction may be erroneous; imagine the coefficients for the second device being 00111. In this case, the wrong reliable bit is selected. Interestingly, even with a moderate amount of reconciliation data, these types of errors are rare. This means that relying on error-correcting codes to correct the remaining errors is more effective than increasing the amount of reconciliation data. Minimizing the Lee distance can be accomplished simply by trying candidate correction coefficients with increasing Lee distance until a match is found. More advanced algorithms are also possible, such as those described in the literature.

[0293] There's an interesting synergy between reliability and reconciliation. It's possible that the closest modified coefficient with correct reconciliation data has been discarded by the public key encryption device. The closest modified coefficient with correct reconciliation data, with the additional constraint that it won't be discarded by the public key encryption device, can have a different reliable bit. By taking this into account, the effectiveness of the reconciliation bit is further increased. For example, continuing with the example above, consider that the second device obtains the coefficient 01100 with reconciliation data of 0. The closest modified coefficient is 10000, but the closest coefficient that hasn't been discarded is 00111. Therefore, the first device recovers the reliable bit 0 instead of 1.

[0294] In some embodiments, the processor of the public key encryption device is configured to derive a final key based on at least the transmission key, encrypt a message using the final key, and transmit the encrypted message to the private key decryption device. In some embodiments, the processor of the private key decryption device is configured to receive an encrypted message from the private key decryption device, derive a final key based on at least the transmission key, and decrypt the encrypted message using the final key.

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

[0296] The following numbered embodiments are further contemplated:

[0297] 1. A public key encryption device (20), comprising:

[0298] a communication interface configured to communicate with a private key decryption device (10);

[0299] A processor configured to:

[0300] obtaining a first public key matrix (b) associated with the private key decryption device,

[0301] Generate the transmission key (K),

[0302] generating a second private key matrix (s), and calculating a second public key matrix (u) from the second private key matrix (s), the second public key matrix (u) having fewer matrix elements than the first public key matrix (b),

[0303] calculating a second original shared key (k*) based on the second private key matrix (s) and the first public key matrix (b), wherein calculating the second original shared key comprises matrix multiplication between the second private key matrix (s) and the first public key matrix (b),

[0304] encapsulating said transmission key (K) with at least part of said second original shared key by applying an encapsulation function, thereby obtaining encapsulated data (c),

[0305] The second public key matrix (u) and the encapsulated data (c) are transmitted to the private key decryption device.

[0306] 2. A private key decryption device (10), comprising:

[0307] a communication interface configured to communicate with a public key encryption device (20);

[0308] A processor configured to:

[0309] generating a first private key matrix (r), and calculating a first public key matrix (b) based on the first private key matrix (r), and allowing the first public key matrix (b) to be transmitted to the public key encryption device,

[0310] receiving a second public key matrix (u) and encapsulated data (c) from the public key encryption device, the second public key matrix (u) having fewer matrix elements than the first public key matrix (b),

[0311] calculating a first original shared key (k') based on the second public key matrix (u) and the first private key matrix (r), wherein calculating the first original shared key comprises matrix multiplication between the second public key matrix (u) and the first private key matrix (r),

[0312] The encapsulated data (c) is decapsulated using at least part of the first original shared key (k') to obtain a transmission key.

[0313] 3. The public key encryption device or private key decryption device according to any one of the preceding numbered embodiments, wherein:

[0314] The processor of the public key encryption device is configured to:

[0315] obtaining a key size of the transmission key (K) and generating the transmission key (K) according to the key size,

[0316] determining a matrix size of the second private key matrix (s) to accommodate encapsulation of the transmission key of the key size, and generating the second private key matrix (s) according to the matrix size, and

[0317] transmitting an indication of the key size and / or the matrix size to the private key decryption device, and / or

[0318] The processor of the private key decryption device is configured to:

[0319] receiving an indication of a key size and / or matrix size from the public key encryption device, and

[0320] The encapsulated data (c) is decapsulated according to the received size to obtain the transmission key.

[0321] 4. The public key encryption device or private key decryption device according to any of the above numbered embodiments, wherein:

[0322] The processor of the public key encryption device is configured to: encrypt a message (m) using the transmission key and transmit the encrypted message to the private key decryption device, and / or

[0323] The processor of the private key decryption device is configured to receive an encrypted message from the private key decryption device and decrypt the encrypted message using the transmission key.

[0324] 5. The public key encryption device or private key decryption device according to any of the preceding numbered embodiments, wherein:

[0325] The second original key is a matrix, and encapsulating the transmission key (K) comprises: adding bits of the transmission key to the most significant parts of at least part of the elements of the second original key matrix, and discarding zero or more least significant bits of at least part of the elements of the second original key matrix,

[0326] The first original key is a matrix, and decapsulating the encapsulated data includes: discarding zero or more least significant bits of at least a portion of the elements of the first original key matrix; subtracting at least a portion of the elements of the first original key matrix from the encapsulated data; and rounding the subtraction result.

[0327] Figure 6a An example of a public key encryption method (400) according to an embodiment is schematically shown. The method 400 comprises:

[0328] establishing (410) communication with a private key decryption device,

[0329] obtaining (420) a first public key matrix (b) associated with a private key decryption device,

[0330] Generate (430) a transmission key (K),

[0331] generating (440) a second private key matrix (s), and calculating a second public key matrix (u) from the second private key matrix (s), the second public key matrix (u) having fewer matrix elements than the first public key matrix (b),

[0332] calculating (450) a second original shared key (k*) based on the second private key matrix (s) and the first public key matrix (b), the calculating the second original shared key comprising matrix multiplication between the second private key matrix (s) and the first public key matrix (b),

[0333] encapsulating (460) the transport key (K) with at least part of the second original shared key by applying an encapsulation function, thereby obtaining encapsulated data (c),

[0334] The second public key matrix (u) and the encapsulated data (c) are transmitted (470) to a private key decryption device.

[0335] Figure 6b An example of a private key decryption method 500 according to an embodiment is schematically shown. The method 500 includes:

[0336] establishing (510) communication with a public key encryption device,

[0337] generating (520) a first private key matrix (r), and calculating a first public key matrix (b) from the first private key matrix (r), and allowing the first public key matrix (b) to be transmitted to a public key encryption device,

[0338] receiving (530) a second public key matrix (u) and the encapsulated data (c) from a public key encryption device, the second public key matrix (u) having fewer matrix elements than the first public key matrix (b),

[0339] calculating (540) a first original shared key (k') based on the second public key matrix (u) and the first private key matrix (r), the calculating the first original shared key comprising a matrix multiplication between the second public key matrix (u) and the first private key matrix (r),

[0340] The encapsulated data (c) is decapsulated (550) using at least a portion of the first original shared key (k') to obtain a transmission key.

[0341] As will be apparent to those skilled in the art, the method can be performed in many different ways. For example, the steps can be performed in the order shown, but the order of the steps can also be changed, or some steps can be performed in parallel. In addition, other method steps can be inserted between steps. The inserted steps can represent, for example, improvements to the method described herein, or can be unrelated to the method. In addition, a given step may not be fully completed before starting the next step.

[0342] An embodiment of the method may be performed using software comprising instructions for causing a processor system to perform method 400 and / or 500. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored in a suitable storage medium (e.g., a hard disk, a floppy disk, a memory, an optical disk, etc.). The software may be sent as a signal along a wire, wirelessly, or using a data network (e.g., the Internet). The software may be made available for download and / or remote use on a server. An embodiment of the method may be performed using a bitstream arranged to configure a programmable logic unit (e.g., a field programmable gate array (FPGA)) to perform the method.

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

[0344] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

[0345] In the claims, any reference signs between brackets shall not be construed as limiting the claim. The use of the verb “comprise” and its conjugations does not exclude the presence of other elements or steps not mentioned in the claim. The word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. When preceding a list of elements, expressions such as “at least one of…” indicate a selection of all elements or any subset of elements from that list. For example, the expression “at least one of A, B, and C” should be understood to include only A, only B, only C, both A and B, both A and C, both B and C, or all A, B, and C. The present invention may be implemented by means of hardware comprising several different elements or by means of a suitably programmed computer. In a device claim enumerating several units, several of these units may be embodied by the same item of hardware. The fact that certain measures are recited in different dependent claims does not mean that a combination of these measures cannot be used to advantage.

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

Claims

1. A public key encryption device (20), wherein: During the encryption phase, the second dimension of the second public key matrix (u) is It is configurable, and the public key encryption device includes: a communication interface configured to communicate with a private key decryption device (10); A processor configured to: obtaining a first public key matrix (b) associated with the private key decryption device, Get the key size of the transport key (K), generating the transmission key (K) according to the key size, By choosing the second dimension of the second private key matrix(s) accordingly The matrix size of the second private key matrix (s) is determined based on the value of to accommodate the masking of the transmission key of the key size, and the second dimension of the second private key matrix (s) is Equal to the second dimension of the second public key matrix (u) generating the second private key matrix (s) according to the matrix size, and calculating the second public key matrix (u) according to the second private key matrix (s), calculating a second original shared key (k*) according to the second private key matrix (s) and the first public key matrix (b), wherein calculating the second original shared key comprises matrix multiplication between the second private key matrix (s) and the first public key matrix (b), masking said transmission key (K) using at least part of said second original shared key, An indication of the key size and / or the matrix size, the second public key matrix (u) and the masked transmission key (c) are transmitted to the private key decryption device.

2. The public key encryption device according to claim 1, wherein: The processor of the public key encryption device is configured to perform a handshake with the private key decryption device, including: receiving from the private key decryption device at least two indications of at least two first public key matrices of the private key decryption device, the two first public key matrices having different sizes, selecting a first public key matrix by determining whether a key cache of the public key encryption device includes a larger of the two first public key matrices, and if so, selecting the larger first public key matrix, An indication of a selected first public key matrix is ​​sent to the private key decryption device, and if the first public key matrix is ​​not available in the key cache, the first public key matrix is ​​requested, and the transmission key (K) is encapsulated with the selected first public key matrix.

3. The public key encryption device according to any one of claims 1 and 2, wherein: The second private key matrix (s) has fewer matrix elements than the first public key matrix (b), and / or The second public key matrix (u) has fewer matrix elements than the first public key matrix (b), and / or The second public key matrix (u) has fewer matrix elements than the first private key matrix (r).

4. The public key encryption device according to claim 3, wherein: The second public key matrix (u) has a first system dimension (d) and a second dimension The first public key matrix (b) has the first system dimension (d) and a second dimension The second dimension of the second public key matrix (u) is smaller than the second dimension of the first public key matrix (b) 5. The public key encryption device according to claim 4, wherein: The second dimension of the second public key matrix (u) At most the second dimension of the first public key matrix (b) half of the Among them, the second dimension of the second public key matrix (u) is 1.

6. The public key encryption device according to claim 3, wherein: The processor of the public key encryption device is configured to: Obtain a public matrix (a) associated with the first public key matrix (b), and wherein, Calculating the second public key matrix (u) comprises a noise matrix multiplication between the second private key matrix and the public matrix (a), the public matrix being shared between the public key encryption device and the private key decryption device.

7. The public key encryption device according to claim 6, wherein: The noise matrix multiplication includes scaling from q elements to p elements, where log2p / log2q≤0.85, Wherein, the public key encryption device is configured as: generating reconciliation data (h) for said at least part of said second original shared key, said reconciliation data comprising information allowing to reduce the difference between the first original key and the second original key derived at said public key encryption device and said private key decryption device, and transmitting said reconciliation data (h) to said private key decryption device, A parity bit is generated for the transmission key, the transmission key and the parity bit form a codeword according to an error correction code, and masking the transmission key includes encapsulating the codeword.

8. The public key encryption device according to any one of claims 1 and 2, wherein: The processor of the public key encryption device is configured to derive a final key based at least on the transmission key, encrypt a message (m) using the final key, and transmit the encrypted message to the private key decryption device.

9. The public key encryption device according to any one of claims 1 and 2, wherein: The transmission key is random and / or ephemeral and / or symmetric and / or independent of the first public key matrix (b).

10. The public key encryption device according to any one of claims 1 and 2, wherein: The processor of the public key encryption device is configured to calculate helper data to reduce an error rate when obtaining the transmission key at the private key decryption device.

11. The public key encryption device according to claim 7, wherein: The second original key is a matrix, and masking the transmission key (K) includes: adding the bits of the transmission key to the most significant part of at least part of the elements of the second original key matrix, and discarding zero or more least significant bits of at least part of the elements of the second original key matrix.

12. The public key encryption device according to any one of claims 1 and 2, wherein: The processor of the public key encryption device is configured to derive the second private key matrix from the transmission key.

13. The public key encryption device according to any one of claims 1 and 2, wherein: The processor of the public key encryption device is configured to obtain the first public key matrix from a public key database.

14. The public key encryption device according to claim 7, wherein: The first public key matrix and the second public key matrix, the first private key matrix and the second private key matrix, and the first original key and the second original key are matrices over a finite field or a ring.

15. A cryptographic system comprising: The public key encryption device (20) according to claim 1; as well as A private key decryption device (10), comprising: a communication interface configured to communicate with a public key encryption device (20); A processor configured to: generating a first private key matrix (r), and calculating a first public key matrix (b) based on the first private key matrix (r), and allowing the first public key matrix (b) to be transmitted to the public key encryption device, receiving from the public key encryption device an indication of a key size and / or a matrix size, a second public key matrix (u) and a masked transmission key (c), wherein during an encryption phase, at the public key encryption device, a second dimension of the second public key matrix (u) is It is configurable. Calculating a first original shared key (k') based on the second public key matrix (u) and the first private key matrix (r), wherein calculating the first original shared key comprises matrix multiplication between the second public key matrix (u) and the first private key matrix (r), and The masked transmission key (c) is demasked according to the received size using at least part of said first original shared key (k') to obtain the transmission key.

16. The cryptographic system according to claim 15, wherein: The processor of the private key decryption device is configured to perform a handshake with the public key encryption device, including: sending at least two indications of at least two first public key matrices of the private key decryption device to the public key encryption device, the two first public key matrices having different sizes, An indication of a selected first public key matrix is ​​received from the public key encryption device, and if a request for the selected first public key matrix is ​​received, the selected first public key matrix is ​​sent, and the transmission key (K) is decapsulated using the selected first public key matrix.

17. A cryptographic system according to any one of claims 15 and 16, wherein: The second private key matrix (s) has fewer matrix elements than the first public key matrix (b), and / or The second public key matrix (u) has fewer matrix elements than the first public key matrix (b), and / or The second public key matrix (u) has fewer matrix elements than the first private key matrix (r).

18. The cryptographic system according to claim 17, wherein: The second public key matrix (u) has a first system dimension (d) and a second dimension The first public key matrix (b) has the first system dimension (d) and a second dimension The second dimension of the second public key matrix (u) is smaller than the second dimension of the first public key matrix (b) 19. The cryptographic system according to claim 18, wherein: The second dimension of the second public key matrix (u) At most the second dimension of the first public key matrix (b) half of the Among them, the second dimension of the second public key matrix (u) is 1.

20. A cryptographic system according to any one of claims 15 and 16, wherein: The processor of the private key decryption device is configured to: Generate a common matrix (a), and where, Calculating the first public key matrix (b) includes noise matrix multiplication between the first private key matrix (r) and the public matrix (a), the public matrix (a) is shared between the public key encryption device and the private key decryption device, and the first public key matrix (b) is associated with the public matrix (a).

21. The cryptographic system according to claim 20, wherein: The private key decryption device is configured to: receiving reconciliation data (h) for said at least part of said first original shared key (k'), said reconciliation data comprising information allowing to reduce the difference between the first original key and the second original key derived at said public key encryption device and said private key decryption device, applying a reconciliation function to said first original shared key and at least part of said reconciliation data, and The masked transmission key (c) is unmasked to obtain the near codeword, and error correction is applied according to the error correction code.

22. A cryptographic system according to any one of claims 15 and 16, wherein: The processor of the private key decryption device is configured to receive an encrypted message from the private key decryption device, derive a final key based on at least the transmission key, and decrypt the encrypted message using the final key.

23. A cryptographic system according to any one of claims 15 and 16, wherein: The transmission key is random and / or ephemeral and / or symmetric and / or independent of the first public key matrix (b).

24. A cryptographic system according to any one of claims 15 and 16, wherein: The processor of the private key decryption device is configured to receive helper data from the public key encryption device and apply the helper data to reduce an error rate in obtaining the transport key at the private key decryption device.

25. The cryptographic system of claim 21, wherein: The first original key is a matrix, and demasking the masked transmission key includes: discarding zero or more least significant bits of at least part of the elements of the first original key matrix; subtracting at least part of the elements of the first original key matrix from the encapsulated data; and rounding the subtraction result.

26. A cryptographic system according to any one of claims 15 and 16, wherein: The processor of the private key decryption device is configured to reconstruct the second private key matrix from the transmission key and verify the calculation of the second public key matrix and / or the calculation of the encapsulated transmission key.

27. A cryptographic system according to any one of claims 15 and 16, wherein: The processor of the private key decryption device is configured to store the first public key matrix in a public key database.

28. The cryptographic system of claim 21, wherein: The first public key matrix and the second public key matrix, the first private key matrix and the second private key matrix, and the first original key and the second original key are matrices over a finite field or a ring.

29. A method (400) of public key encryption, comprising configuring a second dimension of a second public key matrix (u) during an encryption phase The public key encryption method comprises: establishing (410) communication with a private key decryption device; obtaining (420) a first public key matrix (b) associated with the private key decryption device; Get the key size of the transport key (K), generating (430) the transmission key (K) according to the key size, By choosing the second dimension of the second private key matrix(s) accordingly The matrix size of the second private key matrix (s) is determined based on the value of to accommodate the masking of the transmission key of the key size, and the second dimension of the second private key matrix (s) is Equal to the second dimension of the second public key matrix (u) generating (440) the second private key matrix (s) according to the matrix size, and calculating the second public key matrix (u) according to the second private key matrix (s), calculating (450) a second original shared key (k*) based on the second private key matrix (s) and the first public key matrix (b), the calculation of the second original shared key comprising a matrix multiplication between the second private key matrix (s) and the first public key matrix (b), masking (460) the transmission key (K) with at least a portion of the second original shared key, An indication of the key size and / or the matrix size, the second public key matrix (u), and the masked transmission key are transmitted (470) to the private key decryption device.

30. A cryptographic method comprising a public key encryption method (400) and a private key decryption method (500) according to claim 29, wherein the private key decryption method (500) comprises: establishing (510) communication with a public key encryption device, generating (520) a first private key matrix (r), and calculating a first public key matrix (b) from said first private key matrix (r), and allowing said first public key matrix (b) to be transmitted to said public key encryption device, An indication of a key size and / or matrix size, a second public key matrix (u), and a masked transmission key (c) are received (530) from the public key encryption device, wherein during an encryption phase, at the public key encryption device, a second dimension of the second public key matrix (u) is It is configurable. calculating (540) a first original shared key (k') based on the second public key matrix (u) and the first private key matrix (r), the calculation of the first original shared key comprising a matrix multiplication between the second public key matrix (u) and the first private key matrix (r), Using at least part of the first original shared key (k'), the masked transmission key (c) is unmasked (550) according to the received size to obtain the transmission key.

31. A transitory or non-transitory computer readable medium (1000) comprising data (1020) representing instructions for causing a processor system to perform the method of claim 29 or 30.

Images