Public key encryption with lwe-type ciphertexts

Abstract

Some embodiments are directed to generating a public key and / or to encrypting a message () with the public key Generating the public key may include computing a vector in the public key which includes applying a bivariate, vector-valued function, Formula (I), (I), to a random vector and a private key. Encrypting a message may include computing a vector (α) including applying the bivariate vector-valued function to a vector in the public key and a random vector, and computing a scalar (b). The resulting ciphertext may be of LWE-type. Noise may be added for security.

Description

[0001] PUBLIC KEY ENCRYPTION WITH LWE-TYPE CIPHERTEXTS TECHNICAL FIELD The presently disclosed subject matter relates to a method for encrypting a message with a public key, a method for decrypting with a private key a message encrypted with a public key, a system, and a non-transitory computer storage medium. BACKGROUND Homomorphic cryptography allows one to execute computer programs, e.g., circuit evaluations, function evaluations, etc., over encrypted data by a party without that party being able to decrypt. For example, input data and computation results may be received and returned in encrypted form. Intermediate data, e.g., an internal state of the computation, may also be in encrypted form. Even though the output of the computer program is returned in an encrypted form, when decrypted the output is expected to be the same, or very close to, as if the operations had been performed on the unencrypted data. Homomorphic encryption can be used for privacy- preserving outsourced storage and computation. This allows data to be encrypted and outsourced to a cloud environment for processing and / or storage, all while encrypted. In particular, homomorphic cryptography techniques exist that can be used, at least in principle, to compute any function on encrypted data. Such techniques are referred to as "fully homomorphic encryption" (FHE) techniques. The execution environment is provided by various homomorphic encryption techniques. One such homomorphic encryption system is described in I. Chillotti et al., “Programmable bootstrapping enables efficient homomorphic inference of deep neural networks”, Cyber Security Cryptography and Machine Learning (CSCML 2021), vol.12716 of Lecture Notes in Computer Science, pp. 1-19, Springer, 2021, DOI: 10.1007 / 978-3-030-78086-9_1 (incorporated herein by reference). Generally, TFHE-like homomorphic encryption schemes can be based on lattice encryption, e.g., LWE or NTRU encryption. For example, encrypted data may be received as LWE-type ciphertexts. Using technologies as described in the above paper, computations can be performed on an LWE-type ciphertext even though the secret key is unknown to the homomorphic computing device. Accordingly, there is a need for systems that can encrypt a message scalar as an LWE-type ciphertext. In particular, there is a need for encrypting a plaintext message as an LWE- type ciphertext in a public / private key setting where only the decryption needs to be private. There is a desire to enable a party to compute encryptions, without also trusting that party with the secret key ^. SUMMARY It would be advantageous to have an improved way of publicly obtaining LWE-type encrypted data. Knowledge of the secret key ^ would allow one to decrypt data using a regular LWE-type decryption algorithm. In an embodiment, a public key is generated from the secret key ^, so that knowledge of the public key of the public / private key pair is enough to encrypt data as an LWE-type ciphertext, but is not enough to allow decryption of the data. In an embodiment, the private key of the public / private key pair may be a secret vector ^. An LWE-type ciphertext has the form (^, ^) wherein ^ is random vector, and b is a scalar. The LWE-type ciphertext encrypts a message scalar ^ for a secret vector ^, wherein ^ = 〈^, ^〉 + ^^ + ^, message ^ is encoded as ^^ , ^ is a noise term, and 〈^, ^〉 is the inner product. For example, the encoding ^^ may be Δ^, wherein Δ represents a multiplier. The error term is added for security reasons. A public key encryption according to an embodiment has advantages over conventional public key encryptions for LWE-type ciphertexts; see e.g. [6, Section 6.1] or

[0012] . For example, the public key is shorter than by about a factor of the size the ciphertext modulus, for example a factor of 64 for a 64-bit ciphertext modulus. Furthermore, noise in the resulting public-key ciphertexts can be well controlled; in particular, the noise level in a ciphertext is lower than in known public-key solutions, e.g., by 2 bits or more for typical parameters. The public / private key pair may be used in any system in which public key encryption is used. For example, in a communication system, a sending device may encrypt a communication, e.g., an email, using the public key, while a receiving device may decrypt the encrypted communication with the private key. The security of the public key encryption is based on a computational hardness assumption, in this case, for example, the standard RLWE assumption. As for the LWE assumption, the RLWE assumption is lattice based; this is advantageous as the RLWE hardness is more likely to hold against adversaries with quantum computing capabilities, than say, the RSA assumption. Interestingly, LWE-type encryption is particularly useful if the encrypted data is used in a homomorphic calculation system. For example, the homomorphic scheme referred to in the background may be used, though it should be noted that LWE-type encryption is used by other schemes than the one mentioned in the background. Embodiments are useful for such systems as well. Because in an embodiment the noise level is well controlled, the subsequent homomorphic calculation needs to make fewer allowances for the presence of noise, e.g., performs fewer bootstrapping operations. As bootstrapping operations are one of the bottlenecks in homomorphic operations, this is an advantage. In an embodiment, a public key is paired with a secret key ^. The secret key ^ may be used as the private key. The private key may be generated as a random and bounded vector, e.g., a binary or ternary vector. The private key may also be received as an input. The public key comprises a pair of vectors that may be of the same dimension as the private key ^. Accordingly, there is only an increase in the size of the public key —which is made of integers modulo ^ (the ciphertext modulus)— compared to the private key but that increase is much lower than in conventional public keys for LWE-type encryption. A first one of the vectors in the public may be randomly generated, while the second vector may be computed from the first vector and the private key vector ^. Interestingly, a bivariate, vector valued function is applied that takes these two vectors as input and computes a vector. Many possibilities are possible for the function, and examples are provided herein. Once the public key is computed, it can be used to encrypt a message. Typically, the public key will be used on a different device than the device that generated the public key. This is not necessary, for example, the public key may be used for process separation to increase security. In this way access to the private key can be restricted to parts of the device, e.g., high security parts. While access to public key can be allowed to a low security part. The encryption of a plaintext scalar ^ comprises a vector and a scalar, as in LWE- type encryption. Where encryption is performed using the private key instead of the public key, which is also possible, the vector part of the encryption may be randomly selected. The scalar part may then be computed from the vector part and the private key. However, in public key encryption, a random vector is generated from which both the vector part and the scalar part is computed, using the public key not the private key. For example, computing the vector part of the encryption uses the same bivariate, vector valued functions as used during public key generation. Devices for public / private key generation, encryption, decryption and homomorphic encryption are electronic devices. The methods described herein may be applied in a wide range of practical applications. Examples include processing private data, e.g., medical data, financial data, etc., in a privacy-preserving way. Some embodiments are directed to generating a public key and / or to encrypting a message (^^) with the public key. Generating the public key may include computing a vector in the public key which includes applying a bivariate, vector-valued function (^ ⊛ ^) to a random vector and a private key. Encrypting a message may include computing a vector (^) including applying the bivariate vector-valued function to a vector in the public key and a random vector. The resulting ciphertext may be of LWE-type. A further aspect is method of key generation, encryption and / or decryption. An embodiment of the method may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment 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, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing an embodiment of the method when said program product is executed on a computer. 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. Another aspect of the presently disclosed subject matter is a method of making the computer program available for downloading. This aspect is used when the computer program is uploaded into, e.g., Apple’s App Store, Google’s Play Store, or Microsoft’s Windows Store, and when the computer program is available for downloading from such a store. BRIEF DESCRIPTION OF DRAWINGS Further details, aspects, and embodiments will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals. In the drawings, Figure 1a schematically shows an example of an embodiment of cryptographic system, Figure 1b schematically shows an example of an embodiment of cryptographic system, Figure 1c schematically shows an example of an embodiment of cryptographic system, Figure 2a schematically shows an example of an embodiment of a key pair generation system, Figure 2b schematically shows an example of an embodiment of a public key generation system, Figure 3a schematically shows an example of an embodiment of an encryption system, Figure 3b schematically shows an example of an embodiment of an encryption system, Figure 4a schematically shows an example of an embodiment of a decryption system, Figure 4b schematically shows an example of an embodiment of a decryption system, Figure 5a schematically shows an example of an embodiment of an encryption method, Figure 5b schematically shows an example of an embodiment of a key generation method, Figure 5c schematically shows an example of an embodiment of a decryption method, Figure 6a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment, Figure 6b schematically shows a representation of a processor system according to an embodiment. Reference signs list The following list of references and abbreviations corresponds to figures 1a-4b, and is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims. 100, 102 a cryptographic system 110 a public / private key pair generation device 110’ a combined key pair generation and encryption device 120, 120.1, 120.2 an encryption device 130 a decryption device 140 a homomorphic calculation device 111, 121, 131, 141 a processor system 112, 122, 132, 142 storage 113, 123, 133, 143 communication interface 172 a computer network 210 a public / private key pair generation system 210’ a public key generation system 211 a private key generator 221 a private key 212 a public key generator 280 a public key 281 a public key first vector 282 a public key second vector 212.1 a first vector generator 212.2 a second vector generator 220, 220’ an encryption system 213 an encryptor 213.1 an encryptor vector generator 213.2 an inner product generator 213.3 an encryptor scalar generator 251 a random vector 241 a message 260 a public-key encrypted message (public-key ciphertext) 261 a vector component of a public-key encrypted message 262 a scalar component of a public-key encrypted message 230, 230’ a decryption system 214 a decryptor 214.1 an inner product generator 271 an inner product 214.2 a subtraction and rounding / decoding unit 510 an encryption method 511 obtaining a public key 512 obtaining a scalar 513 computing the public key encrypted message 514 generating a bounded, random vector 515 computing the vector 516 computing the scalar 520 a key generation method 521 generating a private key 522 randomly generating a first vector 523 computing a second vector 530 a decryption method 531 receiving an encrypted message encrypted with a public key 532 obtaining a private key 533 obtaining the plaintext message 1000, 1001 a computer readable medium 1010 a writable part 1020 a computer program 1110 integrated circuit(s) 1120 a processing unit 1122 a memory 1124 a dedicated integrated circuit 1126 a communication element 1130 an interconnect 1140 a processor system DESCRIPTION OF EMBODIMENTS While the presently disclosed subject matter is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the presently disclosed subject matter and not intended to limit it to the specific embodiments shown and described. In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them. Further, the subject matter that is presently disclosed is not limited to the embodiments only, but also includes every other combination of features described herein or recited in mutually different dependent claims. TFHE and its variants (e.g., [4, 3]) are natively private-key encryption schemes. The same key is used to encrypt or to decrypt messages. Certain private-key homomorphic encryption schemes can be turned into a public-key encryption scheme by providing encryptions of zero (e.g., [6, Section 6.1]). A public-key encryption scheme may be obtained as follows. If [[⋅]]^^denotes a probabilistic [private-key] encryption algorithm, a public encryption key may comprise ^ encryptions of 0; e.g., pk = (^^← [[0]]^^, … , ^^← [[0]]^^). Let ⊞ denote the ciphertext addition. A public-key encryption of a plaintext ^ then may proceed as follows: $ • Draw a random bit-string (^^, … , ^^) ← {0,1}^; • Compute a randomized encryption of zero as ^ ← ^^^^⊞ ^^^^⊞ ⋯ ⊞ ^^^^; • Compute a trivial encryption of ^ and get ^ ← [[^]]^^; • Output the ciphertext ^ ← ^ ⊞ ^. A so-called trivial encryption is an encryption that can be obtained without the knowledge of the private key. Such an encryption is insecure. The so-obtained ciphertext decrypts to the input plaintext. Noting that ^ = [[^]]^^, the ciphertext ^ can be decrypted using the private key sk. In the case of TFHE-like encryption, the private decryption key is an ^-bit string ^ = (^^, … , ^^). The matching public encryption key is {(^^, ^^) ∈ (ℤ / ^ℤ)^× ℤ / ^ℤ}^^^^^ $ ←^(mod ^) and of vector ^^. The encryption of a plaintext ^ ∈ ℤ / ^ℤ is given by ^ = (^, ^) ∈ (ℤ / ^ℤ)^^^with mask ^ =∑^ ^ ^^^^^^^and body ^ =∑^^^^^^^+ Δ ^ where Δ = ^ / ^. This assumes that ^ divides ^. If not, an option is for example to define Δ = ⌊^ / ^⌋ (flooring), Δ = ⌈^ / ^⌉ (ceiling), or Δ = ⌈^ / ^⌋ (rounding). Another option is for example to define ^^ = ⌊^ ^ / ^⌋ (flooring), ^^ = ⌈^ ^ / ^⌉ (ceiling), or ^^ = ⌈^ ^ / ^⌋ (rounding). The body ^ of the ciphertext is then defined as ^ =∑^ ^^^^^^^+ ^^. Using matrix notation with vectors as column matrices, if we view the public key as the pair pk = (^, ^) with with ^ = ^ ^ and ^ = ^⊺^ + Δ ^ (resp. ^ = ^⊺^ + ^^) where ^ = (^^… ^^)⊺∈ (ℤ / ^ℤ)^. The decryption of a ciphertext ^ = (^^, … , ^^, ^) ∈ (ℤ / ^ℤ)^^^may proceed in two steps. The first step is to recover the corresponding phase defined as ^^(^)= ^ −∑^ ^^^^^^^mod ^ which represents a noisy value of plaintext ^. Indeed, it turns out from the definition that ^^(^) = Δ ^ + Err(^) (resp. ^^(^) = ^^ + Err(^)); Err(^) denotes the noise (error) term present in ^ . The second step is to remove the noise Err(^) to get Δ ^ (resp. ^^) and, in turn, ^. The above description makes use of the ring ℤ / ^ℤ. TFHE and the likes can similarly be ^ defined over the discretized torus ^^= ℤ / ℤ; see [8]. It also applies to polynomial structures; see e.g. [5]. More generally, it applies to structures known as modules. Let ^ be a ring. An ^-module ^ equipped with an external product ‘⋅’ satisfies the following properties. For any ^, ^ ∈ ^ and ^, ^ ∈ ^, it holds that (^ + ^) ⋅ ^ = ^ ⋅ ^ + ^ ⋅ ^ and ^ ⋅ (^ + ^) = ^ ⋅ ^ + ^ ⋅ ^. Further, the external product is homogeneous: for any ^, ^ ∈ ^ and ^ ∈ ^, one has ^ ⋅ (^ ⋅ ^

[0002] ^) = (^^) ⋅ ^. For example, the real torus ^ = ℝ / ℤ is a ℤ-module. Take ^ = 2, ^ = 3, ^ = ^ and ^ = ^ ^ ^ ^ ^. One gets (^ + ^) ⋅ ^ = 5 ⋅ ^ = 0 and ^ ⋅ ^ + ^ ⋅ ^ = ^ + ^ = 0, as expected. One also get ^ ⋅ (^ + ^ ^ ^ ^ = ^. Finally, taking ^ = ^ = ^, one gets ^ ⋅ (^ ⋅ ^) = 2 ⋅ ^ = ^ ^ ^, Modules are defined from any rings, including polynomial rings. For example, let Φ(^) denote the ^-th cyclotomic polynomial, e.g., the unique irreducible polynomial with integer coefficients that divides ^^− 1 but not ^^− 1 for any ^ < ^, and let ^ denote its degree. Suppose for example that ^ is chosen as a power of 2, in which case we have ^ = ^ / 2 and Φ(^) = ^^+ 1. Considering the polynomial rings ℝ^[^]: = ℝ[^] / (^^+ 1) and ℤ^[^]: = ℤ[^] / (^^+ 1), this defines the ℤ^[^]-module ^^[^]: = ℝ^[^] / ℤ^[^] = ^[^] / (^^+ 1). Elements of ^^[^] can therefore be seen as polynomials modulo ^^+ 1 with coefficients in ^. Being a ℤ^[^]-module, elements in ^^[^] can be added together and externally multiplied by polynomials of ℤ^[^]. Here is an illustration. If ^ = 4 (and so ^ = 2) then Φ(^) = ^^+ 1 and, in turn, ^^[^] = ^[^] / (^^+ 1) ={^(^)= ^^^ + ^^|^^, ^^∈ ^}. Take for example ^ ^ ^ ^ ^ ^ ^(^) = ^^ + ^, ^(^) = ^^ + ^, and ^(^) = 2^ + 7. Then (^ + ^)(^) = ^^ + ^ and (^ ⋅ ^)(^) = ^ ^ ^ ^ ^ ^ ^ ^ ^^+ ^ + = − + ^ + = ^ + . Recall that polynomials are defined mod^^ ^^ ^ ^ ^^ ^ ^^ ^^ ulo ^ + 1 (and thus ^^≡ −1). It is worth noting that a ring ^ is also an ^-module wherein the external product is simply the (internal) product of ^. In order to have a sufficient security margin, the value of ^ should be at least of the order of ^ = (^ + 1) |^|^+ ^ ; the additional term ^, where ^ is the security parameter accounts for the corresponding subset-sum problems. For example, typically, ^ = 128. For a random variable ^, its expectation is denoted by ^[^] and its variance by Var(^). Assuming that the noise ^^is centered and that its variance is bounded by the same reshold ^^$ ^ th = Var(^^), the noise variance in an output ciphertext—where ^ ← {0,1}^—is of^^^ ^ . In the worst case, ^ = (1,1, … ,1) and Var(Err(^)) = ^ ^^. Indeed, let ^ denote the output ciphertext. It is easy to check that ^ ^ ^(^) =∑^^^^^^^+ Δ ^ and thus Err(^) =∑^ ^^^^^^^. Noting that for a uniform bit ^ in {0,1}, ^[^] = 1 / 2 and Var(^) = ^ ^ ^ ^ 1 / 4, it follows that Var(Err(^)) = ∑^ ^^^Var(^^^^) = ∑^ ^^^(^ ^ ^ ^^ ^ + ^ 0 + ^ ( ^) ) = ^ ^ ^ . If ^ = (1,1, … ,1) then Var(Err(^)) =∑^ ^^^Var(^^) = ^ ^^. Further, assuming the masks ^^are derived from a random seed ^ ∈ {0,1}^where ^ is the security parameter, the size of the public encryption key is of |^|^+ ((^ + 1)|^|^+ ^) |^|^bits. For example, at the 128-bit security level, e.g., ^ = 128, with ^ = 1024, ^ = 2^^and ^ = 2^^^^ = 2^^, we have ^ = 65728 ≈ 2^^. This results in an increase of the noise variance in an output ciphertext by an expected factor of 2^^. With ^ = 2^^, the standard deviation of the noise in an output ciphertext is of 2^^.^. We also have that the public encryption key takes 4206720 bits, that is, about 526 kB. While the above approach is capable of forming LWE-type ciphertexts, it suffers from several disadvantages. The public encryption key has a large size. Furthermore, the resulting LWE-type ciphertexts contain a larger amount of noise. This may be particularly an issue for fully homomorphic encryption, where operations are directly performed on ciphertexts. Embodiments described herein reduce the public encryption key size for a given security level, or increase security for a given public encryption key size. Embodiments described herein reduce noise in an LWE-type ciphertext. Figure 1a schematically shows an example of an embodiment of a key pair generation device 110, an embodiment of an encryption device 120, an embodiment of a decryption device 130, and an embodiment of homomorphic calculation device 140. Key pair generation device 110, encryption device 120, decryption device 130, and homomorphic calculation device 140 may be part of a system 100. Key pair generation device 110 is configured to generate a public / private key pair. The private key of the key pair may be generated as a bounded, random vector (^). The public key may comprise two vectors, that are computed from the private key and further inputs, e.g., random inputs. Encryption device 120 is configured to encrypt a plaintext message using a public key, e.g., as generated by the key pair generation device 110. Note encryption does not need access to the private key. The encryption may comprise a vector and a scalar. The vector and scalar being computed from the public key, the plaintext message, and further random inputs, in particular a random vector. The random vector and other random inputs may be computed by the encryption device 120. Decryption device 130 is configured to decrypt an encrypted message, e.g., an encryption of the plaintext message, performed by encryption device 120. Decryption uses the private key, e.g., computed by the key pair generation device. Key pair generation device 110 and decryption device 130 are typically the same device. For example, key pair generation device 110 may generate a key pair, retain the private key and send the public to encryption device 120. It is not necessary that key pair generation 110 and decryption device 130 are the same device. For example, key pair generation device 110 may be trusted to compute key pairs. Key pair generation device 110 may send the public key to encryption device 120 and the private key to decryption device 130. Key pair generation device 110, encryption device 120, decryption device 130, form a cryptographic system 100. For example, any device 120 with access to the public key may encrypt messages which can only be decrypted with access to the private key, e.g., by decryption device 130. Multiple devices 120 may use the same public key to encrypt messages for decryption device 130. In a communication system, devices 120 typically do not have access to the private key; for some applications this may be done however, e.g., see below. An optional, but advantageous addition to cryptographic system 100 is homomorphic calculation device 140. Calculation device 140 is configured to perform homomorphic calculations on encrypted messages. For example, one or more encryption devices 120 encrypt data, e.g., numerical data, using the same public key, and send the resulting encrypted messages to calculation device 140. Calculation device 140 performs a calculation, e.g., an algorithm, e.g., evaluates a neural network on the encrypted data. Note that calculation device 140 is not provided with the private key, though it may receive the public key. It may also be provided with so-called public evaluation keys; including bootstrapping keys or key-switching keys. Such auxiliary key material may be used by calculation device 140 to perform its computations. However, the auxiliary key material does not allow calculation device 140 to decrypt ciphertexts, nor to create ciphertexts. That is, the auxiliary key material is neither a private decryption key, nor a public encryption key. The outcome of the calculation may be provided to decryption device 130, and may be decrypted there. For example, calculation device 140 may be configured to receive an encrypted message; the encrypted message being previously obtained by encrypting a plaintext message with a public key according to an encryption method as in an embodiment. Calculation device 140 may also receive the public key that was used to encrypt the data as well as evaluation keys. Calculation device 140 can then perform a homomorphic calculation upon the encrypted input data, obtaining a public key encrypted output data. The output data can be supplied, e.g., to decryption device 130. The calculations may use a system such as described in the background. For example, in a cryptographic system 100, devices 110 and 130 may be the same device, but devices 130 and 140 are not. For example, in a cryptographic system 100, devices 110, 120 and 130 may be the same device, but device 140 is not. In the latter example, the encrypting device has access to the private key, the calculation device however does not get access to the private key. Key pair generation device 110 may comprise a processor system 111, a storage 112, and a communication interface 113. Encryption device 120 may comprise a processor system 121, a storage 122, and a communication interface 123. Decryption device 130 may comprise a processor system 131, a storage 132, and a communication interface 133. Homomorphic calculation device 140 may comprise a processor system 141, a storage 142, and a communication interface 143. In the various embodiments of communication interfaces 113, 123, 133, and / or 143, the communication interfaces may be selected from various alternatives. For example, the interface may be a network interface to a local or wide area network, e.g., the Internet, a storage interface to an internal or external data storage, an application interface (API), etc. Storage 112, 122, 132, and 142 may be, e.g., electronic storage, magnetic storage, etc. The storage may comprise local storage, e.g., a local hard drive or electronic memory. Storage 112, 122, 132, and 142 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 112, 122, 132, and 142 may comprise a storage interface to the non-local storage. Storage may comprise multiple discrete sub-storages together making up storage 112, 122, 132, and 142. Storage 112, 122, 132, and 142 may be non-transitory storage. For example, storage 112, 122, 132, and 142 may store data in the presence of power such as a volatile memory device, e.g., a Random Access Memory (RAM). For example, storage 112, 122, 132, and 142 may store data in the presence of power as well as outside the presence of power such as a non-volatile memory device, e.g., Flash memory. Storage may comprise a volatile writable part, say a RAM, a non-volatile writable part, e.g., Flash, Storage may comprise a non-volatile non-writable part, e.g., ROM. The devices 110, 120, 130, and 140 may communicate internally, with each other, with other devices, external storage, input devices, output devices, and / or one or more sensors over a computer network. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. The devices 110, 120, 130, and 140 comprise a connection interface which is arranged to communicate within cryptographic system 100 or outside of cryptographic system 100 as needed. For example, the connection interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. The communication interface 113 may be used to send or receive digital data, e.g., sending a public key to an encryption device. The communication interface 123 may be used to send or receive digital data, e.g., receive a public key, send encrypted data. The communication interface 133 may be used to send or receive digital data, e.g., receive encrypted data. The communication interface 143 may be used to communicate with other encryption devices, e.g., receive encrypted input data, send encrypted output data. The execution of devices 110, 120, 130, and 140 may be implemented in a processor system. The devices 110, 120, 130, and 140 may comprise functional units to implement aspects of embodiments. The functional units may be part of the processor system. For example, functional units shown herein may be wholly or partially implemented in computer instructions that are stored in a storage of the device and executable by the processor system. The processor system may comprise one or more processor circuits, e.g., microprocessors, CPUs, GPUs, etc. Devices 110, 120, 130, and 140 may comprise multiple processors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub- processor circuits. For example, devices 110, 120, 130, and 140 may use cloud computing. Typically, the key pair generation device 110, encryption device 120, decryption device 130, and homomorphic calculation device 140, each comprise one or more microprocessors which executes appropriate software stored at the device; for example, that software may have been downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. Instead of using software to implement a function, the devices 110, 120, 130, and / or 140 may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The devices may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL, etc. In particular, devices 110, 120, 130, and 140 may comprise circuits, e.g., for cryptographic processing, and / or arithmetic processing. In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., cryptographic coprocessors, and partially in software stored and executed on the device. Figure 1b schematically shows an example of an embodiment of a cryptographic system 102. System 102 may comprise multiple encryption devices; shown are encryption devices 120.1 and 120.2. System 102 comprises a combined key pair generation device and decryption device 110’. The devices are connected through a computer network 172, e.g., the Internet. Figure 1c schematically shows an example of an embodiment of a cryptographic system 103. System 103 may comprise multiple encryption devices; shown are encryption devices 120.1 and 120.2. System 103 comprises a public / private key pair generation device 110 and a decryption device 130; these may be combined in a single device. System 103 comprises a homomorphic calculation device 140 Key pair generation device generates a private key and sends it to decryption device 130. Note that the latter could be other way round; the decryption device generating a private key and sending it to device 110. Device 110 generates a corresponding public key and send it to the encryption devices 120.1, and 120.2. Typically, all encryption devices receive the public key, though multiple different yet functionally equivalent public keys could be computed for the same private key. Encryption devices 120.1 and 120.2 use the public key to encrypt data and send the encrypted data to homomorphic calculation device 140 A device that knows the public key, e.g., key pair generation device 110 and possibly decryption device 130 could also encrypt data and send it to homomorphic calculation device 140. In figure 1c, device 110 sends encrypted data to device 140. Device 110 or 130 may also compute additional cryptographic data useful for homomorphic calculations, and send it to device 140. The additional cryptographic data does not allow decryption of the encrypted data. Calculation device 140 may send the encrypted data to the decryption device. Figure 2a schematically shows an example of an embodiment of a key pair generation system 210. For example, generation system 210 could be implemented on key pair generation device 110. System 210 may comprise a private key generator 211. The private key 221 comprises a bounded, random vector ^. For example, the entries of the vector may be generated with a random number generator. The entries of the vector are bounded. For example, system 210 may store a bound, and may be configured to generate the entries up to the bound. The bound has an impact on the proliferation of noise in the system, so that a small bound is preferable for efficiency reasons. On the other hand, a larger bound allows for more randomness in the so- generated secret private key, which improves security. The bound may be chosen so that the system meets the targeted security level; e.g., typically 128-bit security. The entries are preferably balanced around zero, as this reduces noise proliferation.. For example, the absolute value of the entries in a bounded vector may be at most the bound, the bound being determined by the targeted security level and system parameters; for example, over the integers, may be, e.g., at most 5, at most 2, preferably, at most 1. In an embodiment, system 210 receives a security parameter as an input. The other parameters, e.g., dimension of vectors and the like, may be derived from the security parameters. Instead, system 210 may store one or more sets of parameters, selected by a cryptographic professional, e.g., a low, medium, and high security set. Instead of generating the private key, system 210 may obtain the key in another manner, e.g., receive the key. In that case the key pair generation system needs only to generate the public key corresponding to the private key. The private key generator 211 is optional. For example, a lower and upper bound may be set within which the entries of the vector are chosen. Two typical choices for a bounded vector, such as the private key vector are a binary vector. In this case, the entries may be chosen between 0 and 1 inclusive. Another choice is a ternary vector. In this case, the entries may be chosen between -1 and 1 inclusive. Having a private key 221, a public key 280 may be generated. Interestingly, knowledge of the public key 280 is sufficient to encrypt a message, while knowledge of the corresponding private key is needed to decrypt the encrypted message. In an embodiment the public key 280 comprises at least two vectors, at least one of which is randomly generated, and at least one of which is derived from at least the private key. In an embodiment, public key 280 comprises exactly two vectors of equal dimension. In an embodiment, public key 280 comprises two vectors, e.g., a pair of vectors (^, ^). Shown is first vector 281, ^, and second vector 282, ^. A public key generator 212 may be configured to generate public key 280 from the private key 221. A first vector of the two vectors may be randomly generated. For example, the entries of the first vector may be generated by a random number generator. It is not needed for the first vector to be small, e.g., bounded. Instead, the elements of the first vectors may be freely chosen from the underlying domain defining the scheme; for example, the ring ℤ / ^ℤ, the real torus ^ or the discretized torus ^^. A second vector of the two vectors is derived from the randomly generated vector and private key 221. Figure 2b schematically shows an example of an embodiment of a public key generator 210’. Generator 210’ is an example embodiment of public key generator 212, and may be used in system 210. Generator 210’ comprises a first vector generator 212.1. First vector generator 212.1 may be similar to private key generator 211, except that no bound on the size of the entries of first vector 281 needs to be imposed. Generator 210’ comprises a second vector generator 212.2. Second vector generator 212.2. computes second vector 282 from the first vector 281 and the private key vector 221. To compute second vector 282, a bivariate, vector-valued function, denoted as ⊛ is applied to the first vector 281 (^) and the private key 221 (^). The result of the function ^ ⊛ ^ is perturbed by adding a noise component to the result. A typical way to do this is to generate a noise vector ^ and to add the noise vector to the result of the function application: ^ ⊛ ^ + ^. For example, the noise vector may be generated similarly as the private key, e.g., as a random and bounded vector. The bound used for the noise vector does not have to be the same as the one used for the private key, though it may. For example, the noise vector may be a binary or ternary vector. For example, the noise vector can be drawn from a normal distribution centered around zero. For the bivariate function various possibilities are possible. Especially if the function is allowed to be non-linear, there are many choices. There are various constructions possible to determine a suitable bivariate function. For example, choosing the bivariate function may be done by determining it subject to restrictions imposed upon the function. For example, a typical restriction on the bivariate function is that encrypting results in an LWE-type ciphertext that decrypts to the original message—the same bivariate function may be used in the encryption and decryption. If in addition the bivariate function is, say, required to be linear in both of its inputs, then a system of equations can be created that determine the function or at least significantly limit the remaining choices. Various constructions for the bivariate functions are described herein. For example, a more efficient construction is to adapt an existing convolution. In the latter construction far fewer parameters need to be determined. It is possible to compute multiple different public keys corresponding to the same private key. The resulting ciphertexts resulting from using the different public keys are indistinguishable in the sense that one cannot tell, not even with the knowledge of the private key, which public key was used for the encryption. The entries in the vectors, e.g., in the private key and public key, and also the vectors and scalars described below for encrypting are typically chosen from a finite algebraic structure. For example, the algebraic structure may be the finite ring ℤ / ^ℤ. For example, the algebraic structure may be the discretized torus ^^. Note that ^ in these two examples is not required to be prime, though it may be; typically ^ is taken as a power of two. The underlying algebraic structure can also be continuous; for example, the algebraic structure may be the real torus ^. The dimension of the vector may be set according to the usage, for example, security requirements imposed on the system, the type of calculations that are performed on the encrypted data, if any, e.g., the expected noise proliferation, etc. Typically, the dimension of the vectors is a power of 2. For example, the dimension of the vectors may be at least 512, at least 1024, etc. Other values for the dimension, e.g., other than powers a power of 2, may be chosen. For example, the dimension may be selected as ^(^) where ^ denotes Euler’s totient function for some integer ^. This for example corresponds to the case where quotient polynomial is chosen as a cyclotomic polynomial. The degree of the ^-th cyclotomic polynomial is ^(^). Note also that when ^ is a power of two so is ^(^). Figure 3a schematically shows an example of an embodiment of an encryption system 220. Encryption system 220 may be implemented in a different system as the key generation system. For example, encryption system 220 may be used in a communication system, e.g., an email system. For example, encryption system 220 receives a public key 280, e.g., from system 210, and uses it to encrypt a message 241. The encrypted message 260 may be sent to a decryption system, which could be the same system as the key generation system 210, who can then decrypt the encrypted message 260 to recover the original message 241. In this embodiment, encryption system 220 typically has no access to the private key 221 corresponding to public key 280. Encryption system 220 may be implemented to encrypt data for use in a subsequent homomorphic calculation system. In an embodiment, encryption system 220 may be implemented in the same system as key generation system 210, though this is not necessary. In such an embodiment, encryption system 220 may have access to the private key 221 corresponding to public key 280, though private key 221 is not needed for encryption. Encryption system 220 obtains a public key 280. For example, public key 280 may be received from a key generation system 210. For example, public key 280 may be generated in system 220. For example, public key 280 and the corresponding private key 221 may be ephemeral keys. For example, a private / public key pair may be generated for the duration of one computation. Encryption system 220 is configured to obtain a scalar (^^) representing a plaintext message. The scalar may be selected from the underlying domain. For example, a function may map a plaintext message to the scalar. A plaintext message may be split over multiple scalars, to accommodate larger plaintext messages. The multiple scalars can be encrypted separately according to an embodiment. In an embodiment described below the multiple scalars can be encrypted jointly. The public key encryption of message 241 comprises a vector (^) and a scalar (^). The scalar could be an entry in a vector, but typically, this is not the case. For example, each encrypted message scalar may have one corresponding vector and one corresponding scalar. The plaintext could represent various types of data. Below is a list of examples for the plaintext message. These examples are especially suitable if the encryption is used to encrypt data before sending it to a homomorphic calculator, e.g., such as device 140. Encryption may be used, e.g., in one of the following scenarios: Healthcare applications: patient data may be encrypted with an embodiment of system 220. Homomorphic calculation can be used to perform medical research on the encrypted data without compromising patient privacy. This could include analyzing genomic data or conducting clinical trials. For example, a homomorphic calculation may be performed on medical data, e.g., medical sensor data, e.g., a medical image. The medical data may comprise genomic data. Cloud computing: The encryption may be used to securely outsource computation to untrusted cloud providers. Computations may be performed on encrypted data stored in the cloud, without ever having to decrypt the data. Machine learning: The encryption may be used to perform machine learning computations on encrypted data. This could include training models on encrypted data or making predictions on encrypted data without ever decrypting it. For example, a neural network may be trained and / or evaluated on encrypted data. For example, multiple data sources may be provided with the public key corresponding to the same private key. A data source uses the public key to encrypt its data and send it to a homomorphic calculation device. At the homomorphic calculation device a machine learnable model is trained, e.g., a neural network. The resulting parameters are then sent to a decryption device. For example, the data sources may correspond to hospitals or the like. The encrypted data may be medical data. This may be used, e.g., to train a neural network on data contributed from multiple parties, without the need to share plain training data. The multiple data source may each use the same public key. Block chains: The encryption may be used to hide data appearing on a public block chain. This could include private data like a user’s account balance. Using encryption would enable wiring money by checking on encrypted data that the user’s balance is sufficient for the transfer. Doing so would hide the exact balance of the user. Internet of Things (IoT) applications: The encryption may be used to securely process sensor data in real-time, without exposing the data to third parties. For example, a smart city could use homomorphic encryption to perform calculations on encrypted sensor data to improve traffic flow or reduce energy consumption. Encryption system 220 generates a bounded, random vector (^). Generating this vector may be done in a similar way as generating the private key. For example, the random vector may be a random binary or ternary vector. An encryptor 213 takes the public key 280, message scalar 241, and the random vector 251 and uses it to compute an encrypted message 260. Encrypted message 260 comprises a vector 261 and a scalar 262. Computing vector 261 uses the bivariate function introduced for computing the public / private key pair. Encryptor 213 adds a noise component to the encryption 260; preferably both to vector 261 and to scalar 262. Figure 3b schematically shows an example of an embodiment of an encryption system 220’. Encryption system 220’ is similar to encryption system 220 but more exemplifying details are provided. System 220’ comprises an encryptor vector generator 213.1. Vector generator 213.1 is configured to receive as input the public key first vector 281 and the random vector 251. Vector generator 213.1 computes the vector 261 by applying the bivariate vector-valued function to the first vector 281, ^ in the public key and the random vector 251, ^. The result is a vector 261. The bivariate vector-valued function may be the same function that was used in key generation. A noise component is included in the result. For example a noise vector is generated and added to the result of the bivariate function. System 220’ comprises an inner product generator 213.2. Generator 213.2 is configured to receive as input the public key second vector 282 and the random vector 251, and to compute their inner product 263. Generator 213.2 computes the inner product of the second vector 282, ^ in the public key and the random vector 251, ^. This inner product is used to mask an encoding of the plaintext message. Both the plaintext message and the encoding thereof may be represented as a scalar. System 220’ comprises an encryptor scalar generator 213.3. Scalar generator 213.3 adds an encoding (^^) of the plaintext message 241, ^; for example, ^^ = Δ^ for some multiplier Δ or ^^ = ^. Scalar generator 213.3 also adds a noise component. For example, a random value may be generated and added to the result. Typically, but not necessarily, the noise is drawn at random from a normal distribution centered around zero. There are various ways to encode a message scalar, e.g., by combining functions that cause the encoded message to be recoverable from the noise. One such possible function is to multiply a scalar representing the message. As the message moves to an upper position with respect to the noise, a rounding operation can remove most or all of the noise. Instead of multiplication with a multiplier, the encoding could be the application of a function that also causes the message scalars to move the the upper position, though not necessarily linearly. Preferably, the function is invertible, at least for the set of message scalars that are used. Another possibility is to encode the message together with an error correcting function. For example, the encoding may have the form ^(^(^)), wherein ^ is an error correcting coder, e.g., a BCH, Reed-Solomon, Hamming, etc., while ^ is an increasing function that maps the domain of ^(^) to an upper position. For example, function ^ may comprise a multiplication with a multiplier, ∆, etc. For example, the function could be a polynomial, though it is not necessary to restrict to polynomials. Accordingly, the scalar 262, ^, may be computed as ^ = 〈^, ^〉 + ^^ + ^^, wherein ^^ is an encoding of the message, and ^2is the noise. The choice of the encoding determines the message space and may impact the way the noise may interfere with correct decryption. Note that two functions are used in key generation and encryption: the bivariate vector valued function, ⊛ and the inner product. The latter function could be replaced with a bivariate, scalar function, taking as input two vectors and producing a scalar. As for the bivariate vector valued function, by imposing the encryption followed by decryption should give back the original message, conditions can be set for the both the vector valued function and for the scalar valued function. For example, the inner product can be chosen for the scalar valued function to obtain an LWE-type ciphertext, that is compatible with LWE type homomorphic encryption. For example, if the vector value function is denoted ^, and the scalar valued function as ^, then one way to create conditions on this function is to require that ^(^(^, ^), ^) = ^(^(^, ^), ^), e.g., for all ^, ^, ^, or at least for all those vectors that may be chosen by the system, or at least the condition should hold sufficient often. In fact exact equality is not even needed, so long the error is sufficiently small sufficiently often. Practically speaking it is often easier to evaluate the conditions on ^ and ^ when it is assumed that the condition holds exactly for all inputs. Since in this way the masking part falls out during decryption. A further condition may be that the resulting noise is sufficiently small, the encoding of plaintext does not interfere with the noise error, and any amplification of errors by functions ^ and / or ^ is sufficiently small. A more detailed example is given below. Interestingly, there is considerable freedom in choosing the bivariate functions. It turns out that if one sets the scalar valued function to be the inner product, the conditions of having a working encryption and decryption still allows the vector valued function to be chosen. For example, one condition that could be set is that: (^ ⊛ ^ ⊛ ^)^= (^ ⊛ ^ ⊛ ^)^= 〈^ ⊛ ^, ^〉 for some index ^, wherein the angle brackets represent the inner product. For example, assuming linearity, one can evaluate the above expression for a system of independent relations, and thus derive a system of equations for the vector valued function. Below other constructions for the vector valued function are given. As above, the condition could be relaxed if desired. In an embodiment, the dimension of the private key vector, the first and second public key vector, and the vector in an encryption are typically the same. The dimension may be at least 512, at least 1024. Figure 4a schematically shows an example of an embodiment of a decryption system 230. Decryption system 230 comprises a decryptor 214 configured to receive as input the public key encryption 260, a private key 221. For example, system 230 may receive the private key from the public / private key generator 210. Alternatively, the decryptor 230 and generator 210 may be implemented in the same system. Decryption system 230 may receive the encryption 260 from an encryption system 220. Decryption system 230 may receive the encrypted message 260 from a calculation device 140. Decryptor 214 is configured to compute the original plaintext message scalar from the public key encryption and the private key 221. Figure 4b schematically shows an example of an embodiment of a decryption system 230’. System 230’ is similar to system 230, but more exemplifying details are included. System 230’ comprises an inner product generator 214.1 configured to compute the inner product between the vector component 261 of a public-key encrypted message and the private key 221. The resulting inner product 271 is subtracted from the scalar component 262 of the public-key encrypted message. The latter equals the encoded message scalar plus an error ^^ + ^. The rounding / decoding unit (214.2) is configured to obtain the message scalar from the noisy encoded message scalar. For example, if the encoding comprises multiplying with a multiplier, then recovering the message may comprise rounding this value, possibly combined with other decoding steps. For example, if ^^ = Δ^, decryption system 230’ may decrypt a public key ciphertext ^ = (^, ^), using secret decryption key ^, the system may compute ⌈(^∗mod ^) / Δ⌋ mod ^ wherein, ^∗= ^ − 〈^, ^〉. Note that this corresponds to LWE-type decryption. Generally speaking, the systems can be configured by choosing the encoding larger and the error smaller so that the message ^ can be recovered from this value ^^ + ^. The bivariate, vector-valued function The bivariate, vector-valued function ⊛ may be derived from a convolution (*) and a univariate function (φ^), the bivariate function for a first vector (^) and a second vector (^) being defined as the convolution applied to the first vector and a vector obtained from the univariate function applied to the second vector (^ ⊛ ^ = ^ ∗ φ^(^)). This is advantageous as determining the univariate function is easier than if the bivariate vector-valued function were derived without this construction. Accordingly, determining a suitable vector-valued function ⊛ is faster and requires less storage. In this way a known convolution can be taken and adapted to get a new vector operator; i.e., bivariate, vector-valued function ⊛, enabling the construction of a public / private key encryption system producing LWE-type ciphertexts. Determining the univariate function, and thus the vector valued function, becomes even easier when the univariate function is taken to be linear. For such a univariate function, one further requires that one component of the vector valued function equals the inner product of the inputs. That is, an index ^ may be chosen such that the output of the bivariate, vector-valued function at index ^, namely, its ^-th component, equals the inner product of the two input vectors. That is applied to a first vector (^) and a second vector (^), the relation (^ ⊛ ^)^= 〈^, ^〉 is satisfied. Once an index ^ has been chosen, other scalar components of index different from of ^ from an induced vector ^ ⊛ ^ can be used as well; for example, (^ ⊛ ^)^for some index ^ ≠ ^. Convolutions of vectors may be obtained from a quotient polynomial ^ defining a polynomial module; for example, ℤ[^] / (^(^)) or ^[^] / (^(^)). Given the quotient polynomial ^ a convolution may be derived. The convolution applied to a first vector and a second vector is obtained by mapping the first and second vector to a first polynomial and a second polynomial, multiplying the first and second polynomials, and reducing the so-obtained polynomial modulo the quotient polynomial (^), and mapping the result to a vector. The multiplication of the first and second polynomials may preferably use an external multiplication. Note that for rings, the notions of external product and of internal product coincide. From the convolution a bivariate, vector- valued function can be derived, defined by a univariate function as indicated above. For example, simple system is obtained by taking the reduction polynomials to be ^^+ 1. Over ℤ, the bivariate, vector-valued function may be defined for two vectors ^ = (^^, … , ^^), ^ = (^^, … , ^^) ∈ ℤ^as the vector ^ = ^ ⊛ ^ = (^ ⊛^^, … , ^ ⊛^^) ∈ ℤ^defined by Multiple messages variant Interestingly, multiple messages may be encrypted jointed, saving on storage, and transmission bandwidth. In an embodiment as many scalars can be encrypted as is the dimension of the private vector. This can be done as follows. Instead of computing only the inner product of the second vector and the random vector, the bivariate, vector-valued function (^ ⊛ ^) is applied to the second vector (^) and the random vector (^), a distinct component of which being used for encrypting each message. The function can be arranged so that one of the components of the resulting vector is the inner product of the second vector (^) in the public key and the random vector (^). So this inner product is still computed, but together with other components of the vector ^ ⊛ ^. For the index (^) in the resulting ciphertext for which the vector component corresponds to the inner product, an LWE format encryption is obtained as in an embodiment. The other vector elements may still be used for encryption. For example, for the public-key encryption of multiple scalars (^^) representing multiple plaintext messages, one may compute ^ℓ← (^ ⊛ ^)^ℓ+ ^^ℓ+ ^^,ℓ, wherein ℓ runs from 1 to the number of messages, and wherein ^^ℓis an message ^ℓ. For the of ^ℓone vector ^ as in an embodiment is computed, e.g., by applying the bivariate vector-valued function to the first vector (^) in the public key and the random vector (^), and preferably adding first noise vector (^^). This significantly shortens the size of an encryption of this set. If more message scalars than the dimension of ^ need to be encrypted, then a new random vector may be computed, and a new vector ^ may be computed. Typically, all encryptions of multiple messages scalars will all use the same encoding, e.g., using same multiplier Δ, and noise from the same distribution. This is not necessary though; for example, some message scalars may be encrypted with low noise, and a lower-position encoding, while others may use higher noise and a higher-position encoding. Below several further optional refinements, details, and embodiments are illustrated. Let ^ be a monic (irreducible) polynomial of degree ^. Let also ℛ and ℛ^denote the polynomial rings ℤ[^] / (^(^)) and ℛ / (^) = (ℤ / ^ℤ)[^] / (^(^)), respectively. A polynomial ^ ∈ ℛ (resp. ^ ∈ ℛ^) of degree less than ^ and given by ^(^) =∑^^^ ^^^^^^^with ^^∈ ℤ (resp. ^^∈ ℤ / ^ℤ) can be identified with its coefficient vector ^: = (^^, ^^, … , ∈ ℤ^(resp. ∈ (ℤ / ^ℤ)^). Over ℛ^, we let Υ den ^ ote the corresponding map ∼ Υ^: ℛ^^ (ℤ / ^ℤ)^, two vectors in (ℤ / ^ℤ)^. Given ^, ^ ∈ (ℤ / ^ℤ)^, their convolution may be defined as ^ ∗ ^ = Υ^(Υ ^^ ^ (^) ⋅ Υ ^^ ^ (^)) ∈ (ℤ / ^ℤ)^ where ⋅ denote the polynomial multiplication in ℛ^. Using a convolution operator, e.g., as defined above, a public / private key system may be formulated. The secret key comprises a small vector ^ ∈ ℤ^and the public key is a pair of vectors (^, ^) where ^ is a random vector in (ℤ / ^ℤ)^and ^ = ^ + ^ (mod ^) for some small random vector ^ ∈ ℤ^. Then encryption of a plaintext ^ seen as a vector in (ℤ / ^ℤ)^is given by the pair of vectors (^, ^) in (ℤ / ^ℤ)^where ^ = ^ ∗ ^ + ^ ^^for some small random Next, given ciphertext (^, ^), plaintext ^ can be recovered using secret key ^ from the phase ^ − ^ ∗ ^ = Δ ^ + ^ (mod ^) where ^: = ^ ∗ ^ + ^^− ^^∗ ^ ∈ ℤ^. More generally, Δ ^ may be replaced with an encoded vector ^. Futhermore, encryption is defined over the ring ℤ / ^ℤ for illustration; a similar cryptosystem can easily be adapted and described for example over the discretized torus ^^or the real torus ^. Three observations are in order: 1. If ^^(resp. ^^) denotes the ^-th component of vector ^ (resp. ^) in (1) then the pair (^, ^^) is an LWE-type ciphertext encrypting a message ^^∈ ℤ / ^ℤ provided that ^^− 〈^, ^〉 = Δ ^^+ (small noise). In particular, we have ^^− 〈^, ^〉 = (^ ∗ ^)^+ Δ ^^+ (^^)^− 〈^ ∗ ^ + ^^, ^〉 As (^ ∗ ^ ∗ ^)^≈ 〈^ ∗ ^, ^〉 (2) is satisfied, one ends up with an LWE-type ciphertext for plaintext ^^∈ ℤ / ^ℤ. 2. If the public key is replaced with (^, ^ = ^ ∗ ^^(^) + ^) ∈ (ℤ / ^ℤ)^× (ℤ / ^ℤ)^for some (bijective) map ^^: (ℤ / ^ℤ)^→ (ℤ / ^ℤ)^then Condition (2) relaxes to (^ ∗ ^^(^) ∗ ^)^≈ 〈^ ∗ ^, ^〉. (3) 3. Further, the above encryption scheme is unchanged if vector ^ is replaced with vector ^^(^) for some (bijective) map ^^: (ℤ / ^ℤ)^→ (ℤ / ^ℤ)^. In particular, taking ^^= ^^and letting ^ ⊛ ^ = ^ ∗ ^^(^), Condition (3) can be written as (^ ⊛ ^ ⊛ ^)^= (^ ⊛ ^ ⊛ ^)^≈ 〈^ ⊛ ^, ^〉. (4) One can find a map ^^such that Condition (4) is strictly verified. Define ^ = ^ ⊛ ^ = (^^, … , ^^) and write ^^(^) = (^′^, … , ^′^). Then, since by definition ^ ⊛ ^ = ^ ∗ ^^(^), (^ ⊛ ^)^: = (^ ∗ ^^(^))^= 〈^, ^〉 ⇐ (mod ^). (5) The left-hand side of the last equation can be rewritten as ∑^^^^ ^^ (∑^ ^^^^^,^^′^) (6) for some ^ ∈ ℤ / ^ℤ given by ℛ ^ yields a system of ^ equ ^ ^ ations,∑^^^^^,^^′^= ^^(for 1 ≤ ^ ≤ ^), from which values for ^′^, … , ^′^can be derived and, in turn, map The following public-key encryption scheme may be defined. For security reasons, quotient polynomial ^(^) is preferably restricted to cyclotomic polynomials Φ^(^). The construction however carries over for any quotient polynomial. Corresponding to ring ℤ / ^ℤ, one has ℛ^= (ℤ / ^ℤ)[^] / (Φ^(^)) with ^ = deg(Φ^). The multiplication in ℛ^is denoted by ⋅ and the corresponding convolution in (ℤ / ^ℤ)^by ∗. The ‘specialized’ convolution operator in (ℤ / ^ℤ)^is denoted by ⊛. For any two vectors ^, ^ ∈ (ℤ / ^ℤ)^, we define ^ ⊛ ^ = ^ ∗ ^^(^). With this corresponding definition of ^^, it holds by construction that (^ ⊛ ^)^= 〈^, ^〉. Key Generation: On input of a security parameter ^, define an integer ^ = ^(^) for some integer ^ and where ^ denotes Euler’s totient function, select positive integers ^ and ^ with ^|^, let Δ = ^ / ^, and define two discretized error distributions ^̂^and ^̂^over ℤ. $ Sample uniformly at random a vector ^ = (^^, … , ^^) ← {0,1}^. Using ^, select $ uniformly at random a vector ^ ← (ℤ / ^ℤ)^and form the vector ^ = ^ ⊛ ^ + ^ ∈ (ℤ / ^ℤ)^with ^ ← ^̂ ^ ^ . The plaintext space is ℳ = {0,1, … , ^ − 1}. The public parameters are pp = {^, ^, ^, ^, Δ}, the public key is pk = (^, ^), and the private key is sk = ^. Encryption: The public-key encryption of a plaintext ^ ∈ ℳ is given by ^ = (^, ^) ∈ ^^^^ = ^ ⊛ ^ + ^ ^^ ,^ ^ ^ ^. Decryption: To decrypt ^ = (^, ^), using secret decryption key ^, return ^^∗^^^^ ^ ^ mod ^ where ^∗= ^ − 〈^, ^〉. Instead of using a multiple Δ ^ of the message scalar, more generally another encoding ^^ may be used. For example, for the ring ℤ / ^ℤ, when ^ does not divide ^, one may take ^^ = ⌈^ / ^⌋ ^ or ^^ = ⌈(^ / ^)^⌋. Flooring or ceiling functions may also be chosen for the definition of ^^ , instead of the rounding function. Importantly, a ciphertext output by the previous cryptosystem has the form of an LWE- type ciphertext. Namely, it can be decrypted as an LWE ciphertext. Indeed, we can verify that a ciphertext ^ = (^, ^) satisfies ^ − 〈^, ^〉 = Δ ^ + (small noise): ^ − 〈^, ^〉 = 〈^, ^〉 + Δ ^ + ^^− 〈^ ⊛ ^ + ^^, ^〉 ^ (^))^= (^ It is useful to introduce a new vector operator. The reverse negative wrapped convolution of two vectors ^ = (^^, … , ^^), ^ = (^^, … , ^^) ∈ ℤ^is the vector ^ = ^ ⊛ ^ = (^ ⊛^^, … , ^ ⊛^^) ∈ ℤ^defined by ^ ^ ^ = ^ ⊛^^ =∑^^^^^^^^^^^−∑^ ^^^^^^^^^^^. For example, For a vector ^ ∈ ℤ^, ^ denotes vector ^ in reverse order; e.g., if ^ = (^^, … , ^^) then ^ = (^^, … , ^^). The above convolution bears its name from the classical negative wrapped convolution (a.k.a. skew circular convolution or negacyclic convolution) defined by ^ = ^ ∗ ^ where ^^=∑^ ^^^^^^^^^^^−∑^ ^^^^^^^^^^^^^^^. Indeed, it turns out that ^ ⊛ ^ = ^ ∗ ^. wrapped convolution are captured hereafter. Given three vectors ^, ^, ^ ∈ ℤ^, it holds that 1. ^ ⊛ ^ = ^ ⊛ ^ ; 2. ^ ⊛^^ = 〈^, ^〉 ; 3. 〈^ ⊛ ^, ^〉 = 〈^ ⊛ ^, ^〉 . Indeed, The first property is immediate. Since ∗ is commutative, it follows that ^ ⊛ ^ = ^ ∗ ^ = ^ ∗ ^ = ^ ⊛ ^. Now, write ^ = (^^, … , ^^), ^ = (^^, … , ^^), and ^ = (^^, … , ^^). From the definition, denoting [pred] = 1 if some predicate pred is true and [pred] = 0 otherwise, ^ ⊛^^ is expressed compactly as ∑^ ^^^(−1)[^^^]^^^[^^^]^^^^^. Plugging ^ = ^ leads to ^ ⊛^^ = ∑^ ^^^^^^^= 〈^, ^〉. 〈^ ⊛ ^, ^〉 = ∑^ ^^^(∑^ ^^^(−1)[^^^]^^^[^^^]^^^^^) ^^by Observe that the above is a specialization of the previous setting; it corresponds to ^ = 2^^^, ^(^)= ^^+ 1 with ^ = 2^, and letting ^ = (^^, … , ^^), ^^(^)= = (^^, … , ^^). This yields the following embodiment. Detailed example embodiment Equipped with the ⊛ operator, a public-key cryptosystem can now be presented. Interestingly, the encryption algorithm outputs regular LWE-type ciphertexts. As a consequence, the decryption algorithm is unchanged. Below are the descriptions of the key generation algorithm, of the encryption algorithm and of the decryption algorithm. Key Generation: On input of a security parameter ^, define an integer ^ = 2^for some ^ > 0, select positive integers ^ and ^ with ^|^, let Δ = ^ / ^, and define two discretized error distributions ^̂^and ^̂^over ℤ. $ at random a vector ^ = (^^, … , ^^) ← {0,1}^. Using ^, select uniformly at $ random a vector ^ ← (ℤ / ^ℤ)^and form the vector ^ = ^ ⊛ ^ + ^ ∈ (ℤ / ^ℤ)^with ^ ← ^̂ ^ ^ . The plaintext space is ℳ = {0,1, … , ^ − 1}. The public parameters are pp = {^, ^, ^, ^, Δ}, the public key is pk = (^, ^), and the private is sk = ^. Encryption: The public-key encryption of a plaintext ^ ∈ ℳ is given by ^ = (^, ^) ∈ (ℤ / ^ℤ)^^^with ^^ = ^ ⊛ ^ + ^^$ for a random vector ^ ← {0,1}^, and where^ ^Decryption: To decrypt ^ = (^, ^), using secret decryption key ^, return ∗ ^^ ^^^^ ^ mod ^ where ^∗= ^ − 〈^, ^〉. Correctness Let ^ = (^, ^) be the public-key encryption of ^ as returned by the encryption algorithm. Then, ^ − 〈^, ^〉 = 〈^ ⊛ ^ + ^, ^〉 + Δ ^ + ^^− 〈^ ⊛ ^ + ^^, ^〉 = Δ ^ + ^^+ 〈^, ^〉 − 〈^^, ^〉 + 〈^ ⊛ ^, ^〉 − least if |^| < Δ / 2. Security The semantic security [7] of the proposed cryptosystem is stated under the RLWE assumption [9] in ℤ^,^[^]: = (ℤ / ^ℤ)[^] / (^^+ 1). [RLWE Assumption] Given a security parameter ^, let ^, ^ ∈ ℕ with ^ a power of 2 and let $ ^ ← ^[^] / (^^+ 1) where ^ = {0,1}. Let also ^̂ be an error distribution over ℤ[^] / (^^+ 1); namely, over polynomials of ℤ[^] / (^^+ 1) with coefficients drawn according to ^̂. The ring learning with errors (RLWE) problem is to distinguish samples chosen according to the following distributions: $ $ ^^^^^← ^ ← and ^ $ ^^^^^← ^ ^ ^ ^ ^ ← The RLWE assumption posits that for all probabilistic polynomial-time algorithms ℛ, the function $ $ ← ^^^^^− ← ^^^^^is negligible in ^. Polynomials in ℤ^,^[^] are identified with their coefficient vectors in (ℤ / ^ℤ)^, and conversely. A vector ^ = (^^, … , ^^) ∈ (ℤ / ^ℤ)^corresponds to polynomial ^ = ∑^^^ ^^^^^^^^^∈ ℤ^,^[^]; the correspondence is written ^ ≅ ^. The next relation relates the corresponding operations. Let ^ = (^^, … , ^^) and ^ = (^^, … , ^^) ∈ (ℤ / ^ℤ)^. Let also ^ =∑^^^ ^^^^^^^^^and ^ =∑^^^ ^^^^^^^^^∈ ℤ^,^[^]. Then Indeed, if ∗ denotes the reverse negative wrapped convolution, it turns out that ^ = (^ , … , ^ ): = ^ ⊛ ^ = ^ ∗ ^ ^ ^^^ with ^^=∑^^^^^^^^^^^−∑^^^^^^^^^^^^^^^. Now looking at the in ℤ^,^[^] = (ℤ / ^ℤ)[^](^^+ 1) yields polynomial ^ =∑^^^ ^^^^^^^^^. Hence, we have ^ ≅ ^ or, equivalently, ^ ⊛ ^ ≅ ^ ⋅ ^. The equality ^ ⊛ ^ = ^ ⊛ ^ then follows. Back to the encryption scheme, observe that the public key pk = (^, ^ = ^ ⊛ ^ + ^) corresponds to a polynomial RLWE sample under secret key∑^^^ ^^^^^^^^^≅ ^ = (^^, … , ^^). Under the RLWE assumption, the public key as output by the key algorithm is therefore pseudo-random; e.g., indistinguishable from uniform. Regarding a ciphertext ^ = (^, ^) with ^ = ^ ⊛ ^ + ^ ^ ^ and ^ = 〈^, ^〉 + Δ ^ + ^^, consider the vector ^: = ^ ⊛ ^ + ^^for some ^^∈ ^̂^such that (^^)^= ^^. Again, it is worth noting that the pairs (^, ^ = ^ ⊛ ^ + ^^) and (^, ^ = ^ ⊛ ^ + ^^) correspond respectively to two (polynomial) RLWE samples under ‘secret key’∑^^^ ^^^^^^^^^≅ ^ and thus appear to be pseudo-random. The same is true for 〈^, ^〉 + ^^, this turns out to be the ^th component of vector ^ ⊛ ^ + ^^: 〈^, ^〉 + ^^= ^ ⊛^^ + (^^)^. It is also important that the randomness can be re-used in multiple ciphertexts provided they are all encrypted under different keys. Indeed, when the randomness is given explicitly in a ciphertext, it is readily verified that the reproducibility criterion is satisfied. The semantic security under the RLWE assumption is established by a series of hybrid games where the different RLWE samples are successively replaced with uniform samples. With the notation of above, this corresponds to ^(^) = ^^+ 1 and, letting ^ = (^^, … , ^^), ^^(^) = (^^, … , ^^). Indeed, for ^ = ^ and ^(^) = ^^+ 1, left-hand side of eq:cond2e (Υ ^ ^((∑^^^^^^^^^) ⋅ (∑^ ^^^^′^^^^^))) ^ ^ =∑^^^^^^′^^^^^thus, 0 0 … 0 1 Equating each yields ^′^^^^^= ^ or, equivalently, (^′ , … , ^′^) = (^^, … , ^^); and thus ^^(^) = (^^, … , Performance The public key expands to 2^ |^|^bits. If the component ^ of the public key is generated from a random seed, the public key only requires ^ |^|^+ ^ bits for its storage or transmission. With the example parameters this amounts to 65664 bits, or about 8.2 kB. Suppose normal distributions for ^̂^: ^̂^= ^(0, ^^^) for ^ ∈ {1,2}. For a ciphertext ^ output by the encryption algorithm, the noise variance satisfies Var(Err(^)) = Var(^^+ 〈^, ^〉 − 〈^^, ^〉) = ^^∑ ^^ ^ Var(^ ) + ^ ^^^Var(^+ ^ Var^= ^^^+ 2^ + ^^^ ^+ = ^^^+ ^ ^^^. the noise variance. With ^^= ^^= 2^^, the standard deviation of the noise in an output ciphertext is of 2^^. Larger values for ciphertext modulus ^ lead to larger gains compared to the direct approach using encryptions of 0 for the public key. In an embodiment, multiple plaintexts are encrypted. For example, for ^ = ^ and ^ a power of two, for a vector ^ = (^^, … , ^^), one can define Ψ^ℓ(^) = ((−1)[^^^^^ℓ]^^^(^^^ℓ^^^^^^))^^^^^. For such a choice for Ψ , it can plaintext ^ℓ; that is, that ^^ℓ− 〈Ψ^ℓ(^), ^〉 = Δ ^ℓ+ (small noise). It is also interesting to observe that when ^ = ^, replacing ^ℓby ^ yields Ψ^(^) = (^^)^^^^^= (^^, … , ^^); namely, Ψ^is the identity map. There are a number of possible variants that apply to the detailed example embodiment as well as to other embodiments. Instead of selecting ^|^, plaintext modulus ^ can be more generally chosen as an arbitrary positive integer < ^. In this case, a plaintext ^ is encrypted as ^ = (^, ^) with ^ = ^ ⊛ ^ + ^^and ^ = 〈^, ^〉 + ⌈^ / ^⌋ ^ + ^^or ^ = 〈^, ^〉 + ⌈(^ / ^) ^⌋ + ^^. Instead of the rounding function, flooring and ceiling functions can also be used when ^ ∤ ^. In the general case, message ^ is encoded into ^^. Another variant is to select private key ^ and / or randomizer ^ at random from another set; e.g., from {−1,0,1}^. Another variant is to rely on another vector convolution operator that is compatible with the multiplication in ℤ^,^[^]. The map ^^used above corresponds to ^^(^) = (^^, … , ^^). This can be obtained by selecting ^ = ^. A variant therefore consists in value for ^. For a general value for ^ ≠ ^, the vector ^ = (^^, … , ^^) is mapped to ^^(^) = (^^, … , ^^, −^^, … , −^^^^) For has ^^(^) = (^^^^, … , ^^, −^^). The matching specialized convolution operator is defined as ^ ⊛ ^ = ^ ∗ ^^(^) for any two vectors ^ and ^, where ∗ denotes the classical negative With this corresponding definition of ^^, it holds by construction that ^ ⊛^^ = 〈^, ^〉 for any two vectors ^ and ^, for any 1 ≤ ^ ≤ ^. Yet another variant is to consider the convolution associated with the multiplication associated with other polynomial rings, including with the multiplication in arbitrary cyclotomic rings (ℤ / ^ℤ)[^] / (Φ^(^)) with ^ = deg(Φ^). For example, if ^ = 3^then ^ = 2 ⋅ 3^^^and ^(^) = ^^+ ^^ / ^+ 1. For ^ = ^, ∗ corresponds to the multiplication in (ℤ / ^ℤ)[^] / (^^+ ^^ / ^+ 1) and ^^(^) = (^^+ ^^ / ^, ^^^^+ ^^ / ^^^, … , ^^^(^ / ^^^)+ ^^ / ^^(^ / ^^^), ^ = 〈^, ^〉 for any two vectors ^ and ^. This embodiment presents the advantage that the condition ^ being a power of two can be relaxed. For quotient polynomial ^(^) = Φ^(^), the corresponding value for ^ is given by the Euler’s totient function of ^. In the above ^ = 2^ / 3. Encrypting multiple plaintexts Multiple plaintexts may be encrypted, by encrypting them individually. For ^ plaintexts this requires ^ ⋅ (^ + 1) ⌈log^^⌉ bits for the corresponding ciphertexts. As will be described, a better way only makes use of (⌈^ / ^⌉ ^ + ^) ⌈log^^⌉ bits. This saves (^ − ⌈^ / ^⌉) ⋅ ^ ⌈log^^⌉ bits. Given an LWE dimension ^ and a convolution operator ∗ operating on ^-dimensional vectors, fix an integer ^ ∈ {1, … , ^}. This integer ^ defines a map ^^and, in turn, the matching specialized convolution as ^ ⊛ ^ = ^ ∗ ^^(^) for any two ^-dimensional vectors ^ and ^. As detailed in the previous section, this operator ⊛ gives rise to a public-key encryption scheme. With the previous notations, a plaintext ^ may be encrypted under public key (^, ^) ∈ (ℤ / ^ℤ)^^as ^^ = ^ ⊛ ^ + ^^$ for some ^ ← {0,1}^, ^ ^ ^ ← ^̂^, the mask of the ciphertext and part ^ is called the body of the ciphertext. When ^ plaintexts, ^^, … , ^^, need to be encrypted, they are first put in ⌈^ / ^⌉ bins so that each bin contains at most ^ Next, for each bin: $ 1. A fresh mask ^ is generated from a fresh randomizer ^ ← {0,1}^and a fresh noise vector ^^← ^̂ ^ ^ as ^ ← ^ ⊛ ^ + ^^; 2. The first plaintext, say ^^, is encrypted as above; namely, by adding the body ^: = ^^← 〈^, ^〉 + Δ ^^+ ^^,^for a fresh random noise ^^,^← ^̂^; 3. The remaining plaintexts in the bin (if any), say ^^, … , ^^for some ^ ≤ ^, are represented by pairs of the form {(^, ^ℓ)}^^ℓ^^where ^ is the mask generated in 1 and ^ℓ← (^ ⊛ ^)^ℓ+ Δ ^ℓ+ ^^,ℓ(for 2 ≤ ℓ ≤ L) for a fresh random noise ^^,ℓ← ^̂^and distinct indexes ^ℓ∈ {1, … , ^}\{^}. (Note that, by construction, (^ ⊛ ^)^= 〈^, ^〉.) Ciphertext (^, ^^) is an LWE format ciphertext but ciphertexts in {(^, ^ℓ)}^^ℓ^^are not. To turn them into LWE format ciphertexts the common mask ^ needs first to be converted into the corresponding mask Ψ^ℓ(^) to get the LWE format ciphertext (Ψ^ℓ(^), ^^ℓ) for some converting map Ψ^ℓ: (ℤ / ^ℤ)^→ (ℤ / ^ℤ)^. There is always such a converting map. For instance, map Ψ^ℓcan be as a linear map satisfying (^ ⊛ ^)^ℓ≈ 〈Ψ^ℓ(^), ^〉 for any vector ^ = (^^, … , ^^). An expression for Ψ^ℓcan be obtained in a way similar to what is done to derive map ^^. References [1] Mihir Bellare, Alexandra Boldyreva, Kaoru Kurosawa, and Jessica Staddon. Multi- recipient encryption schemes: How to save on bandwidth and computation without sacrificing security. IEEE Transactions on Information Theory, 53(11):3927–3943, 2007. doi:10.1109 / TIT.2007.907471. [2] Mihir Bellare, Alexandra Boldyreva, and Jessica Staddon. Randomness re-use in multi-recipient encryption schemes. In Y. Desmedt, editor, Public Key Cryptography (PKC 2003), volume 2567 of Lecture Notes in Computer Science, pages 85–99. Springer, 2003. doi:10.1007 / 3-540-36288-6_7. [3] Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène. TFHE: Fast fully homomorphic encryption over the torus. Journal of Cryptology, 33(1):34–91, 2020. doi:10.1007 / s00145-019-09319-x. [4] Léo Ducas and Daniele Micciancio. FHEW: Bootstrapping homomorphic encryption in less than a second. In Elisabeth Oswald and Marc Fischlin, editors, Advances in Cryptology – EUROCRYPT 2015, Part I, volume 9056 of Lecture Notes in Computer Science, pages 617– 640. Springer, 2015. https: / / doi.org / 10.1007 / 978-3-662-46800-5_24 doi:10.1007 / 978-3-662- 46800-5_24. [5] Junfeng Fan and Frederik Vercauteren. Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, Report 2012 / 144, 2012. https: / / eprint.iacr.org / 2012 / 144. [6] Craig Gentry, Chris Peikert, and Vinod Vaikuntanathan. Trapdoors for hard lattices and new cryptographic constructions. In Richard E. Ladner and Cynthia Dwork, editors, 40th Annual ACM Symposium on Theory of Computing, pages 197–206. ACM Press, 2008. doi:10.1145 / 1374376.1374407. [7] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. Journal of Computer and System Sciences, 28(2):270–299, 1984. doi:10.1016 / 0022-0000(84)90070-9. [8] Marc Joye. SoK: Fully homomorphic encryption over the [discretized] torus. IACR Transactions on Cryptographic Hardware and Embedded Systems, 2022(4):661–692, 2022. doi:10.46586 / tches.v2022.i4.661-692. [9] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. On ideal lattices and learning with errors over rings. In Henri Gilbert, editor, Advances in Cryptology – EUROCRYPT 2010, volume 6110 of Lecture Notes in Computer Science, pages 1–23. Springer, 2010. doi:10.1007 / 978-3-642-13190-5_1.

[0010] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. On ideal lattices and learning with errors over rings. Cryptology ePrint Archive, Report 2012 / 230, 2012. https: / / eprint.iacr.org / 2012 / 230.

[0011] Oded Regev. On lattices, learning with errors, random linear codes, and cryptography. Journal of the ACM, 56(6), Article 34, 2009. doi:10.1145 / 1568318.1568324.

[0012] Ron Rothblum. Homomorphic encryption: From private-key to public-key. In Yuval Ishai, editor, TCC 2011: 8th Theory of Cryptography Conference, volume 6597 of Lecture Notes in Computer Science, pages 219–234. Springer, 2011. doi:10.1007 / 978-3-642-19571-6_14. Figure 5a schematically shows an example of an embodiment of an encryption method 510 for encrypting a message (^^) with a public key. Method 510 may be computer implemented and comprises - obtaining (511) a public key ((^, ^)) corresponding to a public / private key pair, - obtaining (512) a scalar (^^) representing a plaintext message, - computing (513) the public key encrypted message comprising a pair of a vector (^) and a scalar (^), the computing comprising - generating (514) a bounded, random vector (^), - computing (515) the vector (^), comprising applying the bivariate vector-valued function to the first vector (^) in the public key and the random vector (^), and adding a noise vector (^^), - computing (516) the scalar (^), comprising computing the inner product of the second vector (^) in the public key and the random vector (^), adding an encoding (^^) of the plaintext message—for example, a multiple of a plaintext message scalar (^^), and adding a noise scalar (^^). Figure 5b schematically shows an example of an embodiment of a key generation method 520. Method 520 may be computer implemented and comprises - generating (521) a private key comprising a bounded, random vector (^), - generating the public key comprising a pair of vectors ((^, ^)), the generating comprising - randomly (522) generating a first vector (^) in the pair of vectors, - computing a (523) second vector (^) in the pair of vectors from the first vector and the private key (^), comprising applying a bivariate, vector-valued function (^ ⊛ ^) to the first vector (^) and the private key (^), and adding a noise vector (^). Figure 5c schematically shows an example of an embodiment of a decryption method 530 for decrypting a message with a private key. Method 530 may be computer implemented and comprises - receiving (531) an encrypted message encrypted with a public key, the encrypted message comprising a vector (^) and a scalar (^), the encrypted message being encrypted with a method for encrypting a message with a public key as in an embodiment. - obtaining (532) a private key (^) corresponding to the public key used for the encrypted message, - computing (533) a decryption element by subtracting from the scalar (^) in the encrypted message the inner product of the vector in the encrypted message (^) and the private key, obtaining the plaintext message from a result of the subtraction. For example, the result may be rounded and decoded, or may be directly decoded. In the latter case, the rounding operation is implicit in the decoding. Many different ways of executing the method are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be performed in the shown order, but the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, some steps may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started. Embodiments of the method may be executed using software, which comprises instructions for causing a processor system to perform an embodiment of method 510, 520, and / or 530. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc. The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the Internet. The software may be made available for download and / or for remote usage on a server. Embodiments of the method may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform an embodiment of the method. It will be appreciated that the presently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the presently disclosed subject matter into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in 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 of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and / or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the devices, units and / or parts of at least one of the systems and / or products set forth. Figure 6a shows a computer readable medium 1000 having a writable part 1010, and a computer readable medium 1001 also having a writable part. Computer readable medium 1000 is shown in the form of an optically readable medium. Computer readable medium 1001 is shown in the form of an electronic memory, in this case a memory card. Computer readable medium 1000 and 1001 may store data 1020 wherein the data may indicate instructions, which when executed by a processor system, cause a processor system to perform an embodiment of a method for key generation, encryption and / or decryption, according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 comprises instructions for causing a processor system to perform an embodiment of said method for key generation, encryption and / or decryption. Figure 6b shows in a schematic representation of a processor system 1140 according to an embodiment of a key generation device and / or encryption device and / or decryption device. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Figure 6b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and / or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and / or contact-less communication, using an antenna and / or connectors, respectively. For example, in an embodiment, processor system 1140, e.g., the key generation device and / or encryption device and / or decryption device may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non-volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software. While system 1140 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processing unit 1120 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform elements or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the system 1140 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 1120 may include a first processor in a first server and a second processor in a second server. It should be noted that the above-mentioned embodiments illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb ‘comprise’ and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article ‘a’ or ‘an’ preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of” when preceding a list of elements represent a selection of all or of any subset of elements from the list. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The presently disclosed subject matter may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In the device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. In the claims references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.

Claims

CLAIMS Claim 1. A method (510) for encrypting a message (^) with a public key, comprising - obtaining (511) a public key ((^, ^)) corresponding to a public / private key pair, the key pair being computable by a key pair generation method comprising - obtaining (521) a private key comprising a bounded, random vector (^), - generating the public key comprising a pair of vectors ((^, ^)), the generating comprising - randomly (522) generating a first vector (^) in the pair of vectors, - computing a (523) second vector (^) in the pair of vectors from the first vector and the private key (^), comprising applying a bivariate, vector-valued function (^ ⊛ ^) to the first vector (^) and the private key (^), - obtaining (512) a scalar (^) representing a plaintext message, - computing (513) the public key encryption comprising a pair of a vector (^) and a scalar (^), the computing comprising - generating (514) a bounded, random vector (^), - computing (515) the vector (^), comprising applying the bivariate vector-valued function to the first vector (^) in the public key and the random vector (^), - computing (516) the scalar (^), comprising computing the inner product of the second vector (^) in the public key and the random vector (^), and adding an encoding (^^) of the plaintext message scalar. Claim 2. A method for encrypting as in Claim 1, wherein - generating the public key comprises randomly generating a noise vector (^), and computing the second vector (^) comprises adding the noise vector (^) (^ = ^ ⊛ ^ + ^), and / or - computing the public key encryption comprises generating a first noise vector (^^), and a second noise scalar (^^), computing the vector (^) comprises adding the first noise vector (^^) (^ = ^ ⊛ ^ + ^^), and computing the scalar (^) comprises adding the second noise scalar (^^) (^ = 〈^, ^〉 + ^^ + ^^). Claim 3. A method for encrypting as in any of the preceding claims, wherein a predefined index (^) of the output of the bivariate, vector-valued function applied to a first vector (^) and a second vector (^) equals the inner product of first vector (^) and a second vector (^) ((^ ⊛ ^)^= 〈^, ^〉) Claim 4. A method for encrypting as in any one of the preceding claims, wherein the bivariate, vector-valued function (⊛) is obtained from a convolution (∗) and a univariate function (φ^), the bivariate function for a first vector (^) and a second vector (^) being defined as the convolution applied to the first vector and a vector obtained from the univariate function applied to the second vector (^ ⊛ ^ = ^ ∗ φ^(^)).Claim 5. A method for encrypting as in Claim 4, wherein the univariate function is linear and defined by the predefined index and the convolution. Claim 6. A method for encrypting as in Claims 4 or 5, wherein the convolution is derived from a quotient polynomial (^), wherein the convolution applied to a first vector and a second vector is obtained by mapping the first and second vector to a first polynomial and a second polynomial, multiplying the first and second polynomials, and reducing the so-obtained polynomial modulo the quotient polynomial (^), and mapping the result to a vector. Claim 7. A method for encrypting as in Claim 6, wherein the quotient polynomial is ^^+ 1. Claim 8. A method of encrypting as in any of the preceding claims, wherein the bivariate, vector- valued function is defined for two vectors ^ = (^^, … , ^^), ^ = (^^, … , ^^) ∈ ℤ^as the vector ^ = ^ ⊛ ^ = (^ ⊛^^, … , ^ ⊛^^) ∈ ℤ^defined by^^^^^^^^^^^.Claim 9. A method of encryption as in any of the preceding claims for encrypting multiple messages (^^) with a public key, - obtaining multiple scalars (^^) representing multiple plaintext messages, - computing once the vector (^) of the public key encryption, - applying the bivariate, vector-valued function (^ ⊛ ^) to the second vector (^) and the random vector (^), wherein one component of the resulting vector is the inner product of the second vector (^) in the public key and the random vector (^), - computing an encoding (^^ℓ) for each of the multiple scalars (^ℓ) - encrypting the multiple scalars comprises adding distinct components of the resulting vector to different ones of the encoded scalars (^ℓ← (^ ⊛ ^)^ℓ+ ^^ℓ+ ^^,ℓ), wherein ^^,ℓis a possible noise value. Claim 10. A method of encrypting as in any of the preceding claims, wherein a bounded vector has bounded elements, wherein the elements - are binary, or - are ternary. Claim 11. A method as in any one of the preceding claims, wherein - the dimension of the vectors is a power of 2, or - the dimension of the vectors is 2 times a power of 3, and / or - the dimension of the vectors is ^(^) wherein ^ denotes Euler’s totient function for some integer ^. Claim 12. A method as in any one of the preceding claims, wherein the vector (^) and / or the scalar (^) in a public key encryption,- are defined over the ring ℤ / ^ℤ, the public encryption being an LWE ciphertext over ℤ / ^ℤ, or - are defined over the discretized torus ^^, the public encryption being an LWE ciphertext over ^^, or - are defined over the real torus ^, the public encryption being an LWE ciphertext over ^. Claim 13. A method of encrypting as in any of the preceding claims, wherein the bivariate, vector- valued function satisfies the constraint that decrypting an encrypted message provides the original message. Claim 14. A method of encrypting as in any of the preceding claims, wherein - the bivariate, vector-valued function is linear in both inputs. Claim 15. A method of encrypting as in any of the preceding claims, wherein the first and second vector (^, ^) in the public key have elements in the set of integers modulo a number ^ (ℤ / ^ℤ), the message scalar is chosen from the set of integers modulo a number ^, with ^ > ^, the encoding is multiplying the plaintext message scalar (^) times a rounding of ^ / ^, or is rounding the multiplication of the plaintext message scalar (^) times ^ / ^. Claim 16. A homomorphic calculation method, comprising - receiving an encrypted message, the encrypted message being obtained by encrypting a plaintext message with a public key according to an encryption method as in any of the preceding claims, - performing a homomorphic calculation upon the encrypted input data at a server computer, obtaining a public-key encrypted output data. Claim 17. A method (530) for decrypting with a private key a message encrypted with a public key as in any of the preceding claims, comprising - receiving (531) an encrypted message encrypted with a public key, the encrypted message comprising a vector (^) and a scalar (^), - obtaining (532) a private key (^) corresponding to the public key used for the encrypted message, - computing (533) a decryption element by subtracting from the scalar (^) in the encrypted message the inner product of the vector in the encrypted message (^) and the private key, obtaining the plaintext message scalar from the result of the subtraction. Claim 18. A method for decrypting with a private-key multiple messages encrypted with a public key as in any of Claims 9-15, comprising - receiving an encrypted message encrypted with a public key, the encrypted messages comprising a vector (^) and multiple scalars (^ℓ),- converting the vector (^) to multiple LWE-type ciphertexts ((Ψ^ℓ(^), ^ℓ)), comprising applying a converting map (Ψ^ℓ) to the vector, - decrypting each LWE-type ciphertext as in Claim 17. Claim 19. A system comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations for a method according to any of the preceding claims. Claim 20. A non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform operations according to any of Claims 1-18.

Images