This example protocol[1], implements Prepare-and-Send Quantum Fully Homomorphic Encryption[2] protocol with the additional property that it may be verified, where it is checked if the final ciphertext produces by the server matches the results of a particular computation. QFHE is a protocol where any arbitrary computations can be carried out by the server on the client’s encrypted data while hiding all inputs and outputs of the client. In the classical version of this protocol, verification was carried by creating copies at every stage, which is not possible in the quantum version due to the no-cloning theorem. Hence in this protocol, verification is carried out by a technique where the server generates classical computational logs through which the underlying encryptions becomes authenticated. These computational logs are used to certify to the client that a particular homomorphic quantum computation was performed on a classical computer.
This protocol consists mainly of four stages: Key Generation, Encryption, Homomorphic evaluation, and Verified decryption. To introduce verification, the major changes from the standard Prepare and Send Quantum Fully Homomorphic Encryption protocol take place in stage 2 (Evaluation) where a computational log is provided as an extra output and in stage 4 (Verified decryption) which accepts computational log and performs the verification. The verification performed in this protocol is mainly classical in nature.
Key gen:
Encryption: We encrypt each qubit of the plaintext using the trap code, and encrypt the trap code keys using the FHE scheme. This again requires the ability to perform Paulis, execute an error-correcting encoding, and the generation of basic single-qubit states.
Evaluation : Evaluation of a circuit is done gate by gate. Throughout this procedure, apart from the outputs, a complete computational log is made of all randomness used, all computation steps, all intermediate results, and all the classical FHE computations. To measure a qubit, we measure all ciphertext qubits and place the outcomes in the log.
Verified decryption
Here the correctness and consistency of the classical FHE transcript, the measurement outcomes, and the claimed circuit are checked. The result of this computation is a set of keys for the trap code, which are correct provided that Eval was performed honestly. In this step, decryption takes place using these keys and the output is either plaintext or reject. In terms of quantum capabilities, decryption requires executing the decoding procedure of the error-correcting code, computational-basis and Hadamard-basis measurements, and Paulis.
This procedure consists of two parts. Several classical checks are performed at first, where MAC-verification of all classically authenticated messages takes places. It also includes checking if the gates listing in the computational log match the circuit description. The portion of the log which specifies the purely classical, FHE steps taking during classical homomorphic encryption are also checked.
Next, all the unmeasured traps are checked and the remaining qubits are decoded. If the logs don’t match or if any of the traps are triggered, then the entire process is rejected.
Stage 1 : Key generation and encryption Main function: TrapTP.KeyGen
Function 1 : TrapTP.KeyGen($1^\\\kappa, 1^t, 1^p, 1^h$)
Function 2 : TrapTP.GadgetGen($sk_i$)
Function 3 : TrapTP.Enc(($\\\pi, k, sk_0, …, sk_t, pk$), $\\\sigma$)
Stage 2 : Evalutation
Function 4 : TrapTP.EvalMeasure($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 5 : TrapTP.EvalX($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{\\\pi}, pk, evk$)
Function 6 : TrapTP.EvalCondX($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 7 : TrapTP.EvalCNOT($\\\tilde{\\\sigma}_1, \\\tilde{\\\sigma}_2, \\\tilde{x}_1, \\\tilde{x}_2, \\\tilde{z}_1, \\\tilde{z}_2, \\\tilde{\\\pi}, pk, evk$)
Function 8 : TrapTP.EvalT($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, \\\mu_i^{T},\\\Gamma_i, pk_{i-1}, evk_{i-1}$)
Function 9 : TrapTP.EvalCondP($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\Gamma_i = (\\\tilde{g_i}, \\\tilde{\\\pi}i, \\\tilde{\\\gamma_i^{in}}, \\\tilde{\\\gamma_i^{mid}}, \\\tilde{\\\gamma_i^{out}}), \\\tilde{\\\pi},pk{i}, evk_{i}$)
Stage 3 : Verification Decryption
Function 10 : TrapTP.VerDec($sk, \\\tilde{\\\sigma}, \\\tilde{x[i]}_i, \\\tilde{z[i]}_i, log, c$)
No content has been added to this section, yet!
The message authentication code used in the protocol is taken from [3].
This example protocol[1], implements Prepare-and-Send Quantum Fully Homomorphic Encryption[2] protocol with the additional property that it may be verified, where it is checked if the final ciphertext produces by the server matches the results of a particular computation. QFHE is a protocol where any arbitrary computations can be carried out by the server on the client’s encrypted data while hiding all inputs and outputs of the client. In the classical version of this protocol, verification was carried by creating copies at every stage, which is not possible in the quantum version due to the no-cloning theorem. Hence in this protocol, verification is carried out by a technique where the server generates classical computational logs through which the underlying encryptions becomes authenticated. These computational logs are used to certify to the client that a particular homomorphic quantum computation was performed on a classical computer.
This protocol consists mainly of four stages: Key Generation, Encryption, Homomorphic evaluation, and Verified decryption. To introduce verification, the major changes from the standard Prepare and Send Quantum Fully Homomorphic Encryption protocol take place in stage 2 (Evaluation) where a computational log is provided as an extra output and in stage 4 (Verified decryption) which accepts computational log and performs the verification. The verification performed in this protocol is mainly classical in nature.
Key gen:
Encryption: We encrypt each qubit of the plaintext using the trap code, and encrypt the trap code keys using the FHE scheme. This again requires the ability to perform Paulis, execute an error-correcting encoding, and the generation of basic single-qubit states.
Evaluation : Evaluation of a circuit is done gate by gate. Throughout this procedure, apart from the outputs, a complete computational log is made of all randomness used, all computation steps, all intermediate results, and all the classical FHE computations. To measure a qubit, we measure all ciphertext qubits and place the outcomes in the log.
Verified decryption
Here the correctness and consistency of the classical FHE transcript, the measurement outcomes, and the claimed circuit are checked. The result of this computation is a set of keys for the trap code, which are correct provided that Eval was performed honestly. In this step, decryption takes place using these keys and the output is either plaintext or reject. In terms of quantum capabilities, decryption requires executing the decoding procedure of the error-correcting code, computational-basis and Hadamard-basis measurements, and Paulis.
This procedure consists of two parts. Several classical checks are performed at first, where MAC-verification of all classically authenticated messages takes places. It also includes checking if the gates listing in the computational log match the circuit description. The portion of the log which specifies the purely classical, FHE steps taking during classical homomorphic encryption are also checked.
Next, all the unmeasured traps are checked and the remaining qubits are decoded. If the logs don’t match or if any of the traps are triggered, then the entire process is rejected.
Stage 1 : Key generation and encryption Main function: TrapTP.KeyGen
Function 1 : TrapTP.KeyGen($1^\\\kappa, 1^t, 1^p, 1^h$)
Function 2 : TrapTP.GadgetGen($sk_i$)
Function 3 : TrapTP.Enc(($\\\pi, k, sk_0, …, sk_t, pk$), $\\\sigma$)
Stage 2 : Evalutation
Function 4 : TrapTP.EvalMeasure($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 5 : TrapTP.EvalX($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{\\\pi}, pk, evk$)
Function 6 : TrapTP.EvalCondX($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 7 : TrapTP.EvalCNOT($\\\tilde{\\\sigma}_1, \\\tilde{\\\sigma}_2, \\\tilde{x}_1, \\\tilde{x}_2, \\\tilde{z}_1, \\\tilde{z}_2, \\\tilde{\\\pi}, pk, evk$)
Function 8 : TrapTP.EvalT($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, \\\mu_i^{T},\\\Gamma_i, pk_{i-1}, evk_{i-1}$)
Function 9 : TrapTP.EvalCondP($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\Gamma_i = (\\\tilde{g_i}, \\\tilde{\\\pi}i, \\\tilde{\\\gamma_i^{in}}, \\\tilde{\\\gamma_i^{mid}}, \\\tilde{\\\gamma_i^{out}}), \\\tilde{\\\pi},pk{i}, evk_{i}$)
Stage 3 : Verification Decryption
Function 10 : TrapTP.VerDec($sk, \\\tilde{\\\sigma}, \\\tilde{x[i]}_i, \\\tilde{z[i]}_i, log, c$)
No content has been added to this section, yet!
The message authentication code used in the protocol is taken from [3].
This example protocol[1], implements Prepare-and-Send Quantum Fully Homomorphic Encryption[2] protocol with the additional property that it may be verified, where it is checked if the final ciphertext produces by the server matches the results of a particular computation. QFHE is a protocol where any arbitrary computations can be carried out by the server on the client’s encrypted data while hiding all inputs and outputs of the client. In the classical version of this protocol, verification was carried by creating copies at every stage, which is not possible in the quantum version due to the no-cloning theorem. Hence in this protocol, verification is carried out by a technique where the server generates classical computational logs through which the underlying encryptions becomes authenticated. These computational logs are used to certify to the client that a particular homomorphic quantum computation was performed on a classical computer.
This protocol consists mainly of four stages: Key Generation, Encryption, Homomorphic evaluation, and Verified decryption. To introduce verification, the major changes from the standard Prepare and Send Quantum Fully Homomorphic Encryption protocol take place in stage 2 (Evaluation) where a computational log is provided as an extra output and in stage 4 (Verified decryption) which accepts computational log and performs the verification. The verification performed in this protocol is mainly classical in nature.
Key gen:
Encryption: We encrypt each qubit of the plaintext using the trap code, and encrypt the trap code keys using the FHE scheme. This again requires the ability to perform Paulis, execute an error-correcting encoding, and the generation of basic single-qubit states.
Evaluation : Evaluation of a circuit is done gate by gate. Throughout this procedure, apart from the outputs, a complete computational log is made of all randomness used, all computation steps, all intermediate results, and all the classical FHE computations. To measure a qubit, we measure all ciphertext qubits and place the outcomes in the log.
Verified decryption
Here the correctness and consistency of the classical FHE transcript, the measurement outcomes, and the claimed circuit are checked. The result of this computation is a set of keys for the trap code, which are correct provided that Eval was performed honestly. In this step, decryption takes place using these keys and the output is either plaintext or reject. In terms of quantum capabilities, decryption requires executing the decoding procedure of the error-correcting code, computational-basis and Hadamard-basis measurements, and Paulis.
This procedure consists of two parts. Several classical checks are performed at first, where MAC-verification of all classically authenticated messages takes places. It also includes checking if the gates listing in the computational log match the circuit description. The portion of the log which specifies the purely classical, FHE steps taking during classical homomorphic encryption are also checked.
Next, all the unmeasured traps are checked and the remaining qubits are decoded. If the logs don’t match or if any of the traps are triggered, then the entire process is rejected.
Stage 1 : Key generation and encryption Main function: TrapTP.KeyGen
Function 1 : TrapTP.KeyGen($1^\\\kappa, 1^t, 1^p, 1^h$)
Function 2 : TrapTP.GadgetGen($sk_i$)
Function 3 : TrapTP.Enc(($\\\pi, k, sk_0, …, sk_t, pk$), $\\\sigma$)
Stage 2 : Evalutation
Function 4 : TrapTP.EvalMeasure($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 5 : TrapTP.EvalX($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{\\\pi}, pk, evk$)
Function 6 : TrapTP.EvalCondX($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, pk, evk$)
Function 7 : TrapTP.EvalCNOT($\\\tilde{\\\sigma}_1, \\\tilde{\\\sigma}_2, \\\tilde{x}_1, \\\tilde{x}_2, \\\tilde{z}_1, \\\tilde{z}_2, \\\tilde{\\\pi}, pk, evk$)
Function 8 : TrapTP.EvalT($\\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\tilde{\\\pi}, \\\mu_i^{T},\\\Gamma_i, pk_{i-1}, evk_{i-1}$)
Function 9 : TrapTP.EvalCondP($\\\tilde{b}, \\\tilde{\\\sigma}, \\\tilde{x}, \\\tilde{z}, \\\Gamma_i = (\\\tilde{g_i}, \\\tilde{\\\pi}i, \\\tilde{\\\gamma_i^{in}}, \\\tilde{\\\gamma_i^{mid}}, \\\tilde{\\\gamma_i^{out}}), \\\tilde{\\\pi},pk{i}, evk_{i}$)
Stage 3 : Verification Decryption
Function 10 : TrapTP.VerDec($sk, \\\tilde{\\\sigma}, \\\tilde{x[i]}_i, \\\tilde{z[i]}_i, log, c$)
No content has been added to this section, yet!
The message authentication code used in the protocol is taken from [3].