Homomorphic evaluation of pseudorandom function

Abstract

Some embodiments are directed to a server device configured for homomorphically evaluating a pseudorandom function, and a client device for evaluating the same pseudorandom function in standard computation. For example, in an application data is encrypted by the client device by adding a stream of pseudorandom values to it. The server device can transcipher such data to FHE encrypted data.

Description

[0001] HOMOMORPHIC EVALUATION OF PSEUDORANDOM FUNCTION TECHNICAL FIELD The presently disclosed subject matter relates to a method for a server device for homomorphically evaluating a pseudorandom function, a method for a client devicefor evaluating a pseudorandom function, a server device, a client device, and a computerstorage medium. BACKGROUND A pseudorandom function (PRF) is a deterministic function indexed by a secret key ^. On a uniform and hidden choice of ^, the PRF is indistinguishable from a function that has random outputs. PRFs are a fundamental cryptographic object with numerous applications, e.g., symmetric encryption schemes [5], message authentication [6] and more generally in standard protocols such as TLS [27, 26]. Fully homomorphic encryption (FHE) allows the homomorphic evaluation of any circuit. For example, starting with an FHE encryption of the PRF secret key and a public input, one can produce an encryption of the PRF evaluation without the FHE decryption key. Various FHE schemes exist, each with their own distinct properties. One example of an FHE scheme is TFHE / FHEW [13, 16] which has relatively large key sizes,but reasonably fast computation time. All known FHE schemes have noisy ciphertexts. Ifthe noise grows too large as a result of homomorphic computation, one can shrink the noise back down using a process known as bootstrapping. An advantage of TFHE / FHEW is that one may apply a univariate function to the plaintext while bootstrapping to shrink the noise. This is known as programmable bootstrapping (PBS). This allows efficientevaluation of circuits that can be compressed using univariate functions.We consider the problem of homomorphically evaluating PRFs. That is, given an FHE encryption of a PRF key ^, we wish to produce an encryption of a LWR-basedPRF evaluation on public input ^ using key ^. Applying FHE naively requires that thePRF be decomposed as a Boolean circuit. This will typically result in many programmablebootstrapping operations (PBS); for example, at least one PBS for each NAND gate inthe circuit. Therefore, the circuit may become very complicated. Even if such a circuit is optimized for the number of PBS operations, the circuit remains very costly to evaluate. The number of bootstraps / key-switches required for evaluation is related to the number of non-linear operations over ^. Since bootstrapping is by far the most computationally expensive aspect of FHE, one would like to limit the number of bootstraps per PRF evaluation. In order to do so, it is desirable to have a PRF evaluation circuit with a small number of gates. Additionally, limiting the depth of the circuit restricts the number of sequential bootstrapping operations which indicates efficiency given parallel processing. SUMMARY There is a need to improve the homomorphic evaluation of pseudorandom functions. Embodiments present pseudorandom functions, FHE schemes, and / orparametrization. In particular, embodiments are provided that may be implemented witha small number of sequential bootstraps. Aspects of the invention include a method for a server device for homomorphically evaluating a pseudorandom function, a method for a client device for evaluating a pseudorandom function, a server device, a client device, and a computer storage medium. 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. 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 ahomomorphic computing system, Figure 1b schematically shows an example of an embodiment of a homomorphic computing system, Figure 1c schematically shows an example of an embodiment of a homomorphic computing system, Figure 2a schematically shows an example of an embodiment of a homomorphic computing system, Figure 2b schematically shows an example of an embodiment of a pseudorandom function, Figure 2c schematically shows an example of an embodiment of a pseudorandom function, Figure 3a schematically shows an example of an embodiment of a method for a server device for homomorphically evaluating a pseudorandom function, Figure 3b schematically shows an example of an embodiment of a method for a client device for evaluating a pseudorandom function, Figure 4a schematically shows a computer readable medium having a writablepart comprising a computer program according to an embodiment, Figure 4b schematically shows a representation of a processor systemaccording to an embodiment. Reference signs list The following list of references and abbreviations corresponds to figures 1-2c, 4a-4b, and is provided for facilitating the interpretation of the drawings and shall notbe construed as limiting the claims.100-102 a homomorphic computing system110 a client device120 a server device130 a data storage device111 a processor system112 storage113 a communication interface121 a processor system122 a storage123 a communication interface131 a processor system132 a storage133 a communication interface172 a computer network210 a client device220 original data generator221, 222 original data230 an argument generator231, 232 an argument240 a pseudorandom function241, 242 a pseudorandom value not FHE encrypted245 a collision-resistant function246 a randomizing function250 combining operator251, 252 stream-cipher encrypted data260 FHE auxiliary key unit261 secret key262 a bootstrapping key310 a server device321, 322 FHE encrypted data331 a randomized ciphertext340 a pseudorandom function341, 342 a pseudorandom value FHE encrypted345 a bootstrapping algorithm350 combining operator1000, 1001 a computer readable medium1010 a writable part1020 a computer program1110 integrated circuit(s)1120 a processing unit1122 a memory1124 a dedicated integrated circuit1126 a communication element1130 an interconnect1140 a processor systemDESCRIPTION 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. Figure 1a schematically shows an example of an embodiment of ahomomorphic computing system 100. Figure 1b schematically shows an example of anembodiment of a homomorphic computing system 101. System 100 comprises a client device 110 and a server device 120. System101 further comprises an optional data storage device 130Client device 110 is configured to compute a pseudorandom value, typically a stream of pseudorandom values. Client device 110 does this by applying a pseudorandom function (PRF) to one or more arguments. Client device 110 executes the pseudorandom function using plaintext computation, also referred to as standardcomputation, without using a fully homomorphic computation scheme. Client device110’s computation of the pseudorandom function is performed on non-encrypted data producing a non-encrypted output—in this case a non-encrypted pseudorandom value. The arguments may be selected by client device 110 in a number of ways, e.g., randomly, pseudorandomly, as the output of a further function, e.g., a sequence of numbers, e.g., obtained by incrementing a seed, also known as an Initialization Vector (IV), a stream-cipher, and so on. Server device 120 is configured to compute the same pseudorandom value, likewise typically a stream of pseudorandom values. Server device 120 applies apseudorandom function to the same one or more arguments as client 110. However, serverdevice 120 executes the pseudorandom function using homomorphic computation. Although the input to the pseudorandom function, the arguments, may be received andused by server device 120 in the plain, server device 120’s computation of thepseudorandom function produces an encrypted output—in this case a pseudorandomvalue encrypted according the homomorphic encryption scheme used by client device 110and server device 120. In particular, the server device 120’s implementation of thepseudorandom function may be configured for a secret key ^ according to thehomomorphic encryption scheme. The secret key ^ is known to client device 110, butunknown to server device 120. The encrypted pseudorandom value computed by serverdevice 120 may be FHE encrypted for key ^ or for a further key ^′.The arguments may be obtained by server device 120 in a number of ways,e.g., received from client device 110, generated as the output of a further function knownto both device 110 and 120. Server device 120 may receive the arguments or a seed togenerate them, in the plain or encrypted according to conventional non-homomorphicencryption. In an embodiment, the pseudorandom function is keyed, e.g., keyed with the secret key ^. In an embodiment, the pseudorandom function is keyed, and server device 120 receives an argument or a seed to generate it in the plain from client device 110.Secret key ^ is unknown to the server device, though it may have access to keys derivedtherefrom such as bootstrapping and key-switching keys. One advantageous application of having a PRF that can be computed in theclear by a client device and homomorphically by a server device, is to transfer encrypteddata from the client device to the server device. For example, a client device may havedata in plain form, which it wishes to send to the server device while encrypted. To do this the plain data is encrypted using the PRF as a stream-cipher. Such encrypted data canbe transciphered by the server device. The concept of transciphering involves convertinga data that is encrypted in one scheme, e.g., according to a stream-cipher, into another encryption scheme, e.g., according to an FHE, in this case without decrypting the data,that is, without gaining information about the unencrypted content of the data.Since an FHE encryption of data is larger than a stream-cipher encryption ofthe same data, typically significantly so, it is advantageous that the client device can send data encrypted according to the latter. At the same time, because a server device cantranscipher the data to FHE form, the server device can perform homomorphiccomputation on the data. Accordingly, storage of such encrypted data is smaller, and network transfers faster. Optional, data storage device 130 is configured to receive from client device110 data in encrypted form, e.g., stream-cipher encrypted form, store the encrypted dataat device 130, and to later forward the encrypted data to server device 120.Communication with data storage device 130 uses stream-cipher encrypted data, so that network transfer to and from device 130 is reduced compared to FHE encrypted data. Moreover, the data storage needed at device 130 is reduced. For example, the system 100 and / or system 101 may be used to transfer datafrom a client device 110 to a server device, optionally through an intermediate data storage device. For example, the stream-cipher encrypted data could represent various typesof data. The original plain data may be stream-cipher encrypted by client device 110 andsent to server device 120. Server device 120 may transcipher the data to an FHEencryption format and perform a computation while in FHE form. The resulting computation result is still in FHE format and sent to server device 120. Below is a list of examples for using a homomorphic computation system. In these examples a client device 120 is used to encrypt data before sending it to a homomorphic calculator, e.g., such as homomorphic computing system 110. Encryption may be used, e.g., in one of the following scenarios: Healthcare applications: patient data may be encrypted by a client device. 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 maycomprise genomic data. The medical data is smaller during transport from the clientdevice to the server device due to the stream-cipher type encryption. Cloud computing: The encryption may be used to securely outsource computation to untrusted cloud providers. Computations may be performed on encrypteddata stored in the cloud, without ever having to decrypt the data. For example, a clientdevice may stream-cipher encrypt data and store it in the cloud. A server device mayaccess the data and transcipher it to FHE encrypted 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, a client devicemay stream-cipher encrypt training data and send it to a server device. The server devicemay access the data and transcipher it to FHE encrypted data. Blockchains: The encryption may be used to hide data appearing on a public blockchain. 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.For example, a client device may stream-cipher encrypt data and place it on theblockchain. A server device can access the blockchain to receive the encrypted data andtranscipher it to FHE encrypted data for further processing.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 stream-cipher encrypt sensor data before sending the sensor data to aserver device. The server device can transcipher the data to FHE format and perform a calculation homomorphically thereon. For example, such a system may be used to improve traffic flow or reduce energy consumption. Encryption of data, e.g., by combining a plaintext data with a stream ofpseudorandom values, e.g., by adding or subtracting the pseudorandom values to / fromthe plaintext data, is an important application. Nevertheless, pseudorandom functions(PRFs) are used extensively in various cryptographic applications. Below are further examples of where PRFs are used in cryptography. For example, in an embodiment, a key derivation comprises a pseudorandomfunction, e.g., to derive one or more dependent keys from a master key, or to expand ashort secret key into a longer key, e.g., for use in encryption algorithms, e.g., to derive akey from a password. For example, a Hash-Based Message Authentication Code (HMAC) maycomprise a pseudorandom function. For example, a pseudorandom function may be used for random number generation, especially within a cryptographic context, but also outside thereof. For example, the PRF may be used to derive random components needed for signature algorithms, or random numbers for simulation models. Client device 110 may comprise a processor system 111, a storage 112, and a communication interface 113. Server device 120 may comprise a processor system 121, a storage 122, and a communication interface 123. Data storage device 130 may comprise a processor system 131, a storage 132, and a communication interface 133. In the various embodiments of communication interfaces 113, 123 and / or 133, 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 and 132 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 and 132 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 112, 122 and 132 may comprise a storage interface to the non-local storage. Storage may comprise multiple discrete sub-storages together making up storage 112, 122, 132. Storage 112, 122 and 132 may be non-transitory storage. For example, storage 112, 122 and 132 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 and 132may store data in the presence of power as well as outside the presence of power such asa 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 and 130 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, a WAN, etc. The computer network may be the Internet. The devices 110, 120 and 130 may comprise a connection interface which is arranged to communicate within system 100 or outside of 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., FHE key data, e.g., bootstrapping key, optionally key-switching key, e.g., argumentsand / or seeds for generating arguments, optionally stream-cipher encrypted data, FHEencrypted computation results. The communication interface 123 may correspondingly be used to send or receive digital data. The communication interface 133 may be used tosend or receive stream-cipher encrypted digital data, and / or FHE encrypted data.Client device 110, server device 120, and data storage device 130 may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, display, touch screen, etc. The user interface may be arranged for accommodating user interaction for performing a homomorphic computation on server device 120. The execution of devices 110, 120 and 130 may be implemented in a processor system. The devices 110, 120 and 130 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 and 130 may comprise multipleprocessors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. For example, devices 110, 120 and 130 may use cloud computing. Typically, the client device 110, server device 120, and data storage device 130 each comprise a microprocessor 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 and / or 130 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, client device 110, server device 120 and data storage device 130 may comprise circuits, e.g., for cryptographic processing, and / or arithmetic processing. In hybrid embodiments, functional units are implemented partially inhardware, e.g., as coprocessors, e.g., cryptographic, or arithmetic coprocessors, andpartially in software stored and executed on the device. Figure 1c schematically shows an example of an embodiment of ahomomorphic computation system 102. System 102 may comprise multiple clientdevices; shown is client device 110. System 102 may comprise multiple server devices;shown is server device 120. System 102 may comprise multiple data storage devices shown is data storage device 130. The devices are connected through a computer network 172, e.g., the Internet. The client device 110, server device 120, and optional data storage device 130 may be according to an embodiment. Figure 2a schematically shows an example of an embodiment of ahomomorphic computing system 200. System 200 comprises a client device 210 and a server device 310. Client device 210 and server device 310 are both configured to evaluate a pseudorandom function; Client device 210 using plaintext computation and server device 310 using homomorphic computation according to an FHE scheme. In figures 2a-2c, values that are encrypted according to an FHE scheme have a patterned background. Client device 210 and server device 310 are configured to participate in an FHE scheme, e.g., server device 310 is configured for computing on encrypted data while it is encrypted; client device 210 is configured to encrypt and / or decrypt data to FHE format from plain format and vice versa. Depending on the exact FHE scheme used, the device may exchange key material at some point before server device 310 evaluates thePRF. The key material derived from the main FHE secret key ^ is referred to as theauxiliary key material. For example, the auxiliary key material to generate the auxiliary key material from key 261 according to the FHE scheme. For example, the auxiliary key material may include bootstrap key(s), and / or key-switching key(s). Accordingly, client device 210 comprises an FHE auxiliary key unit 260. Unit260 is optional as the auxiliary keys may be computed elsewhere. For example, client device 210 may obtain a secret key 261, ^, for the FHEscheme. Using the secret key, FHE data may be decrypted or plain data encrypted. Secret key 261 is known to device 210, but secret from device 310. For example, client device 210 may generate the key randomly, or may retrieve the key from a storage. For example, in an embodiment, secret keys are vectors of ring elements(^^, … , ^^) ∈ ^^ . For example, the ring may be a polynomial ring ^, typically ^ =ℤ[^] / (Φ(^)), e.g., a cyclotomic ring where Φ(^) has degree ^. For example, ring ^may be ℤ modulo a modulus.For example, the message space may be ^^ for a modulus ^ < ^, where ^^denotes the ring ^ with its coefficients / entries reduced modulo ^. A ciphertext may havethe form: mod ^) (7)where ^^, … , ^^ ↩ ^ ↩ ^^ is a noise sampled from some distribution ^^ over ^,and ^ ∈ ^^ is the plaintext. Typically, p is a divisor of q. In an embodiment, q = p^, wherein both p and q are a power of a prime, e.g., 2 or 3. FHE auxiliary key unit may compute a bootstrapping key by selecting afurther key ^′ and encrypting the secret key ^ ∈ ^^ under the further key. The further keymay be randomly selected. The auxiliary key material, e.g., bootstrapping key and optionally key-switching key is sent to server device 310. The PRF which is evaluated at devices 210 and 310 takes as input anargument, e.g., ^, and computes an output, e.g., PRF(^). In some embodiments, the PRFis keyed by the secret FHE key ^. A pseudorandom function is a deterministic function algorithm that, for a given input, produces a seemingly random output. The PRF always produces the same output for the same input and key, yet its output appears random and indistinguishable from a truly random sequence to an observer without knowledge of the key. For FHEencrypted PRF output it is acceptable that noise and random values inherent in the FHEencrypted value are different, this may happen if the same PRF function is implementedin two different FHE implementations, e.g., using slightly different bootstrapping operations. Preferably, the output values of the PRF are uniformly distributed over its output range. For example, the client device 210 selects the argument for the pseudorandomfunction and sends the argument to the server device 310, wherein the argument is notencrypted according to the FHE scheme. Shown in figure 2a are two arguments: argument 231 and argument 232. There may be more than 2 arguments, e.g., to encrypt a stream of data. For example, the number of arguments may be at least 2, at least 1000, at least 10000, etc. The argument is sometimes referred as ^. There are various ways in which client device 210 may select the argument. For example, the argument or arguments may be randomly or pseudorandomly selected. For example, the arguments may be output of a further function, e.g., incrementation, astream-cipher generator, a pseudorandom generator, etc. For example, an argument maybe sent to a server device by sending a seed for a generator that generates the argument.To produce a stream of pseudorandom values from our construction, the client device may generate the arguments according to predictable pattern. For example, thearguments may be x = 1, 2, 3, ... It is advisable not to repeat the same stream for the samesecret key 261. Accordingly, the stream may start from a Nonce, e.g., N, and compriseN, N + 1, N + 2, N + 3, ... Any other non-repeating stream of arguments may also be used.The sequence of arguments does not need to be random because the PRF maps any value, or any sequence of distinct values, to pseudorandom outputs. The stream may be generated from a seed. For example, as above, the streammay comprise x, g(x), g(g(x)), .... In the example above, the function ^ is incrementationby 1. Other options may be used. Preferably, a function is used that avoids that thearguments predictably repeat, e.g., an increasing function. Afurther option is to use a stream-cipher to generate the stream of arguments.In an embodiment, the security of the system is derived from generally accepted hardness principles, but as a further precaution the stream of arguments may itself be generated in a pseudorandom fashion. Stream-ciphers which may be used to generate a pseudorandom stream of arguments include: Salsa20 / ChaCha, AES in Counter Mode (AES-CTR), Rabbit, etc. When generating arguments using a stream-cipher there is a chance ofrepeating arguments, though the probability of this happening may be made small enough given an application’s security requirements by choosing a larger block size of the stream- cipher’s outputs. It should be emphasized that using a stream-cipher is not necessary to generatethe arguments to the PRF. As the PRF maps a predictable sequence of numbers, e.g., by incrementing a seed or the like, to an unpredictable sequence. Accordingly, it is not needed to choose unpredictable arguments. Nevertheless, this is an option for additional security. Server 310 receives from client 210 the arguments, e.g., arguments 231 and 232 for the pseudorandom function, wherein the argument is not encrypted according tothe FHE scheme. The argument may be received through an intermediary such as storagedevice 130. The arguments may be encrypted using non-FHE cryptography, e.g., using aconventional encryption, e.g., using symmetric or asymmetric encryption. If thearguments are transferred in encrypted form, they are decrypted by device 310 so thatthey are available in plain format. Although arguments may be transferred in encrypted form, this is notnecessary. As PRF 240 and 340 are keyed, the pseudorandom values generated by it arestill unpredictable, even if the input arguments are known. Both client device 210 and server device 310 compute pseudorandom values by applying the PRF to the arguments. In case of device 210, pseudorandom values, ofwhich pseudorandom values 241 and 242 are shown, are computed by applyingpseudorandom function 240 to the argument, of which arguments 231 and 232 are shown.This computation is a standard, plaintext computation. The PRF 240 of device 210 corresponds to a PRF 340 of device 310, except that PRF 340 produces its outputs encrypted according to the FHE scheme. The function that is evaluated by server device 310 depends on FHE operations performed by server device 310, in particular the bootstrapping operations(s)and a collision-resistant function used to compute an initial ciphertext on which the PRF340 computes. In particular, given PRF 340 the PRF 240 may be defined as the corresponding algorithm that operates on plaintext values instead on FHE encrypted values. As discussed herein, some choices for the PRF 340 are particularlyadvantageous. For example, because the corresponding PRF 240 can be proven securebased on accepted hardness assumptions, and / or because PRF 340 is particularly efficient to compute in the FHE scheme, e.g., has a bootstrapping depth of 1, 2, or 3. Thebootstrapping depth is the number of bootstrapping operations evaluated in a parallelizedcomputation. Figure 2b schematically shows an example of an embodiment of apseudorandom function 240.Given an argument, e.g., argument 231, server device 310 applies a collision- resistant function 245 to the argument. The output of collision-resistant function 245 is used to fill at least part of the elements of a randomized ciphertext 331, also referred to as ^. The ciphertext 331 is indicated with a patterned background, as it has the form of anFHE encryption. Note though, that ciphertext 331 was not obtained by encrypting anyparticular plaintext. Accordingly, ciphertext 331 will likely have very high noise, probably near the maximum noise possible. For the collision-resistant function a cryptographic hash function may be used, e.g., a hash from the sha-3 family. For example, using TFHE type ciphertext, of the form (^^, … , ^^, ^) , part ofthe collision-resistant function output may be used to assign values to any of these components. In particular, in an embodiment, all or at least multiple of the values ^^are derived from the collision-resistant function output. Parts that are not assigned may be given a fixed value. For example, in an embodiment the randomized ciphertext has the form(^^, … , ^^ , ^), wherein all of ^^ and ^ are derived from the collision-resistant functionoutput. For example, in an embodiment the randomized ciphertext has the form:(^^, … , ^^ , ^), wherein all of ^^ are derived from the collision-resistant function output,but wherein ^ is fixed, in particular it may be 0. For example, the randomized ciphertextmay be (^^, … , ^^ , 0) .For example, a part of the collision-resistant function output may be evaluatedmodulo a modulus, e.g., mod ^, to obtain values in If the elements of a ciphertext in the chosen FHE are polynomials, then the polynomial coefficients may be generated in the same manner. Typically, an FHE ciphertext like TFHE comprises a vector of components the value of which or at least multiple of which may be chosen as indicated. Next the server device 310 performs a bootstrapping operation 345 on the randomized ciphertext 331, e.g., applies the bootstrapping algorithm of the FHE scheme. This has the effect of reducing the noise of randomized ciphertext 331 back to levels that are acceptable in the FHE scheme, so that the resulting FHE ciphertext may be regarded as a proper FHE encryption. In an embodiment, the output of bootstrapping 345 is used directly as the FHE encrypted pseudorandom value 341. However, in other embodiment, encrypted pseudorandom value 341 is derived from the FHE encrypted output of bootstrap 345. For example, FHE calculations may be performed on the output, e.g., to adjust a range of the number. For example, further bootstrappings may be performed to tailor PRF 340 to a particular desired PRF 240. The output of a bootstrapping operation is normally encrypted under a different key than the FHE secret key ^, e.g., under a further secret key ^’. Sometime this is undesirable. For those cases, a key-switching operation may be performed as usual inFHE, to transcipher the encrypted value back to FHE secret key ^, or any other key ^’’ asdesired. Such a key-switching operation typically uses a key-switching key obtained atthe server from the client. For example, when apply multiple bootstrapping, e.g., to obtain more complicated functions ^, a key-switching back to a common key, in particular,secret key ^ is convenient.On the other hand, sometimes there is no objection to keeping thepseudorandom value encrypted under ^’. In such cases, the transciphering to ^ may bedelayed or even avoided. A bootstrapping operation is keyed, e.g., depends on the secret key ^, eventhough ^ is not available to server device 310. Furthermore, the bootstrapping may beprogrammable, e.g., evaluates a function ^ on the input to the bootstrapping in additionto reducing noise levels. Embodiments may select a particular function ^ in order toachieve a particular PRF 240. In particular, the combination of the mapping from argument 231 to ciphertext 245, the bootstrapping operation, and in particular its programmed function ^, and optional further derivation (not separately shown in figure 2b), together define themapping from argument 231 to pseudorandom value 341. The same function may beevaluated in plaintext computation, thus defining a mapping from argument 231 to pseudorandom value 241. The mapping may be selected to have various properties. For example, the mapping may be configured to map arguments drawn from a uniform distribution to values that are likewise drawn from a uniform distribution. Figure 2c schematically shows an example of an embodiment of apseudorandom function 240 for use in client device 210. Argument 231 is mappedthrough a collision-resistant function 245, which is the same function as used by server device 310 to the same randomized ciphertext. However, in PRF 240, a randomizingfunction 246 is applied to the randomized ciphertext. Randomizing function 246 usessecret key ^, 261, to compute the result of bootstrap 345, and any optional further FHE operations, but in plaintext computation, thus resulting in plaintext pseudorandom value 241. Pseudorandom value 241 is equal to the FHE decryption of pseudorandom value 341. In an embodiment, pseudorandom function 240 is configured for applyingcollision-resistant function 245 to the argument, filling at least part of the elements of arandomized ciphertext 331 with the output of the collision-resistant function, decryptingthe randomized ciphertext using the secret key 261, ^, and deriving the pseudorandomvalue from the decryption. For example, deriving the pseudorandom value may comprise applying the functions for which bootstrap operations are configured in PRF 340 to the decrypted value. Returning to figure 2b. If the FHE scheme is a TFHE scheme havingciphertexts of the form (^^, … , ^^ , ^), and keys of the form (^^, … , ^^), then the bootstrapoperation will have the form In other wo the bootstrapped value will depend on the dot product ^^ ⋅ ^ mod ^.It was an insight of the inventors that such values can be made to have randomnessproperties like pseudorandom functions. In fact, making intelligent choices for thefunction ^, this property may be used to evaluate a PRF which can be proven secure basedon accepted hardness assumptions. Even if ^ is selected as fixed, e.g., as 0, apseudorandom function is still obtained. Even some, though not all, e.g., a minority, ofthe ^^may be given a fixed value. In particular, in an embodiment, an encrypted data item according to the FHEscheme (e.g., (^^, … , ^^ , ^)) comprises a tuple numbers and / or polynomials in a ring,including a masking tuple (e.g., ^ = (^^, … , ^^)), and a masked message (e.g., ^ =(^, ^) + ^ + Δ ⋅ ^, for secret key ^ comprising a tuple of masking numbers and / orpolynomials in a ring, dot product (^, ^), noise ^, message ^, and multiplier Δ), and / or- wherein the randomized ciphertext ((−^, ^); (−^, 0)) is regarded as theFHE encryption of a value depending on the dot product (^, ^), (e.g., ⌈(〈^, ^〉 mod ^) / Δ⌉),where ⌈⋅⌉ denotes a rounding function.For example, given a desired PRF 240 that depends on the dot product(〈^, ^〉 mod ^) may be decomposed into a sequence of one or more programmablebootstrapping operations. The programmable bootstrappings in the sequence being configured to provide the desired pseudorandom function in composition when performed on the randomized ciphertext. This may be used to form the naturally appearing dot product into a desired function, e.g., one for which hardness can be related to hardness criteria. In an embodiment, the function for which bootstrap 345 and possibly further bootstrap operations are configured may be negacyclic. In some FHE schemes, e.g., TFHE, negacyclic are easier to evaluate. Decomposing a desired function into one or more negacyclic bootstrap operations is efficient. In particular a function 240 may be decomposed in a function decomposition of multiple bootstraps, one or all of which may be negacyclic. Below some specific examples are given. In an embodiment, the bootstrapping algorithm may be configured for the ^)⌋, and the pseudorandom function is mod ^)⌋ mod ^.In an embodiment, the bootstrapping algorithm is configured for the function ⋅ (^ mod ^)⌋ +^ ^^ mod ^, and the pseudorandom function In an embodiment, the pseudorandom function is ^^^^(^) ≔ ⌈(^ / 2^) ⋅(〈^, ^〉 mod 2^)⌋, the function ^(^) = Δ ⋅ ⌈^ / Δ⌋ being decomposed over twobootstrapping applications. However, each of the examples can be varied considerably. In an embodiment, the PBS or multiple PBS, e.g., composition of multiple PBS, are configured for a function ^, wherein the resulting PRF is indistinguishable from random under the LWE assumption. However, even if the randomness is not fully equivalent to the LWEassumption, the output will still be highly random. For example, the function ^ may havea uniform output distribution, wherein the outputs of ^ are distributed uniformly acrossits range. For efficient implementation furthermore a negacylic ^ may be used.In an embodiment, the function for which bootstrap 345 and possibly furtherbootstrap operations are configured may map a range (e.g., ℤ^^; ℤ^) of the argument (e.g.,^) to a ring for the elements of encrypted data items according to the FHE scheme (e.g., ℤ^). For example, under FHE encryption a value may be added or subtracted. In an embodiment, the function for which bootstrap 345 and possibly further bootstrap operations are configured may comprise a scalar multiple of the argument or the argument modulo a modulus. In an embodiment, the function for which bootstrap 345 and possibly further bootstrap operations are configured may be the function and the pseudorandom function is ^^^^(^) = (−1)^^^(〈^,^〉 ^^^ ^^) ⋅(〈^, ^〉 mod ^)⌋ mod ^.In an embodiment, the function for which bootstrap 345 and possibly further bootstrap operations are configured may be the function and the pseudorandom function is ^^^^(^) = ⋅(〈^, ^〉 mod ^)⌋ +^ ^ ^ ^^ +^ − ^. In an embodiment, the function for which bootstrap 345 and possibly furtherbootstrap operations are configured may be the pseudorandom function is ^^^^(^) ≔⌈(^ / 2^) ⋅ (〈^, ^〉 mod 2^)⌋, the function ^(^) = Δ ⋅ ⌈^ / Δ⌋ being decomposed over twonegacyclic bootstrapping applications.Returning to figure 2a. Client device 210 obtains one or more pseudorandom values, shown are values 241 and 242. Server device 310 obtains one or more corresponding pseudorandom values, shown are FHE encrypted values 341 and 342. One application, for which the pseudorandom values may be used is to transfer data. There are many other applications of pseudorandom functions. Shown in figure 2a, client device 210 may obtain original data, shown areoriginal data 221 and 222; for example, these may be data blocks of the same size orsmaller as the bit size of the pseudorandom values 241, 242. The original data is plaintext data. For example, the data may be text, e.g., an email, or computer code, or multidimensional sensor data, e.g., an image, etc. Optionally, device 210 comprises an original data generator 220. Original data generator 220 is configured to generate the original data. The original data may be obtained from another source, e.g., from a user, or from another computer or the like. For example, data generator 220 may generate data based on user input, e.g., by formatting the user input. Shown is original data 221, and222. We may refer to the original, e.g., plain data as ^^, ^^, …Client device 210 generates a stream of pseudorandom values, shown arevalues 241, 242 by repeated application of the pseudorandom function, the generatedstream being unencrypted at device 210. For example, the pseudorandom function maybe applied to a stream of arguments. We can refer to the pseudorandom values as ^^, ^^, …(not to be confused with the randomized ciphertext mentioned earlier). To encrypt original data, client device 210 may combine the pseudorandom values in plain form with the corresponding original data. The combining may be addition, e.g., modular addition.For example, the encrypted original data may be ^^ = ^^ + ^^, ^^ = ^^ + ^^, … Shownare encrypted data 251, and 252. The encrypted data 251, 252 is sent to server device 310,possibly through an intermediary. Client device 210 may comprise a combiner 250 for this purpose. Server device 310 generates a stream of pseudorandom values, shown arevalues 341, 342 by repeated applications of the pseudorandom function, the generatedstream being FHE encrypted at device 310. For example, the pseudorandom function maybe applied to a stream of arguments, which is the same stream as used in device 210. Wecan still refer to the pseudorandom values as ^^, ^^, … But note that now they are FHEencrypted. To decrypt the encrypted original data 251, 252, server device 310 maycombine the pseudorandom values in encrypted form with the corresponding encrypted original data. The combining used is the opposite of the combining used in device 210.For example, the combining may be subtracting, e.g., modular subtraction. For example,the decryption may = ^^ − ^^, ^^ = ^^ − ^^, … Shown are decrypted data 321, and322. Server device 310 may comprise a combiner 350 for this purpose. Because the pseudorandom values are FHE encrypted, the output 321, 322, is also FHE encrypted. Server device 310 may be configured to perform a further computation on FHE data 321, 322, e.g., apply a model to it, or some other computation. In an embodiment, the stream-cipher encrypted data 251, 252 is transmittedand / or stored together with information on the corresponding arguments 231, 232. For example, the information may comprise the arguments themselves, or may comprise aseed to generate them. For example, information and stream-cipher encrypted data 251,252 may both be transmitted, e.g., together, to server device 310. For example,information and stream-cipher encrypted data 251, 252 may both be stored, e.g., together,on data storage device 130, where server device 310 may obtain it. Below several further optional refinements, details, and embodiments are illustrated. Some of the embodiments are specific to particular FHE schemes, and contain additional mathematical detail, some of which is optional. For a public matrix ^ ∈ with moduli ^ and ^ such that ^ < ^ and asecret vector ^ ∈ ℤ^, the Learning-With-Rounding (LWR) problem [4] is to distinguish⌈(^ / ^) ⋅ (^^ ^ mod ^)⌋ mod ^ from a random vector in ℤ^^. The conjectured post- quantum hardness of LWR immediately implies a pseudorandom generator (PRG) whichexpands a short string ^ into a longer pseudorandom string ⌈(^ / ^) ⋅(^^ ^ mod ^)⌋ mod ^ using a public matrix ^. Given input ^ and a secret key ^ ∈ ℤ^,the PRF evaluation is defined to be ⌈(^ / ^) ⋅ (^(^)^ ^ mod ^)⌋, where the matrix ^(^) =^(^) ∈ ℤ^^×ℓis derived from a random oracle. The random oracle model is widely used in cryptography to design secure and efficient constructions [7]. A common example of a cryptographic hash function that is often modelled as a random oracle is SHA-3 [1], but other options are available. The more commonly used Learning-With-Errors (LWE) assumption

[0025] isknown to imply the hardness of LWR. If ^ is a priori bounded, there is a reduction fromLWE to LWR for a polynomial ratio ^ / ^ = ^^^^(^) where ^ is the security parameter[2, 8]. Without an a priori bound on ^ the only known reduction requires ^ / ^ = ^^(^)[4]. Aside from these reductions, one may set secure LWR parameters concretely according to the best known cryptanalytic attacks. In the following, when ^ is a distribution, ^ ∼ ^ means that ^ is a randomvariable distributed according to ^. The notation ^ ↩ ^ denotes the explicit action ofsampling an element ^ according to the distribution ^. For a finite set ^, ^(^) stands forthe uniform distribution over ^. For any ^ ≥ 2, ℤ^denotes the ring of integers withaddition and multiplication modulo ^. The notation ⌈⋅⌋ denotes the function that roundsan input to the nearest integer (rounding up in the case of a tie). If the input to this functionis a vector, it is applied component-wise. The notation ⌊⋅⌋ denotes the floor function (i.e.,the function that rounds down to the nearest integer).Hardness criteria We first recall the definition of the Learning-With-Errors (LWE) assumptionintroduced by Regev

[0025] . [LWE assumption] Let integers ^, ^ ≥ 1, ^ ≥ 2 and let ^^, ^^ be distributionsover . The ^^^^,^,^,^^,^^problem requires distinguishing between the distributionswhere ^ ∼ . When the distribution of ^ is the uniformdistribution the assumption is sometimes denoted by ^^^^,^,^,^^. We now recall the Module LWE problem

[0021] , which generalizes both LWEand ring LWE

[0023] . We let a cyclotomic polynomial of degree ^ and let the rings^ = ℤ[^] / (Φ(^)) and ^^ = ^ / (^^) for a modulus ^.[MLWE assumption] Let integers ^, ^ ≥ 1, ^ ≥ 2. Let ^^ and ^^ bedistributions over the ring ^. The Module LWE problem requires distinguishing between the distributions where The distribution for ^ issometimes chosen as the uniform distribution ^^ = We note that, when the degree^ of Φ(^) is 1, MLWE becomes the usual LWE problem in dimension ^. When ^ = 1,it corresponds to the ring LWE problem (i.e., distinguishing {(^, ^ ⋅ ^ + ^)|^ ↩ introduced in

[0023] In the general case for ^ > 1 and ^ > 1, the problem is believed to remainhard even when the secret ^ is sampled from a narrow distribution instead of beinguniform over ^^^ . For example, it was shown when ^ is a vector of integer polynomialswith uniform coefficients in a small interval

[0012] , or even with binary coefficients

[0011] . We now recall the definition of the Learning-With-Rounding (LWR) problem[4]. [LWR assumption] Let integers ^, ^ ≥ 1, ^ > ^ ≥ 2 and let ^^ be distributions overℤ. The Learning-With-Rounding (^^^^,^,^,^^) problem requires distinguishing betweenthe distributions (^^ , ⌈(^ / ^) ⋅ (^^ ^ mod ^)⌋ mod ^) and ^(ℤ ^×^^ × ℤ^^) When the number ^ of samples is a priori bounded, the LWE assumption isknown [2, 8] to imply the hardness of LWR for a polynomial ratio ^ / ^ = ^^^^(^). Whenthere is no pre-determined upper bound on the number of samples, the only knownreduction [4, Theorem~3.2] from LWE to LWR requires a super-polynomial ratio ^ / ^ =However, it is quite plausible that LWR remains hard for ^ / ^ = ^^^^(^) even foran a priori unbounded number of samples. As discussed in [4, 9], as long as ^ / ^ = Ω(√^)and ^ / ^ is an integer (so that LWR may behard even for quantum algorithms. The LWR problem naturally extends to the module setting (e.g.,

[0017] ), where it is defined as follows. [MLWR assumption] Let integers ^, ^ ≥ 1, ^ > ^ ≥ 2. Let Φ(^) acyclotomic polynomial of degree ^ and let the rings ^ = ℤ[^] / (Φ(^)) and ^^ =^ / (^^). Let ^^a distribution over ^. The Module LWR problem requires distinguishing between the distributions MLWR, the “nearest integer”rounding function ⌈⋅⌋ can be replaced by other random functions (like the floor ⌊⋅⌋ orceiling ⌈⋅⌉ functions) without impacting the difficulty of the problem. The floor-roundingvariant was notably used in

[0014] . Pseudorandom Functions based on the (Ring / Module) Learning-With- Rounding Problem Aweak pseudorandom function may be based on the hardness of the LWRproblem. This weak PRF maps a random input ^ ∈ to the output ^^^^^(^) =⌈(^ / ^) ⋅ (〈^, ^〉 mod ^)⌋ mod the secret key.By introducing a random oracle ^: {0,1}ℓ the aforementioned weakPRF can be turned into a full PRF by computing ^ = ^(^) ∈ ℤ^^when the PRF has to beevaluated on an arbitrary input ^ ∈ {0,1}ℓ. It is precisely defined as follows.The secret key is a vector ^ = (^^, … , ^^) ∼ where each ^^is sampled from a distribution ^^specified by public parameters. These public parameters also contain thedescription of a hash function (modelled as a random oracle) and twomoduli ^ and ^ where ^ divides ^. Typically, for LWR-based constructs, ^^ is the uniformdistribution over Alternatively, ^^can be a discrete Gaussian distribution with a suitable standard deviation ^. For our purposes, in an embodiment, we assume that ^^has a support significantly smaller than for the secret keys to be compatible with different moduli. For example, we could take ^^to be the uniform distribution over binary vectors. A function evaluation is then defined as ^↦ ^^^^(^) ≜ ⌈^ ^⋅ (〈^(^), ^〉 mod ^)⌋ mod ^ (1)and outputs a scalar in ℤ^. To output ^ pseudorandom elements in ℤ^, we can extend itas ^↦ ^^^^(^) ≜ (^^, … , ^^) where ^^ = ⌈^ ^⋅ (〈^(^, ^), ^〉 mod ^)⌋ mod ^ ∀^ ∈ {1, … , ^}.Alternatively, we can use a random oracle ^: {0,1}ℓ → that outputs a matrix, for a large enough ^, and define ^↦ ^^^^(^) ≜ ⌈^ ^⋅ (^(^) ⋅ ^ mod ^)⌋ mod ^ (2)which outputs pseudorandom vectors over ℤ^^. It is possible to remove the random oracle and replace ^(^) by a differentencoding of the input. For example, Banerjee and Peikert [3] encode the input ^ = decomposition function that inputs a matrix ^ ∈ ℤ^×^⌈^^^^⌉ ^ and outputs a binary^^^(^) ∈ {0,1}^⌈^^^^⌉×^⌈^^^^⌉. Using this encoding, Banerjee and Peikert [3] define thePRF ^↦ ^^^ (^) ≜ ⌈^⋅ (^ ^^^(^) ⋅ ^ mod ^)⌋ mod ^ (4)In

[0010] , Boneh et al. considered another encoding that maps the input ^ = which is also used to define ^^^^^^(^) ≜ ⌈^⋅ (^(^) ⋅ ^ mod ^)⌋ mod ^. For thisencoding of the input, the secret key ^ ∼ is required to be a uniformover ℤ since it is multiplied by small-norm matrices ^^^(^^^) ∈ contrast, the encoding of Banerjee and Peikert (3) allows a small-norm ^. The security proofs of [10, 3] require the ratio ^ / ^ to be super-polynomial(or even exponential in the input length ^ / ^ = 2^(ℓ) in the case of

[0010] ). Here, we cannotefficiently evaluate them using programmable bootstrapping for a super-polynomial^ / ^ = ^^(^) since it would require lookup tables of super-polynomial size. However, wecan do it if we heuristically rely on the pseudorandomness of these PRFs for parameterssuch that ^ / ^ = poly(^). In these parameter regimes, the security proofs of [10, 3] donot work any longer but no attack has been reported as long as q / p is at least Ω(n^ / ^)where n is the dimension of ^. In the ring setting, we can also consider a variant implicitly suggested in [4].Namely, let the polynomial rings ^^ = ^ / (^^) where ^ = ℤ[^] / (Φ(^)) for somecyclotomic polynomial Φ(^) of degree ^, one can use a hash function ^: {0,1}ℓ → ^^that ranges over ^^ = ^ / (^^). Then, the ring-LWR assumption yields the PRF family mod ^)⌋ mod ^ (5)where the secret key is ^ ∈ ^ and ^(^) ⋅ ^ mod ^ is a product of polynomials in ^^. Inthis case, the output value of (5) lives in ^^ = ^ / (^^), which is isomorphic to ℤ^^ifdeg(Φ(^)) = ^. A single output element can thus live in an exponentially large space.Using the module-LWR assumption, one can also combine the ideas of (6)and (5). If we use a hash function ^: {0,1}ℓ → ^^×^ ^^ , we choose a secret key ^ ∈ ^which defines the PRF ^↦ ^^^ (^) ≜ ⌈^⋅ (^( ^^^^) ⋅ ^ mod ^)⌋ mod ^ (6)which ranges over ^^^. When proving the pseudorandomness of these PRF families (in the random oracle model), we may use an instance of LWR (or ring / module-LWR) where the numberof samples is not a priori bounded since each queried input ^ is mapped to a differentsample (i.e., the number of samples is as large as the number of evaluation queries). Therefore, in an embodiment, we choose a super-polynomial ^ / ^ = ^^(^) ifwe want to rely on known LWE-to-LWR reductions [4]. In practice, one may prefer amore efficient choice of parameters with ^ / ^ = ^^^^(^) and rely on the plausiblehardness of LWR in this parameter regime. In this case, in an embodiment, one may set^ / ^ as an integer larger than Ω(√^) if ^ is the dimension of ^.In [4, 9], LWR was conjectured to be exponentially hard when ^ / ^ = Ω(√^)and assuming uniform secret keys (i.e., ^^ = ^(ℤ^)). In order to homomorphicallyevaluate the PRF using programmable bootstrapping, it is more convenient to sample theseed ^ from a binary or ternary distribution. Fortunately, even for the uniform binarydistribution ^^ = ^({0,1}), an estimate of the lattice hardness gives more than 128 bitsof security for an unbounded number of samples when ^ and ^ are small. For ^ = 2^^and ^ = 16 with ^ = 1024, the estimator gives about 373 bits of security. Even if we set^ = 4096 = 2^^ and ^ = 16, the best attack found by the estimator takes 2^^^ time.Lattice hardness use the approach in: Martin R. Albrecht, Rachel Player, and Sam Scott,Volume 9, Issue 3, Pages 169–203, ISSN (Online) 1862-2984, ISSN (Print) 1862-2976 DOI: 10.1515 / jmc-2015-0016, October 2015, “On the concrete hardness of Learning with Errors.”, included herein by reference. First series of detailed embodimentsThe goal is to homomorphically evaluate a PRF based on the difficulty of the (Module) LWR problem, which is now a well-established assumption in lattice-based cryptography. We aim to homomorphically evaluate either one the original PRFsdescribed above or, alternatively, a modified PRF that is guaranteed to be as secure asone of those described above. A general construction may have the following features and properties. •It assumes a polynomial ring ^, typically ^ = ℤ[^] / (Φ(^)) is a cyclotomicring where Φ(^) has degree ^.• It works for an FHE scheme where secret keys are vectors of ring elements(^^, … , ^^) ∈ ^^ . If the message space is ^^ for a modulus ^ < ^, the secret-key variantof the FHE scheme has ciphertexts of the form where ^^, … , ^^ ↩ ^^ is a noise sampled from some distribution ^^ over ^,and ^ ∈ ^^ is the plaintext. Typically, ^|^, or even ^ = both ^ and ^ could bepowers, e.g., of 2 or 3. •The FHE scheme has a bootstrapping algorithm ^^^^[^](^^, ^^) that allowsevaluating a function ^: ^^ → ^^ such that, on input of a ciphertext (^^, … , ^^ , ^) of theform (7) for a (possibly very large) noise ^, the bootstrapping algorithm outputs a ciphertext for a small noise ^′ ∈ ^ such that |^′| ≤ ^ for some ^ ≪ ^ and a secret key(^^^, … , ^′^^) ∈ ^^^ that may be different from (^^, … , ^^).• It assumes that the PRF secret key is a vector ^ ∈ ^^ encrypted by a ciphertextbsk that can be seen as a bootstrapping key for the FHE scheme. For example, a clientdevice may choose plain secret keys ^, and ^’ and compute bsk = encryption^’ (s) . Theclient may also compute key-switching keys if needed. • If the input space of the PRF is {0,1}ℓ, the general construction uses acollision-resistant function ^ ℓ ^×^ ℓ^: {0,1} → ^^ that maps an input ^ ∈ {0,1} to an input-dependent matrix ^(^) = ^^(^) ∈ ^^^×^. Namely, given the description of ^^it shouldbe computationally infeasible to find distinct ^, ^′ such that ^(^) = ^(^′) if they exist atall. •It also uses a function ^ : {0,1}ℓ → ^^ that maps a ℓ^ ^ n input ^ ∈ {0,1} to a ringelement ^^. We make no specific requirement on ^^(in particular, it can be a constant function). •The function ^: ^^ → ^^ defined at item (3) should satisfy the property that,for any input ^ ∈ {0,1}ℓ, the distribution mod ^))^)} is computationally indistinguishable from where ^(^^^ ) denotes the uniform distribution over ^^^ . Note that this would also workif ^ is not negacyclic.The homomorphic PRF evaluation algorithm then proceeds as follows in apossible embodiment. ^^^^^^(bsk, ^): Given public parameters pp = (^, ^, ^, ^), an evaluation keybsk and an input ^ ∈ {0,1}ℓ, compute (a) For each ^ ∈ [^], compute (b) Output the evaluated ciphertext (ct^, … , ct^), where ct^ ∈^^^^^ for each ^ ∈ [^].Various other embodiments may be obtained by taking particular choices for the objects defined above, e.g., parameters, rings, dimensions, etc. At step 1, if we define Δ = ^ / ^ and assume that Δ divides ^, we note that eachciphertext (^^ , ^^ ) ∈ ^^^^^can be written⋅ ^^ + Δ ⋅ ⌈^(^^^ − ^^ ∑^^ ^^^ ^ ^^^,^ ⋅ ^ ^^^ m ^o^d^^ ^^)^ / Δ^⌋≜ ^^⋅ ^ ^^ m ^^o^d^ ^^)^ m^o^d^ Δ^) mod ^) (9)≜ ^^by decomposing ^^ − ∑^ ^^^ ^^ ⋅ ^^ mod ^ into a quotient ^^ and a remainder ^^ ∈ ^(interpreted as a polynomial with coefficients in [−Δ / 2, Δ / 2)) via an Euclidean divisionof each coefficient over ℤ. Since ^^,^ ⋅ ^^ mod ^ = Δ ⋅ ^^ + ^^, property (7) implies that thedistribution of ^(Δ ⋅ + ^^) should be indistinguishable from Δ ⋅ ^ conditionally on(^^,^, … , ^^,^, ^^).For example, if we consider the BFV FHE

[0018] (which can be obtained bysetting ^ = ^ = 1), the function ^(^) = Δ ⋅ ⌈^ / Δ⌋ is the function that performs thestandard (non-programmable) bootstrapping [18, 19] and only refreshes the input ciphertext (−^, ^ = −^ ⋅ ^ + Δ ⋅ ^ + ^ ^ ) ∈ ^^^ ∈[^^ / ^,^ / ^)by computing (^, ^) ∈ ^^^as a low-noise encryption of the same plaintext ^. Then, bysetting ^ = 0, we obtain that^ = ⌈(^ + (^ / ^) ⋅ ^ ⋅ ^ mod ^)⌋ = ⌈(^ / ^) ⋅ (^ ⋅ ^ mod ^)⌋ mod ^,so that the bootstrapping algorithm outputs a BFV encryption (^, ^) of the Ring-LWR-based PRF ⌈(^ / ^) ⋅ (^ ⋅ ^ mod ^)⌋, where ^ = ^^(^) is an encoding of the input.Second series of detailed embodiments The plaintext space is ℤ^and the ciphertext modulus is ^. It is assumed that^ divides ^ so that Δ = ^ / ^ ∈ ℤ. Furthermore, bsk denotes a bootstrapping key forTFHE / FHEW where the secret key is an LWR-based PRF seed ^ ∈ {0,1}^. The parameter^ is assumed to be a power-of-two equal to the degree of a cyclotomic polynomial. In thedescriptions hereafter, we assume that ^: {0,1}^ × {0,1}ℓ → ℤ^^is a random oracle andset the encoding of an input ^ ∈ {0,1}ℓ to be^(^) = [^^| The first argument of H may be a counter ^ whose binary representation fitswithin ^ bits. This is w.l.o.g. since we assume that the number of evaluations ispolynomial in ^.We then apply the embodiments hereafter to each column ^ ^^ ∈ ℤ^ of ^(^) soas to obtain a set of ^ LWE ciphertexts that encrypt the components of PRF^(^) =(^ / ^) ⋅ (⌈^(^)^ ⋅ ^ mod ^)⌋ mod ^. Importantly, these rows can be processed in parallelusing multiple threads so as to minimize the bootstrapping depth (i.e., the number of sequential bootstraps). Alternatively, one can encode ^ as a matrix ^(^) = ^(^) using a randomoracle ^: {0,1}ℓ → One may also use a structured matrix ^ to represent polynomialmultiplication within a ring yielding a ring / module LWR-based PRF. Yet another alternative is to use the standard-model (i.e., non-random-oracle-based) input encoding(3) suggested in [3]. In this case, we may set ^ = ^⌈log^⌉.If we just want to evaluate a weak PRF, we do not need any input encoding aswe can simply define the input to be the matrix ^ itself. A weak PRF is a PRFthat only guarantees pseudorandomness for random inputs (instead of arbitrary,adversarial-chosen inputs). Aside from the encoding variations, some embodiments also make it possible replace the rounding function with the floor or ceiling functions in the output ciphertext.The rounding function ⌈⋅⌋ is applicable to all embodiments described in the nextsubsections. However, the floor function ⌊⋅⌋ is only supported by the first twoembodiments. ^^^^[^] will refer to the TFHE / FHEW programmable bootstrappingprocedure with univariate negacyclic function ^. In the embodiments based on theprogrammable bootstrapping of TFHE / FHEW, we rely on the theorem mentioned below,which is quoted from

[0022] but is implied by earlier results on the programmable bootstrapping of LWE ciphertexts for negacyclic functions. In the notations, when ciphertext for a secret key ^ ∈ ℤ^ and a noise ^ ∼ ^^. We denote by ^^^^(^, ^) = ^ −〈^, ^〉 mod ^ the decoding function (a.k.a. phase function) which outputs a noisyencoding ^ + ^ ⌈^ / ^⌋ of the plaintext ^.We now state the aforementioned theorem. [Theorem 1] Let positive integers ^, ^ and ^ such that ^ divides ^ and ^ isset to a power of 2. There is a bootstrapping procedure ^^^^ with the following property:For any LWE ciphertext (^, ^) ∈ ℤ^^^^ and any function ^: ℤ^ → ℤ^ such that ^(^ +^ / 2) = −^(^) mod ^, the procedure ^^^^[^](^, ^) outputs a ciphertext (^, ^) ∈ ℤ^^^ ^ such that^^^^(^, ^) = ^(^^^^(^, ^)) + ^( mod ^) ,where |^| < ^, for a noise bound ^ that only depends on the operations performed by^^^^ and not on the input ciphertext (^, ^).The inventors found a way of performing homomorphic PRF evaluation using a smallnumber of sequential (i.e., low-depth) bootstrappings with functions satisfying thecondition on ^ from the theorem. Whenever we apply this theorem in depth 1 and depth2, we take ^ = ^ = 2^, where ^ is the dimension of the ring ^ = ℤ[^] / (^^ + 1) overwhich the bootstrapping key bsk operates. In depth 3, we sometimes apply this tonegacyclic functions that use other moduli. Below are three embodiments are further detailed, which are particularlyadvantageous. First embodiment For this embodiment, we use the negacyclic function ^: ℤ^^ → To analyze this embodiment, we view (−^, 0) as a highly noisyciphertext that informally “encrypts” ⌈(〈^, ^〉 mod ^) / Δ⌉. Written differently, the vector(−^, 0) is viewed as an encryption with phase 〈^, ^〉 mod ^. By Theorem 1, the ^^^^(^) ^^evaluation algorithm (which is described hereafter) outputs a ciphertext encrypting mod ^)⌋ mod ^.Note that this is not the standard LWR-based PRF. However, it is stillpseudorandom via a reduction from the pseudorandomness of a standard LWR-basedPRF. Indeed, we can prove the following result. Assume ^ = 2ℓ^ and ^ = 2ℓ^ are powers-of-two such that ^: = −1 > 0. Take a random function ^: {0,1}⋆ → (ℤ^^)^ and assume that ^^: {0,1}⋆ → ℤ^^ , mod 2^)⌋ mod 4^is pseudorandom for ^ sampled uniformly from {0,1}^. Then the function ^^^^: {0,1}∗→ ℤ^, ^^^ ^^) ⋅ ⌈^⋅ (〈^(^), ^〉 mod ^)⌋ modis pseudorandom where ^ is also sampled uniformly in {0,1}^. This embodiment describes a depth-1 bootstrapping algorithm. As a result, one may choose not to implement the key-switching element of the bootstrapping procedure. Indeed, by removing the final key-switching, we obtain an encryption of^^^^(^) under an LWE secret key which is not ^ but the (ring-)GSW secret key ^′ suchthat bsk = GSW. Enc^^(^).A summary of the algorithmic steps of this embodiment are as follows: ^^^^(^) ^^ (bsk, ^): Given public parameters pp = (^, ^, ^, ^), a bootstrappingkey bsk and input ^ ∈ {0,1}ℓ, compute the input-dependent ciphertext (−^, 0) = the following: (a) (^, ^) = ^^^^[^](−^, 0)( mod ^).(b) Output the ciphertext ct = (^, ^) ∈ ℤ^^^^. Note that, if we modify the negacyclic function (10) and replace the rounding⌈⋅⌋ by the floor function ⌊⋅⌋, we can also evaluate the floor-function analogue of the samePRF: i.e., mod ^⌋.This modified negacyclic function still satisfies our condition (7) in Section 4 because of the following lemma, which is proven in

[0015] . We note that one may also trivially replace the rounding function with the ceiling function ⌈⋅⌉. Assume ^ = 2ℓ^ and ^ = 2ℓ^ are powers-of-two such that ^: = >0. Take a random function ^: {0,1}⋆ → (ℤ ^ ⋆^^) and assume that ^^: {0,1} → ℤ^^ , mod 2^)⌋ mod 2^is pseudorandom for ^ sampled uniformly from {0,1}^. Then the function ^^^^: {0,1}∗→ ℤ^, mod ^)⌋ modis pseudorandom where ^ is also sampled uniformly in {0,1}^.Second embodiment For this embodiment, we evaluate a PRF whose range is half of the plaintext space. This is useful in cases where TFHE / FHEW is set to use a padding bit in theplaintext space. We define the negacyclic function ^′: ℤ → This embodiment concretely evaluates the function ^^^′^: {0,1}ℓ→{0, … , ^ / 2 − 1} defined by ^^^(〈^, ^〉 mod 2^),which uses the floor function ⌊⋅⌋ (recall that we assume that ^ > 4 is a power of 2, so thatthe output is well-defined). As this embodiment only requires bootstrapping depth one, we may once again choose to not implement keyswitching in the bootstrapping procedure. The algorithmic steps of this embodiment are as follows: ^^^^(^^) ^^ (bsk, ^): Given public parameters pp = (^, ^, ^, ^), a bootstrappingkey bsk and input ^ ∈ {0,1}ℓ, compute the input-dependent ciphertext (−^, 0) = the following: (a) (^, ^) = ^^^^[^′](−^, 0)( mod ^) mod ^)Output the ciphertext ct = (^, ^̅) ∈ ℤ^^^^. Since we do not homomorphically evaluate a standard LWR-based PRF we ^ ^ must prove that condition (7) is satisfied. One can show this via applying the shift ^ − ^to ^^^′′ in the following lemma: Assume ^ = 2ℓ^ and ^ = 2ℓ^ are powers-of-two suchthat ^: = + 2 > 0 (i.e. ^ > ^ / 4). Take a random fu ⋆^ nction ^: {0,1} → (ℤ^^)and assume that ^ ⋆^: {0,1} → ℤ^ / ^, mod 2^)⌋is pseudorandom for ^ sampled uniformly from {0,1}^. Then the function is pseudorandom where ^ is also sampled uniformly in {0,1}^.Third embodiment For this embodiment, we evaluate the original LWR-based PRF that wasdefined as ⌈(^ / 2^) ⋅ (〈^, ^〉 mod 2^)⌋, where the rounding function is ⌈⋅⌋. Thiscorresponds to evaluating the non-negacyclic function ^(^) = Δ ⋅ ⌈^ / Δ⌋ on the ciphertext(−^, 0).To this end, we proceed by sequentially evaluating two negacyclic functions^^ , ^^^^^: ℤ[2^] → ℤ[^] as where we set ^ = 2^. Again, we view (−^, 0) as a maximal noise TFHE encryption ofthe LWR-based PRF ⌈(^ / ^) ⋅ 〈^, ^〉 mod ^⌋ to carry out the analysis. Note that a maximalnoise FHE ciphertext cannot be evaluated further. The objective of this embodiment is to reduce the noise by a sequence of PBS operations so that further homomorphic evaluations may be carried out. This embodiment outputs an encryption of the standardLWR-based PRF ⌈(^ / ^) ⋅ 〈^, ^〉 mod ^⌋ in bootstrapping depth 2. The description of thisembodiment is summarised via the following algorithm: ^^^^(^) ^^ (bsk, ^): Given public parameters pp = (^, ^, ^, ^), abootstrapping key bsk and input ^ ∈ {0,1}ℓ, compute the input-dependent ciphertext mod ^)(c) (^, ^̅) = ^^^^[^^^^^](^, ^)( mod ^)Output the ciphertext ct = (^, ^̅) ∈ ℤ^^^^. It can be mathematically proven that the ^^^^(^)procedure indeed achievesits goal. Assume that ^ and ^ are both powers of 2 and that Δ = ^ / ^ > 4^, where ^ isthe bootstrapping error. For any ^ ∈ {0,1}ℓ, ^^^^(^) outputs a ciphertext (^, ^̅) ∈ ℤ^ ^^^such that ^^^^(^, ^̅) = Δ ⋅ ^ + ^( mod ^), where |^| < ^,^ = ⌈^ ^⋅ (〈^, ^〉 mod ^)⌋ mod ^with ^ = ^(^) ∈ ℤ^^. Fourth embodiment In this embodiment, we use three negacyclic functions ^^: ℤ^^ → ℤ^^,^^: → ℤ^ that were described in

[0022] . These functions are defined as−Δ / 4 if0 ≤ x < Δ / 4^^(^) = ^ +Δ / 4 ifΔ / 2 ≤ x < 3Δ / 40 otherwisemod 2Δ< Δ ≥ ΔOnce again we are assuming that ^ = 2^ and Δ = ^ / ^ ∈ ℤ. As in previousembodiments, the analysis crucially relies on viewing the ciphertext (−^, 0) as a maximalnoise encryption of ⌈(^ / ^) ⋅ 〈^, ^〉 mod ^⌋ and performing a sequence of bootstraps thatclean up this noise to obtain a low-noise encryption of ⌈(^ / ^) ⋅ 〈^, ^〉 mod ^⌋. Thedescription of this embodiment is summarised via the following algorithm: ^^^^(^) ^^ (bsk, ^): Given public parameters pp = (^, ^, ^, ^, ^), anevaluation key bsk and an input ^ ∈ {0,1}ℓ, compute the input-dependent vector ^ =^(^) ∈ ℤ^^and do the following: (a) (^, 0) = (−^, 0) mod Δ(b) (^, ^) = (−^, 0) − ^^^^[^^](^, 0)( mod ^) ^)Output the ciphertext ct = (^, ^) ∈ ℤ[^]^^^.Assume that ^ divides ^ and that Δ = ^ / ^ > 16^, where ^ is thebootstrapping error from Theorem 1. For any ^ ∈ {0,1}ℓ, ^^^^(^) outputs a ciphertext(^, ^) ∈ ℤ^^^^ such that ^^^^(^, ^) = Δ ⋅ ^ + ^( mod ^), where |^| < 2^,^ = ⌈^ ^⋅ (〈^, ^〉 mod ^)⌋ mod ^with ^ = ^(^) ∈ ℤ^^. Example Application An application of our invention is efficient data transmitting. In particular, one may wish to send large amounts of data on the cloud that will eventually be used in an FHE application—think for example of image processing over encrypted data. Instead of sending FHE encryptions of the data on the cloud, our invention allows the transmission of symmetric key encryptions to dramatically reduce cloud bandwidth requirements. Specifically, the symmetric encryptions sent on the cloud do not need to be any larger than the original data, whereas FHE ciphertexts would be much larger. As an example ofthis application, a symmetric encryption of a message ^ might take the form(^, ^ + ^^^^(^))where ^ is a random string of sufficient length chosen by the sender. Then, in order toobtain an FHE encryption of ^, the cloud can use an FHE encryption of ^ to compute anFHE encryption of ^^^^(^). With this, the cloud can homomorphically subtract ^^^^(^)to obtain an FHE encryption of ^ that can be computed on further. Note that other formsof symmetric encryption (e.g., certain block cipher modes of operation) may also be used provided that PRF inputs remain public. To give an overview of how our embodiments are applied, we may consider our third preferred embodiment as an example. This yields a symmetric encryptionscheme where the sender chooses a random ^ ↩ ^({0,1}^) and encrypts ^ ∈ ℤ^^usingPRF secret key ^ ↩ ^({0,1}^) by computing (^, ^) = (^, ^ + ^^^^(^) mod ^), where^^^^(^) = ⌈(^ / ^) ⋅ (^(^)^^ mod ^)⌋ ∈ ℤ^^. Then, the encryptor sends the ciphertext (^, ^). It is assumed that the evaluatorpossesses a copy of the corresponding public bootstrapping key bsk = ^^^. ^^^^^(^)for some secret key ^′. From (^, ^) and bsk, the evaluator can compute(bs ^×^^ k, ^) ∈ ℤ^ × ℤ^,where ∥ ^ ∥^≤ ^ for the bound ^ of Theorem 1 Then, the evaluator obtains(−^, −^ + Δ ⋅ ^ mod ^)which is an encryption of ^ ∈ ℤ^^ under key ^′. Observe that (^, Δ ⋅ ^) is a (trivial)encryption of ^. When ^′ = ^, this results in an FHE encryption under the sender’s key ^. Themain advantage of the proposed solution is that the encryption of ^ plaintexts in onlyrequires sending a random seed ^ (typically, a 256-bit value) along with ^ values modulo^. This is much better that the plain solution that would send a matrix ^ of ^ × ^ entriesmodulo ^ plus ^ values modulo ^ (typically, ^ is of the order of 1000). This is evenbetter than the folklore improved solution comprising sending a seed ^ for building matrix^ along with ^ values modulo ^. Our solution trades modulo-^ values against modulo-^ values, where ^ ≪ ^; typically, ^ = 2^ and ^ = 2^^. Compared to the improvedsolution, this saves ^ ⋅ log^^ / ^ bits of transmission. For example, for (1024 × 1024)8-bit grayscale images, with ^ = 16 and ^ = 2^^ (and thus ^ = 2^^), this results insaving more than 10^bits per encrypted image. References [1] Sha-3 standard: Permutation-based hash and extendable-output functions.FIPS 202. NIST, 2015. URL: https: / / csrc.nist.gov / pubs / fips / 202 / final.[2] Joël Alwen, Stephan Krenn, Krzysztof Pietrzak, and Daniel Wichs. Learningwith rounding, revisited - new reduction, properties and applications. In Ran Canetti andJuan A. Garay, editors, CRYPTO 2013, Part I, volume 8042 of LNCS, pages 57–74.Springer, Heidelberg, August 2013. https: / / doi.org / 10.1007 / 978-3-642-40041-4_4doi:10.1007 / 978-3-642-40041-4_4. [3] Abhishek Banerjee and Chris Peikert. New and improved key-homomorphicpseudorandom functions. In Juan A. Garay and Rosario Gennaro, editors, CRYPTO 2014,Part I, volume 8616 of LNCS, pages 353–370. Springer, Heidelberg, August 2014.https: / / doi.org / 10.1007 / 978-3-662-44371-2_20 doi:10.1007 / 978-3-662-44371-2_20. [4] Abhishek Banerjee, Chris Peikert, and Alon Rosen. Pseudorandom functionsand lattices. In David Pointcheval and Thomas Johansson, editors, EUROCRYPT 2012,volume 7237 of LNCS, pages 719–737. Springer, Heidelberg, April 2012.https: / / doi.org / 10.1007 / 978-3-642-29011-4_42 doi:10.1007 / 978-3-642-29011-4_42. [5] Mihir Bellare, Anand Desai, Eron Jokipii, and Phillip Rogaway. A concretesecurity treatment of symmetric encryption. In Proceedings of the 38th Annual Symposium on Foundations of Computer Science, FOCS ’97, page 394. IEEE Computer Society, 1997. [6] Mihir Bellare, Joe Kilian, and Phillip Rogaway. The security of the cipherblock chaining message authentication code. Journal of Computer and System Sciences,61(3):362–399, 2000. https: / / doi.org / 10.1006 / jcss.1999.1694doi:10.1006 / jcss.1999.1694. [7] Mihir Bellare and Phillip Rogaway. Random oracles are practical: A paradigmfor designing efficient protocols. In Dorothy E. Denning, Raymond Pyle, Ravi Ganesan,Ravi S. Sandhu, and Victoria Ashby, editors, ACM CCS 93, pages 62–73. ACM Press,November 1993. https: / / doi.org / 10.1145 / 168588.168596 doi:10.1145 / 168588.168596.[8] Andrej Bogdanov, Siyao Guo, Daniel Masny, Silas Richelson, and AlonRosen. On the hardness of learning with rounding over small modulus. In EyalKushilevitz and Tal Malkin, editors, TCC 2016-A, Part I, volume 9562 of LNCS, pages209–224. Springer, Heidelberg, January 2016. https: / / doi.org / 10.1007 / 978-3-662-49096-9_9 doi:10.1007 / 978-3-662-49096-9_9. [9] Andrej Bogdanov and Alon Rosen. Pseudorandom functions: Three decadeslater. In Yehuda Lindell, editor, Tutorials on the Foundations of Cryptography,Information Security and Cryptography, chapter 3, pages 79–158. Springer, 2017. https: / / doi.org / 10.1007 / 978-3-319-57048-8_3 doi:10.1007 / 978-3-319-57048-8_3.

[10] Dan Boneh, Kevin Lewi, Hart William Montgomery, and AnanthRaghunathan. Key homomorphic PRFs and their applications. In Ran Canetti and JuanA. Garay, editors, CRYPTO 2013, Part I, volume 8042 of LNCS, pages 410–428.Springer, Heidelberg, August 2013. https: / / doi.org / 10.1007 / 978-3-642-40041-4_23doi:10.1007 / 978-3-642-40041-4_23.

[11] Katharina Boudgoust, Corentin Jeudy, Adeline Roux-Langlois, andWeiqiang Wen. On the hardness of module-LWE with binary secret. In CT-RSA, 2021.

[0012] Katharina Boudgoust, Corentin Jeudy, Adeline Roux-Langlois, andWeiqiang Wen. On the hardness of module learning with errors with short distributions.J. of Cryptology, 2022.

[13] Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène.Faster fully homomorphic encryption: Bootstrapping in less than 0.1 seconds. In JungHee Cheon and Tsuyoshi Takagi, editors, ASIACRYPT 2016, Part I, volume 10031 ofLNCS, pages 3–33. Springer, Heidelberg, December 2016. https: / / doi.org / 10.1007 / 978-3-662-53887-6_1 doi:10.1007 / 978-3-662-53887-6_1.

[0014] Chitchanok Chuengsatiansup and Damien Stehle. Towards practical GGM-based PRF from (Module-)Learning-with-Rounding. In SAC, 2019.

[0015] Amit Deo, Marc Joye, and Benoit Libert. Homomorphic evaluation of LWR-based PRFs. Technical report, Zama, September 2023.

[0016] Léo Ducas and Daniele Micciancio. FHEW: Bootstrapping homomorphicencryption in less than a second. In Elisabeth Oswald and Marc Fischlin, editors,EUROCRYPT 2015, Part I, volume 9056 of LNCS, pages 617–640. Springer, Heidelberg,April 2015. https: / / doi.org / 10.1007 / 978-3-662-46800-5_24 doi:10.1007 / 978-3-662-46800-5_24.

[17] Jan-Pieter D’Anvers, Angshuman Karmakar, Sujoy Sinha Roy, and FrederikVercauteren. Saber: module-LWR based key exchange, CPA-secure encryption andCCA-secure KEM. In Africacrypt, 2018.

[0018] J. Fan and F. Vercauteren. Somewhat practical fully homomorphicencryption. Cryptology ePrint Archive Report 2012 / 144.

[0019] Robin Geelen and Frederik Vercauteren. Bootstrapping for BGV and BFVrevisited. J. of Cryptology, 36(12), 2023.

[0020] Oded Goldreich, Shafi Goldwasser, and Silvio Micali. How to constructrandom functions. Journal of the ACM, 33(4):792–807, August 1986.https: / / doi.org / 10.1145 / 6490.6503 doi:10.1145 / 6490.6503.

[21] Adeline Langlois and Damien Stehlé. Worst-case to average-case reductionsfor module lattices. Des. Codes Cryptography, 75(3):565–599, 2015.

[0022] Zeyu Liu, Daniele Micciancio, and Yuriy Polyakov. Large-precisionhomomorphic sign evaluation using FHEW / TFHE bootstrapping. In Shweta Agrawal andDongdai Lin, editors, ASIACRYPT 2022, Part II, volume 13792 of LNCS, pages 130–160. Springer, Heidelberg, December 2022. https: / / doi.org / 10.1007 / 978-3-031-22966-4_5 doi:10.1007 / 978-3-031-22966-4_5.

[23] Vadim Lyubashevsky, Chris Peikert, and Oded Regev. On ideal lattices andlearning with errors over rings. In Henri Gilbert, editor, EUROCRYPT 2010, volume 6110of LNCS, pages 1–23. Springer, Heidelberg, May / June 2010.https: / / doi.org / 10.1007 / 978-3-642-13190-5_1 doi:10.1007 / 978-3-642-13190-5_1.

[24] Shihe Ma, Tairong Huang, Anyu Wang, and Xiaoyun Wang. Fast andaccurate: Efficient full-domain functional bootstrap and digit decomposition forhomomorphic computation. Cryptology ePrint Archive Report 2023 / 645.https: / / eprint.iacr.org / 2023 / 645.

[0025] Oded Regev. On lattices, learning with errors, random linear codes, andcryptography. In Harold N. Gabow and Ronald Fagin, editors, 37th ACM STOC, pages84–93. ACM Press, May 2005. https: / / doi.org / 10.1145 / 1060590.1060603doi:10.1145 / 1060590.1060603.

[26] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3.RFC 8446, 2018. URL: https: / / www.rfc-editor.org / info / rfc8446,https: / / doi.org / 10.17487 / RFC8446 doi:10.17487 / RFC8446.

[27] Eric Rescorla and Tim Dierks. The Transport Layer Security (TLS) ProtocolVersion 1.2. RFC 5246, 2008. URL: https: / / www.rfc-editor.org / info / rfc5246,https: / / doi.org / 10.17487 / RFC5246 doi:10.17487 / RFC5246. The references are included herein by reference. Figure 3a schematically shows an example of an embodiment of a method400 for a server device for homomorphically evaluating a pseudorandom function. The server is configured for an a fully homomorphic encryption (FHE) scheme supporting abootstrapping algorithm . Method 400 may be computer implemented and comprises, the method comprising- receiving (410) from a client device an argument for the pseudorandomfunction, wherein the argument is not encrypted according to the FHE scheme, and abootstrapping key, the bootstrapping key comprising an encryption of a secret key of theclient device under a further encryption key,- applying (420) a collision-resistant function to the argument, filling at leastpart of the elements of a randomized ciphertext with the output of the collision-resistant function,- applying (430) the bootstrapping algorithm to the randomized ciphertextusing the bootstrapping key, the output of the bootstrapping algorithm being encrypted under the further encryption key, and deriving (440) the pseudorandom value from the bootstrapping algorithm’s output while encrypted according to the FHE scheme, the pseudorandom function being defined at least by the combination of the bootstrapping algorithm and the collision-resistant function. Figure 3b schematically shows an example of an embodiment of a method 450 for a client device for evaluating a pseudorandom function. Method 450 may be computer implemented and comprises- selecting (460) an argument for the pseudorandom function and sendingthe argument to the server device, wherein the argument is not encrypted according to the FHE scheme,- obtaining (470) a secret key for the FHE scheme, and a bootstrapping keycomprising an encryption of the secret key under a further encryption key, sending the bootstrapping key to the server device,- computing (480) a pseudorandom value by applying a pseudorandomfunction to the selected argument, the pseudorandom function being defined at least by the combination of a bootstrapping algorithm of the FHE scheme and a collision-resistant function. 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 ofmethod 400 and / or 450. 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 signalalong a wire, or wireless, or using a data network, e.g., the Internet. The software may bemade 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 comprisescomputer executable instructions corresponding to each of the devices, units and / or partsof at least one of the systems and / or products set forth. Figure 4a shows a computer readable medium 1000 having a writable part1010, 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 of evaluating a pseudorandom function, 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 of evaluating a pseudorandom function. Figure 4b shows in a schematic representation of a processor system 1140according to an embodiment of a device for evaluating a pseudorandom function,. Theprocessor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Figure 4b. 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. Theprocessor system 1140 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., a device configured for evaluating a pseudorandom function (either in standard computation or homomorphic computation) 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. In an embodiment, the processor circuit may be ARM Cortex M0. 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, theprocessing unit 1120 may include multiple microprocessors that are configured toindependently execute the methods described herein or are configured to performelements or subroutines of the methods described herein such that the multiple processorscooperate 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 beconstrued as limiting the claim. Use of the verb ‘comprise’ and its conjugations does notexclude 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 ofhardware. The mere fact that certain measures are recited in mutually different dependentclaims 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 cryptographic method (400) for a server device (120; 310) for homomorphically evaluating a pseudorandom function (PRF; 340) by a server device foran argument (231, 232) to obtain a pseudorandom value (341, 342), the server beingconfigured for a fully homomorphic encryption (FHE) scheme supporting a bootstrappingalgorithm (345), the method comprising- receiving (410) from a client device (110; 210) an argument (231, e.g., ^)for the pseudorandom function, wherein the argument is not encrypted according to the FHE scheme, and a bootstrapping key (262, e.g., bsk), the bootstrapping key comprising an encryption of a secret key (261, e.g., ^) of the client device under a further encryption key (e.g., ^′),- applying (420) a collision-resistant function (245) to the argument, fillingat least part of the elements of a randomized ciphertext (331, e.g.,(^^, … , ^^ , ^); (^^, … , ^^, 0) ) with the output of the collision-resistant function,- applying (430) the bootstrapping algorithm (345) to the randomizedciphertext (331) using the bootstrapping key (262), the output of the bootstrappingalgorithm being encrypted under the FHE scheme, and deriving (440) the pseudorandom value (341) from the bootstrapping algorithm’s output while encrypted according to the FHE scheme, the pseudorandom function being defined at least by the combination of the bootstrapping algorithm and the collision-resistant function. Claim 2. The method for the server device as in Claim 1, wherein- the output of the bootstrapping algorithm is encrypted under the furtherencryption key (e.g., s’), and / or- the server device further receives from the client device (110; 210) a key-switching key, the method comprising including a key-switching operation in thebootstrapping algorithm to obtain the output of the bootstrapping algorithm encryptedunder the secret key (261, e.g., ^), or optionally under another key (e.g., ^′′).Claim 3. The method for the server device as in Claim 1 or 2, further comprising- generating a stream of pseudorandom values (341, 342, e.g., ^^^(^^),^^^(^^), …) by repeated applications of the pseudorandom function, the generatedstream being encrypted according to the FHE scheme,- receiving encrypted data (251, 252, e.g.,the data being inencrypted form (e.g., ^1 = ^1 + ^1, ^2 = ^2 + ^2, …), by combining (250) thepseudorandom values in plain form (241, 242) to corresponding original data (221, 222,e.g., ^1, ^2, …),- removing (350) the pseudorandom values from the encrypted data whileencrypted in the FHE scheme, thus obtaining the original data (221, 222) encrypted according to the FHE scheme. Claim 4. A cryptographic method (450) for a client device (110; 210) for evaluating a pseudorandom function (PRF; 240) configured for homomorphic evaluation by a server device (120; 310) according to an FHE scheme, the method comprising- selecting (460) an argument (231; e.g., ^) for the pseudorandom functionand sending the argument to the server device (310), wherein the argument is notencrypted according to the FHE scheme,- obtaining (470) a secret key (261; e.g., ^) for the FHE scheme, and abootstrapping key (262; e.g., bsk) comprising an encryption of the secret key under a further encryption key (e.g., ^′), sending the bootstrapping key to the server device,- computing (480) a pseudorandom value (241, 242) by applying apseudorandom function (240) to the selected argument (231, 232), the pseudorandomfunction being defined at least by the combination of a bootstrapping algorithm of the FHE scheme and a collision-resistant function. Claim 5. The method for the client device as in Claim 4, wherein- the client device further sends to the server device (120; 220) a key-switching key, for including a key-switching operation in the bootstrapping algorithm forthe server device to obtain the output of the bootstrapping algorithm encrypted under thesecret key (261, e.g., ^), or optionally under another key (e.g., ^′′). Claim 6. The method for the client device as in Claim 4 or 5, further comprising- generating a stream of pseudorandom values (241, 242; e.g., ^1, ^2, …) byrepeated application of the pseudorandom function (240), the generated stream beingunencrypted,- encrypting original data (221, 222; e.g., ^1, ^2, …) by combining thepseudorandom values in plain form to the corresponding original data, (251, 252; e.g.,^1 = ^1 + ^1, ^2 = ^2 + ^2, …),- sending the encrypted original data to the server device.Claim 7. A cryptographic method as in any of the preceding claims, wherein- an encrypted data item according to the FHE scheme (e.g., (^^, … , ^^, ^))comprises a tuple numbers and / or polynomials in a ring, including a masking tuple (e.g.,^ = (^^, … , ^^)), and a masked message (e.g., ^ = 〈^, ^〉 + ^ + Δ ⋅ ^, for secret key ^comprising a tuple of masking numbers and / or polynomials in a ring, dot product 〈^, ^〉,noise ^, message ^, and multiplier Δ), and / or- wherein the randomized ciphertext ((−^, ^); (−^, 0)) is regarded as theFHE encryption of a value depending on the dot product 〈^, ^〉, (e.g., ⌈(〈^, ^〉 mod ^) / Δ⌉).Claim 8. A cryptographic method as in any of the preceding claims, wherein the pseudorandom function depends on the dot product between at least part of therandomized ciphertext (e.g., ^^, … , ^^) and the secret key.Claim 9. A cryptographic method as in Claim 8, wherein a desired pseudorandom function depending on said dot product is decomposed into a sequence of one or more programmable bootstrapping operations according to the bootstrapping algorithm, theprogrammable bootstrapping in the sequence being configured to provide the desiredpseudorandom function in composition when performed on the randomized ciphertext. Claim 10. A cryptographic method as in any of the preceding claims, wherein the bootstrapping algorithm is programmable for a function, wherein the function- is negacyclic, and / or- maps a range (e.g., ℤ^^; ℤ^) of the argument (e.g., ^) to a ring for theelements of encrypted data items according to the FHE scheme (e.g., ℤ^), and / or- the function comprises a scalar multiple of the argument or the argumentmodulo a modulus.Claim 11. A cryptographic method as in any of the preceding claims, wherein thebootstrapping algorithm is configured for a function ^: ^^ → ^^ satisfying the propertythat, for any input ^ ∈ {0,1}ℓ, the distributionmod ^))^)} is computationally indistinguishable fromwherein ^(^^ ^ ℓ^ ) denotes the uniform distribution over ^^ , ^^: {0,1} → ^^^×^is thecollision-resistant function that maps an input ^ ∈ {0,1}ℓ to an input-dependent matrixthat maps an input ^ ∈ {0,1}ℓ to a ringelement ^^. Claim 12. A cryptographic method as in any of the preceding claims, wherein- the bootstrapping algorithm is configured for the function ^(^) =function is ^^^^(^) =- the bootstrapping algorithm is configured for the function ^(^) =and the pseudorandom function is- the pseudorandom function is ^^^^(^) ≔ ⌈(^ / 2^) ⋅ (〈^, ^〉 mod 2^)⌋,the function ^(^) = Δ ⋅ ⌈^ / Δ⌋ being decomposed over two bootstrapping applications.Claim 13. A cryptographic method as in any of the preceding claims, wherein the distribution of pseudorandom values is uniform if the distribution of arguments is uniform.Claim 14. A server device comprising: one or more processors; and one or more storagedevices storing instructions that, when executed by the one or more processors, cause theone or more processors to perform operations for any method for a server device as in anyof claims 1-13. Claim 15. A client device comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, cause theone or more processors to perform operations for any method for a client device as in any of claims 1-13. Claim 16. A transitory or non-transitory computer storage medium encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform the method according to any of claims 1-13.

Images