Quantum Protocol Zoo - User contributions [en]

Main Page

2018-11-08T09:27:10Z

Ahmed: /* Getting started */

'''Welcome to The Quantum Protocol Zoo-''' ''Explore, Learn and Implement Quantum Protocols''<br/><br/>The Quantum Protocol Zoo is open repository of quantum protocols which provides a medium to explore all such protocols presented in a compressed form in order to communicate with the computer scientists, engineers and physicists on one platform.

== Getting started ==
Quantum Protocol Zoo encompasses a set of General Functionality Descriptions of different quantum and classical functionalities achieved by various quantum protocols. This description elicits the different methods used by various protocols. Each such method is described by a formal description illustrating a simple yet detailed outline of the method, its properties and relevant papers. The description is written keeping a general audience in mind and a mathematical algorithm of the same is also provided. The section on relevant papers encompass all the various protocols published so far which imply similar method and properties. The different descriptions are interlinked by means of related terms called "tags". Some use case and technological readiness of the method are also highlighted to indicate any near term implementation or scope of the protocol. Finally, all esoteric concepts used in any description are explained via links to [[Supplementary Information]].<br/><br/>
'*'Each page is independent and does not require any extra information yet links are provided for better understanding of some concepts in all such descriptions. Following is the structure for all formal descriptions available on Quantum Protocol Zoo.

==Structure==
*'''Functionality Description'''</br>
A lucid definition of functionality achieved and properties satisfied by the method used.
----
*'''Use Case'''</br>
Bridges the gap between users and protocol designers.

'''Tags:''' Any related page or list of protocols is connected by this section
----
*'''Outline'''</br>
A non-mathematical detailed outline which provides a rough idea of the method described. A figure is accommodated for most protocols.
----
*'''Requirements'''</br>
#Network Stage:
#Technological Readiness:
----
*'''Example:''' link to the example paper to be discussed below is provided here
#'''Properties''' A list of important information extracted from the protocol such as, Parameters (threshold values), security claim, success probability, adversarial assumption (see [[Quantum Adversary Definitions|Quantum Adversary Definitions)]], setup assumptions, etc..
#'''Pseudo Code''' Mathematical step-wise protocol algorithm
----
*'''Relevant papers'''</br>
Protocols easy to interpret after reading the concerned formal description, listed in chronological order.
----

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

MediaWiki:Sidebar

2018-11-08T08:12:56Z

Ahmed:

Supplementary Information

2018-11-08T08:12:03Z

Ahmed: Ahmed moved page Appendix to Supplementary Information without leaving a redirect

==A General Introduction to Quantum Information==
Quantum computation is marked by a set of unitary matrices (quantum gates) acting on qubit states followed by measurement. The most used representation is the circuit model of computation, comprising straight lines and boxes. The horizontal lines represent qubits and boxes represent single qubit unitary gates. A two qubit unitary gate links one qubit from another via vertical lines. Some useful notations are given below.<br/>

*X (NOT gate): X |0i → |1i, X |1i → |0i, X |+i → |+i, X |−i → −|−i
*Z (Phase gate): Z |+i → |−i, Z |−i → |+i, Z |0i → |0i, Z |1i → −|1i
Thus, |0i, |1i are eigenstates of Z gate and |+i, |−i are eigenstates of X gate.
*H (Hadamard gate): H |0i → |+i or H |1i → |−i

*Controlled-U(CU): uses two inputs, control qubit and target qubit. It operates U on the second(target) qubit only when the first (source) qubit is 1. C-U gates are used to produce entangled states, when the target qubit is |+i and control qubit is not an eigenstate of U. In the given equation ’i’ denotes the source qubit and ’j’, the target qubit. Following are two important C-U gates.
*Controlled-NOT(CX):
*Controlled-Phase(CZ): <br/>
The commutation relations for the above gates are as follows:<br/>
* XH = HZ
* XZ = −ZX
*(X ⊗ I)CZ = CZ(X ⊗ Z), (Z ⊗ I)CZ = CZ(Z ⊗ I) 1 <br/>

*Unitary Operation
=== Hierarchy of Quantum Gates ===
There are different class of quantum gates as follows,
*'''Pauli Gates(U):''' Single Qubit Gates I (Identity), X, Y, Z. All the gates in this set follow U2 = I
*'''Clifford Gates(C):''' Pauli Gates, Phase Gate, C-NOT. This set of gates can be simulated on classical computer. All the gates in this set follow CU=U’C, where U and U’ are two different Pauli gates depending on C
*'''Toffoli Gate:''' A three qubit gate that does not belong to Clifford Group
*'''T Gates:''' \sqrt{Z} Although a member of Clifford Gate, its eigen states can be used as acillas to make quantum gate sthat are not!
*'''Universal Set of gates:''' This set consists of all Clifford gates and one Non-Clifford gate (or T gate). One can also say one Toffoli gate and Hadamard gate constitute the set of Universal Gates. If a model can realise Universal Set of gates, it can imlpement any quantum computation efficiently. T gates follow UT = PaU0T, where P is the phase gate and U, U’ are any two Pauli gates depending on C. Parameter 1 is obtained from U, such that P0 = I, P1 = P.

To summarize, the hierarchy of quantum can be defined as such.<br/>
If C(1)=P, C(2)=C, C(3)=T, then
C(n)={U:UQU\dagger=C(n-1),Q\epsilon C(1)}

===Magic States===
Eigen states of T gates

===Universal Resource===
A set of \ket{+_\theta} states on which applying Clifford operations is enough for universal quantum computation.

===Classical Quantum State===
===Density Matrices===
===Fidelity===

==Quantum Information Primitives==

===Superposition===

===Entanglement===
===Measurement===
===Discrete Variables and Continuous Variables===

==Security Definitions==
*Quantum Honest But Curious
*Malicious
*Chosen Plain-text Attack (CPA)

==Quantum Cryptography Techniques==

===Quantum One Time Pad===
*Pauli Gates
*Clifford Gates
*T Gates
===Gate Teleportation===
The idea comes from one-qubit teleporation. This means that one can transfer an unknown qubit |ψi without actually sending it via a quantum channel. The underlying equations explain the notion. See [[Supplementary Information#1|Figure 1]] for circuit.<br/>
<div id="1">
[[File:One Bit Teleportation.jpg|right|thumb|1000px|Figure 1: One Bit Teleportation]]
</div>(H ⊗ I)(CZ12)|ψi1 |+i2 <br/>
= (H ⊗ I)(CZ12)(a|0i1 + b|1i1)|+i2<br/>
= (H ⊗ I)(a|0i1 |+i2 + b|1i1 |−i2)<br/>
= a|+i1 |+i2 + b|−i1 |−i2<br/>
= |0i1 ⊗ (a|+i2 + b|−i2) + |1i1 ⊗ (a|+i2 − b|−i2)<br/>
= |0i1 ⊗ (a|+i2 + b|−i2) + |1i1 ⊗ X(a|+i2 + b|−i2)<br/>
= |0i1 ⊗ H(a|0i2 + b|1i2) + |1i1 ⊗ XH(a|0i2 + b|1i2)<br/>
= |0i1 ⊗ H |ψi2 + |1i1 ⊗ X |ψi2<br/>
= |mi ⊗ XmH |ψi<br/>
Similarly if we have the input state rotated by a Z(θ) gate the circuit would look like [[Supplementary Information#2a|Figure 2a]]. As the rotation gate Z(θ) commutes with Controlled-Phase gate. Hence, [[Supplementary Information#2b|Figure 2b]] is justified.<br/>
<div id="2"><div id="2a"><div id="2b"><ul>
<li style="display: inline-block;"> [[File:Modified Input.jpg|frame|500px|2(a)Modified Input]]</li>
<li style="display: inline-block;"> [[File:Gate Teleportation.jpg|frame|500px|2(b)Gate Teleportation]] </li>
</ul></div></div></div><br/>
This shows that for a pair of C-Z entangled qubits, if the second qubit is in |+i state (not an eigen value of Z) then one can teleport (transfer) the first qubit state operated by any unitary gate U to the second qubit by performing operations only on the first qubit and measuring it. Next, we would need to make certain Pauli corrections (in this case Xm) to obtain U |ψi. In other words, we can say the operated state is teleported to the second qubit by a rotated basis measurement of the first qubit with additional Pauli corrections.
===Graph states===
The above operation can also be viewed as a graph state with two nodes and one edge. The qubit 1 is measured in a rotated basis HZ(θ), thus leaving qubit 2 in desired state and Pauli Correction Xs1HZ(θ1)|ψi, where s1 is the measurement outcome of qubit 1.[[Appendix#3|Figure 3]]<br/>
<div id="3">
[[File:Graph States for Single Qubit States.jpg|center|thumb|1000px|Figure 3: Graph State for Single Qubit Gates]]</div>
Now, suppose we need to operate the state with two unitary gates Z(θ1) and Z(θ2). This can be done by taking the output state of Z(θ1) gate as the input state of Z(θ2) gate and then repeating gate teleportation for this setup, as described above. Thus, following the same pattern for graph states we have now three nodes (two measurement qubits for two operators and one output qubit) with two edges, entangled as one dimensional chain(See [[Supplementary Information#4|Figure 4]]).<br/>
<div id="4">
[[File:Gate Teleportation for Multiple Qubit Gates.jpg|center|thumb|500px|Figure 4: Gate Teleporation for Multiple Single Qubit Gates]]</div>
The measurement on qubit 1 will operate Xs1HZ(θ1)|ψi⊗I on qubits 2 and 3. If qubit 2 when measured in the given basis yields outcome s2, qubit 3 results in the following state Xs2HZ(θ2)Xs1HZ(θ1)|ψi. Using the relation we shift all the Pauli corrections to one end i.e. qubit 3 becomes Xs2Zs1HZ(±θ2)HZ(θ1)|ψi{equation missing}(Zs1H = HXs1). This method of computation requires sequential measurement of states i.e. all the states should not be measured simultaneously. As outcome of qubit 1 can be used to choose sign of ±θ2. This technique is also known as adaptive measurement. With each measurement, the qubits before the one measured at present have been destroyed by measurement. It is a feed-forward mechanism, hence known as one way quantum computation.<br/>

===Measurement Based Quantum Computation (MBQC)===
MBQC is a formalism used for quantum computation by operating only single qubit measurements on a fixed set of entangled states, also known as graph states. Graph states denote any graph where each node represents a quantum state, and the edges denote entanglement between any two vertices. The measurement on successive layers of qubits is decided by previous measurement outcomes. Outcomes of last qubit layer gives the result of concerned computation. Following, we illustrate certain primitives necessary to understand the working of MBQC.

====Cluster States====
In case of multi-qubit quatum circuits, one needs a 2-dimensional graph state. Cluster State is a square lattice used as substrate for such computation. All the nodes are in |+i entangled by C-Z indicated by the edges. It is known to be universal i.e. it can simulate any quatum gate.<br/>
<div id="5">
[[File:Cluster State.jpg|center|thumb|500px|Figure 5: Cluster State]]</div>Each row would thus represent the teleporation of starting qubit in that row horizontally. On the other hand, vertical edges indicate different input qubits linked with multi-qubit gates (same as circuit model). For example, see Figure [[Supplementary Information#6|Figure 6]] to understand the conversion from circuit model to graph state model. As the computation relation follows X = HZH, thus, Figure [[Supplementary Information#6a|Figure 6a]] represents Circuit diagram for C-NOT gate in terms of C-Z gate and Single Qubit Gate H.<br/>
<div id="6"><div id="6a"><div id="6b"><ul>
<li style="display: inline-block;"> [[File:Circuit Diagram to implement C-NOT.jpg|frame|500px|(a)Circuit Diagram to implement C-NOT]] </li>
<li style="display: inline-block;"> [[File:Graph State Pattern for C-NOT.jpg|frame|500px|(b)Graph State Pattern for C-NOT]] </li>
<center><caption>Figure 6: Measurement Pattern from Circuit Model</caption></center>
</ul></div></div></div><br/>
[[Supplementary Information#6a|Figure 6b]] shows implementation of the first Hadamard gate on the second input state as measurement M2 on qubit 2. Then C-Z gate is implemented by the entangled qubits 3 and 1 in the graph state. Qubit 3 is entangled to another qubit 4 to record the output while measurement M3 on qubit 3 implements the second Hadamard gate. Finally, the states to which qubits (1) and (4) are reduced to determine the output states of the two input qubits after C-NOT gate operation. It is evident that one needs to remove certain nodes from the cluster state in order to implement the above shown graph state. This can be done by Z-basis measurements. Such measurements would leave the remaining qubits in the cluster state with extra Pauli corrections. This can be explained as follows. Consider a 2-dimesional graph state {1,2}. If qubit 1 is to be eliminated, we operate C-Z with 2 as target and 1 as control.<br/>
CZ12 |+i1 |+i2 = |0i1 |+i2 + |1i1 |−i2 ,<br/>
Thus, if measurement on 1 yields m, qubit 2 would be in the state Zm |+i. Hence, such Z-basis measurements invoke an extra Zm Pauli correction on all the neigbouring sites of 1 with 1 eliminated, in the resulting graph state. Thus, to summarise, we design a measurement pattern from gate teleportation circuit of the desired computation as shown above. The cluster state is converted into the required graph state by Z-basis measurement on extraneous sites. Measuring all the qubits in the required basis and we get the required computation in the form of classical outcome register from measurement of the last layer of qubits. If it is a quantum function, the last layer of qubits is the output quantum register.<br/>

====Brickwork States====
Although cluster states are universal for MBQC, yet we need to tailor these to the specific computation by performing some computational (Z) basis measurements. If we were to use this principle for blind quantum computing, Client would have to reveal information about the structure of the underlying graph state. Thus, for the UBQC protocol, we introduce a new family of states called the Brickwork states which are universal for X − Y plane measurements and thus do not require the initial computational basis measurements. It was later shown that the Z-basis measurements can be dropped for cluster states and hence cluster states are also universal in X-Y measurements.
<div id="7">
[[File:Brickwork State.jpg|center|thumb|500px|Figure 7: Brickwork State]]</div>
'''Definition 1''' A brickwork state Gn×m, where m ≡ 5 (mod 8), is an entangled state of n × m qubits constructed as follows (see also Figure 7):
# Prepare all qubits in state |+i and assign to each qubit an index (i,j), i being a column (i ∈ [n]) and j being a row (j ∈ [m]).
# For each row, apply the operator c-Z on qubits (i,j) and (i,j + 1) where 1 ≤ j ≤ m − 1.
# For each column j ≡ 3 (mod 8) and each odd row i, apply the operator c-Z on qubits (i,j) and (i + 1,j) and also on qubits (i,j + 2) and (i + 1,j + 2).
# For each column j ≡ 7 (mod 8) and each even row i, apply the operator c-Z on qubits (i,j) and (i + 1,j) and also on qubits (i,j + 2) and (i + 1,j + 2).

====Flow Construction-Determinism====

Measurement outcomes of qubits is not certain, hence it renders MBQC a non-deterministic model. This can still be rectified by invoking Pauli corrections based on the previous outcomes, as evident from above. For example, to implement Hadamard gate on input state |ψi = a|0i + b|1i, we consider the case of a two qubit graph state C2x1.<br/>
C2x1 = CZij |ψii |+ij = a|00i + a|01i + b|10i − b|11i<br/>
If one measures qubit i in {|+i,|−i} basis and gets outcome s, qubit j reduces to,<br/>
= (a + b)|0i + (a − b)|1i,if s=0<br/>
= (a − b)|0i + (a + b)|1i,if s=1<br/>
As, the two possible output states are different, it shows this method is non-deterministic. One could end up with any of the two states and there is no certainty. Nevertheless, we observe that if X gate is operated on the second qubit after measurement if outcome is 1, both the equations would be same and hence, obtained state is H |ψi.<br/>
Flow construction is the semanticism to construct the measurement pattern for a given graph state. It gives the Pauli corrections for a particular qubit in the graph state, called X and Z dependencies. In simpler words, it records the effect of shifting all Pauli X and Z corrections to the left of (after performing) Entanglement and Entanglement operations, respectively, for each qubit. The result is recorded as sets of X, Z corrections required for each site. These sets depend on the graph state and not the computation or measurement results. Hence, it can be computed while choosing the graph state for a required computation. Following we illustrate how to construct such models with ease using Measurement Calculus to invoke determinism in One-Way Quantum Computation(MBQC).<br/>
Choose a unitary gate for the circuit and hence, its measurement pattern. In order to implement this pattern on a graph state, there are four basic steps: Preparation, Entanglement, Measurement, Corrections.<br/>
*''Preparation'' prepares all input qubits in the required state, generally represented as |+θi = ) where
*''Entanglement'' entangles all the qubits according to the required graph state. This operation is denoted by Eij, where C-Z is operated with i as control qubit and j as target qubit.<br/>
*''Measurement'' assigns measurement angle in X-Y plane for each qubit. Measurement operator is notated as Miα: the qubit ’i’ would be measured in {|+αi,|−αi} basis i.e. if the state is ) one gets outcome 0 and if the state is ), the outcome is 1.<br/>
*''Correction'' calculates all Pauli corrections to be applied on a given qubit in the pattern. The set of such parameters are called Dependencies for X and Z operators individually. To calculate all the Pauli Corrections on a given qubit, one needs to take into account the measurement outcomes of previous qubits as well as commutation relations. Both affect the Pauli corrections for a given qubit. Below is a formalism to explain the process with an example.<br/>
The effect of X gate on a measurement angle (α) in X-Y plane is to change its sign and Z gate is to add a phase π.<br/>
t α s α t s (−1)sα+tπ [Mi ] = Mi Z X = Mi{equation missing}π<br/>
We shall denote measurement in X-basis ({equation missing} and Y-basis ({equation missing}<br/>
Commutation relations:<br/>
EijXis = XisZisEij (EX)<br/>
EijXjs = XjsZjsEij (EX)<br/>
EijZit = ZitEij (EZ){equation missing} <br/>
= (EZ){equation missing} <br/>
t α s r<br/>
[Mi ] Xi = t α s+r[Mi ]{equation missing}(MX)<br/>
MixXis = Mix (MX){equation missing} <br/>
= (MZ){equation missing} <br/>
The last second equation is implied from the fact that for , x=0=-0. Thus, X gate has no effect on measurement in X-basis for the given states. Using above notations we express the equation for circuit model of C-NOT from Figure 6 with two inputs and two outputs: Qubits: 1,2,3,4<br/>
Outcomes: s1,s2,s3,s4<br/>
Circuit Operation: .<br/>
EX =⇒{equation missing} <br/>
EX =⇒{equation missing} <br/>
MX =⇒{equation missing} <br/>
X4s3Z4s2Z1s2M3xM2xE13E234{equation missing} <br/>
Hence, we obtain a measurement pattern to implement C-NOT gate with a T-shaped graph state with three qubits entangled chain {2,3,4} and 1 entangled to 3. X dependency sets for qubit 1:{s3}, 2:φ, 3:φ, 4:φ. Z dependency sets for qubit 1:{s2}, 2:φ, 3:φ, 4:{s2}. The measurements are independent of any outcome so they can all be performed in parallel. In the end, Pauli corrections are performed as such. Parity (modulo 2 sum) of all the previous outcomes in the dependency set is calculated for each qubit{equation missing} (i), for X (sXi = s1 ⊕ s2 ⊕ ...) and Z (sZi = s1 ⊕ s2 ⊕ ...), separately. Thus, is operated on qubit i.{equation missing} <br/>
===Quantum Capable Homomorphic Encryption===
*'''Homomorphic Encryption'''<br/>A homomorphic encryption scheme HE is a scheme to carry out classical computation from the Server while hiding the inputs, outputs and computation. It can be divided into following four stages.
* ''Key Generation.'' The algorithm (pk,evk,sk) ← HE.Keygen(1λ) takes a λ, a security parameter as input and outputs a public key encryption key pk, a public evaluation key evk and a secret decryption key sk.
* ''Encryption.'' The algorithm c ← HE.Encpk(µ) takes the public key pk and a single bit message µ ∈ {0,1} and outputs a ciphertext c. The notation HE.Encpk(µ;r) is be used to represent the encryption of a bit µ using randomness r.
* ''Decryption''. The algorithm µ∗ ← HE.Decsk(c) takes the secret key sk and a ciphertext c and outputs a message µ∗ ∈ {0,1}.
* ''Homomorphic Evaluation'' The algorithm cf ← HE.Evalevk(f,c1,...,cl) takes the evaluation key evk, a function f : {0,1}l → {0,1} and a set of l ciphertexts c1,...,cl, and outputs a ciphertext cf. It must be the case that:
HE.Decsk(cf) = f(HE.Decsk(c1),...,HE.Decsk(cl)) (1)
with all but negligible probability in λ. This means classical HE decrypts ciphertext bit by bit.
HE scheme is compact if HE.Eval is independent of any inputs or computation. It is fully homomorphic if it can compute any boolean computation.
*'''Quantum Capable'''<br/>
''A classical HE is quantum capable if it can be used to evaluate quantum circuits.''
Any HE scheme to be quantum capable requires the following two properties.
*''invariance of ciphertext:''
*''natural XOR operation:''

===Garden Hose Complexity Model===
*Gadget Construction for QFHE
===Encrypted CNOT operation===
===Fault Tolerance===
===Quantum Error Correction===
*Quantum Error Correcting Codes (QECCs)

*Stabilizer Codes

===Topological Error Correction===

MediaWiki:Sidebar

2018-11-07T15:33:06Z

Ahmed:

Protocol Library

2018-11-07T15:32:23Z

Ahmed: Ahmed moved page Protocol library to Protocol Library

{| class="wikitable"
!width="40%"|Functionality
!width="60%"|Protocols
|-
|rowspan="3"|[[ Quantum Digital Signature]] || [[Prepare and Measure Quantum Digital Signature]]
|-
|[[Quantum Digital Signature with Quantum Memory]]
|-
|[[Measurement Device Independent Quantum Digital Signature (MDI-QDS)]]
|-
|rowspan="3"| [[Secure Delegated Quantum Computation]] || [[Prepare and Send-Universal Blind Quantum Computation]]
|-
| [[Prepare and Send Quantum Fully Homomorphic Encryption]]
|}

Protocol Library

2018-11-07T15:18:06Z

Ahmed:

{| class="wikitable"
|+ Table Caption
!width="10%"|Functionality
!width="90%"|Protocols
|-
|[[ Quantum Digital Signature]] || [[Prepare and Measure Quantum Digital Signature]], [[Quantum Digital Signature with Quantum Memory]], [[Measurement Device Independent Quantum Digital Signature (MDI-QDS)]]
|-
| [[Secure Delegated Quantum Computation]] || [[Prepare and Send-Universal Blind Quantum Computation]], [[Prepare and Send Quantum Fully Homomorphic Encryption]]
|}

{| class="wikitable"
|-
!scope=col| Column 1
!scope=col| Column 2
!scope=col| Column 3
|-
| rowspan="2" | A
| colspan="2" style="text-align: center;" | B
|-
| C 
| D
|-
| E
| rowspan="2" colspan="2" style="text-align: center;" |F
|-
| G 
|-
| colspan="3" style="text-align: center;" | H
|}

Main Page

2018-11-07T15:13:19Z

Ahmed: Changed protection level for "Main Page" ([Edit=Allow only autoconfirmed users] (indefinite) [Move=Allow only autoconfirmed users] (indefinite))

'''Welcome to The Quantum Protocol Zoo-''' ''Explore, Learn and Implement Quantum Protocols''<br/><br/>The Quantum Protocol Zoo is open repository of quantum protocols which provides a medium to explore all such protocols presented in a compressed form in order to communicate with the computer scientists, engineers and physicists on one platform.

== Getting started ==
Quantum Protocol Zoo encompasses a set of General Functionality Descriptions of different quantum and classical functionalities achieved by various quantum protocols. This description elicits the different methods used by various protocols. Each such method is described by a formal description illustrating a simple yet detailed outline of the method, its properties and relevant papers. The description is written keeping a general audience in mind and a mathematical algorithm of the same is also provided. The section on relevant papers encompass all the various protocols published so far which imply similar method and properties. The different descriptions are interlinked by means of related terms called "tags". Some use case and technological readiness of the method are also highlighted to indicate any near term implementation or scope of the protocol. Finally, all esoteric concepts used in any description are explained via links to [[Appendix]].<br/><br/>
'*'Each page is independent and does not require any extra information yet links are provided for better understanding of some concepts in all such descriptions. Following is the structure for all formal descriptions available on Quantum Protocol Zoo.

==Structure==
*'''Functionality Description'''</br>
A lucid definition of functionality achieved and properties satisfied by the method used.
----
*'''Use Case'''</br>
Bridges the gap between users and protocol designers.

'''Tags:''' Any related page or list of protocols is connected by this section
----
*'''Outline'''</br>
A non-mathematical detailed outline which provides a rough idea of the method described. A figure is accommodated for most protocols.
----
*'''Requirements'''</br>
#Network Stage:
#Technological Readiness:
----
*'''Example:''' link to the example paper to be discussed below is provided here
#'''Properties''' A list of important information extracted from the protocol such as, Parameters (threshold values), security claim, success probability, adversarial assumption (see [[Quantum Adversary Definitions|Quantum Adversary Definitions)]], setup assumptions, etc..
#'''Pseudo Code''' Mathematical step-wise protocol algorithm
----
*'''Relevant papers'''</br>
Protocols easy to interpret after reading the concerned formal description, listed in chronological order.
----

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Main Page

2018-11-07T15:12:59Z

Ahmed: Changed protection level for "Main Page" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

'''Welcome to The Quantum Protocol Zoo-''' ''Explore, Learn and Implement Quantum Protocols''<br/><br/>The Quantum Protocol Zoo is open repository of quantum protocols which provides a medium to explore all such protocols presented in a compressed form in order to communicate with the computer scientists, engineers and physicists on one platform.

== Getting started ==
Quantum Protocol Zoo encompasses a set of General Functionality Descriptions of different quantum and classical functionalities achieved by various quantum protocols. This description elicits the different methods used by various protocols. Each such method is described by a formal description illustrating a simple yet detailed outline of the method, its properties and relevant papers. The description is written keeping a general audience in mind and a mathematical algorithm of the same is also provided. The section on relevant papers encompass all the various protocols published so far which imply similar method and properties. The different descriptions are interlinked by means of related terms called "tags". Some use case and technological readiness of the method are also highlighted to indicate any near term implementation or scope of the protocol. Finally, all esoteric concepts used in any description are explained via links to [[Appendix]].<br/><br/>
'*'Each page is independent and does not require any extra information yet links are provided for better understanding of some concepts in all such descriptions. Following is the structure for all formal descriptions available on Quantum Protocol Zoo.

==Structure==
*'''Functionality Description'''</br>
A lucid definition of functionality achieved and properties satisfied by the method used.
----
*'''Use Case'''</br>
Bridges the gap between users and protocol designers.

'''Tags:''' Any related page or list of protocols is connected by this section
----
*'''Outline'''</br>
A non-mathematical detailed outline which provides a rough idea of the method described. A figure is accommodated for most protocols.
----
*'''Requirements'''</br>
#Network Stage:
#Technological Readiness:
----
*'''Example:''' link to the example paper to be discussed below is provided here
#'''Properties''' A list of important information extracted from the protocol such as, Parameters (threshold values), security claim, success probability, adversarial assumption (see [[Quantum Adversary Definitions|Quantum Adversary Definitions)]], setup assumptions, etc..
#'''Pseudo Code''' Mathematical step-wise protocol algorithm
----
*'''Relevant papers'''</br>
Protocols easy to interpret after reading the concerned formal description, listed in chronological order.
----

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Template:Drop down list

2018-11-07T14:59:37Z

Ahmed:

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">
{{{Value1|Lorem}}}<br>
{{{Value2|}}}<br>
{{{Value3|}}}<br>
{{{Value4|}}}<br>
{{{Value5|}}}<br>
{{{Value6|}}}<br>
{{{Value7|}}}<br>
{{{Value8|}}}<br>
</div></div>
</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

Template:Drop down list

2018-11-07T14:59:04Z

Ahmed:

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
{<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">
{{{Value1|Lorem}}}<br>
{{{Value2|}}}<br>
{{{Value3|}}}<br>
{{{Value4|}}}<br>
{{{Value5|}}}<br>
{{{Value6|}}}<br>
{{{Value7|}}}<br>
{{{Value8|}}}<br>
</div></div>
|}</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

Template:Drop down list

2018-11-07T14:57:39Z

Ahmed:

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
{| cellspacing="0" style="border-collapse: collapse; width: 75px; font-size: 0.9em; border: 0.5px solid black; background-color: white; margin: -.2em 0 0 0;"
|-
! colspan="2" style="border-bottom: 0.5px solid black; background-color: white; text-align: left; padding-left: .7em;" |<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">
{{{Value1|Lorem}}}<br>
{{{Value2|}}}<br>
{{{Value3|}}}<br>
{{{Value4|}}}<br>
{{{Value5|}}}<br>
{{{Value6|}}}<br>
{{{Value7|}}}<br>
{{{Value8|}}}<br>
</div></div>
|}</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

Template:Drop down list

2018-11-07T14:56:46Z

Ahmed:

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
{| cellspacing="0" style="border-collapse: collapse; width: 75px; font-size: 0.9em; border: 0.5px solid black; background-color: white; margin: -.2em 0 0 0;"
|-
! colspan="2" style="border-bottom: 0.5px solid black; background-color: white; text-align: left; padding-left: .7em;" |<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">
{{{Value1|Lorem}}}<br>
{{{Value2|}}}<br>
{{{Value3|Lorem}}}<br>
{{{Value4|Lorem}}}<br>
{{{Value5|Lorem}}}<br>
{{{Value6|Lorem}}}<br>
{{{Value7|Lorem}}}<br>
{{{Value8|}}}<br>
</div></div>
|}</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

Template:Drop down list

2018-11-07T14:55:56Z

Ahmed:

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
{| cellspacing="0" style="border-collapse: collapse; width: 75px; font-size: 0.9em; border: 0.5px solid black; background-color: white; margin: -.2em 0 0 0;"
|-
! colspan="2" style="border-bottom: 0.5px solid black; background-color: white; text-align: left; padding-left: .7em;" |<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">

</div></div>
|}</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

Template:Drop down list

2018-11-07T14:54:12Z

Ahmed: Created page with "<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list"> {| cellspacing="0" style="border-collapse: collapse; width: 75px; font-size: 0.9em; border: 0.5px..."

<includeonly><div class="metadata" style="z-index: 100;" id="Drop-down-list">
{| cellspacing="0" style="border-collapse: collapse; width: 75px; font-size: 0.9em; border: 0.5px solid black; background-color: white; margin: -.2em 0 0 0;"
|-
! colspan="2" style="border-bottom: 0.5px solid black; background-color: white; text-align: left; padding-left: .7em;" |<div class="mw-customtoggle-{{{id|desks}}}">
{{{Name|Text}}}   [[File:MediaWiki Vector skin action arrow.png|link=]]
</div>
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-{{{id|desks}}}" style="padding:0px; border:0px;">
<div class="mw-collapsible-content" style="text-align:left;">
{{{Value1|Lorem}}}<br>
{{{Value2|borem}}}<br>
{{{Value3|Lorem}}}<br>
{{{Value4|Lorem}}}<br>
{{{Value5|Lorem}}}<br>
{{{Value6|Lorem}}}<br>
{{{Value7|Lorem}}}<br>
{{{Value8|Lorem}}}<br>
</div></div>
|}</div></includeonly>

<noinclude>{{documentation|content=
{{Template:Collapse Templates}}
==Usage==
This template can be transcluded to display a Drop down list. This template had 3 parameters (described below). '''The Id parameter''' is very important if you are using 2 drop down lists on the same page.

==Parameters==
This template contains 9 parameters for different purposes:

===Name===
This is the name parameter that shall display the name of the list, defaults to 'Text'. To set the name parameter type <code> <nowiki>{{Drop down list|Name=Name}}
</nowiki> </code> which will render as <br>{{Drop down list|Name=Name|id=name}}<br>
Examples:<br>
<code> <nowiki>{{Drop down list|Name=TW}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=TW|id=TW}}<br>
<code> <nowiki>{{Drop down list|Name=[[WP:TW|TW]]}} </nowiki> </code> renders as <br> <br>{{Drop down list|Name=[[WP:TW|TW]]|id=Twinkle}}

===Values===
The list can hold up to 8 values i.e the text within the list. To add the values type <code> <nowiki>{{Drop down list|Name=Name|Value1=Hello|Value2=Wikipedia|Value3=Blah!}} </nowiki> </code> and so on until
<code> <nowiki>Value8</nowiki> </code>. <br> The values support both Wikilinks and external links i.e you can also type <source lang="moin" inline>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]}} </source> which will render as <br><br>{{Drop down list|Name=Name|Value1=[[Hello]]|Value2=[[Wikipedia|'pedia]]|Value3=[https://www.google.co.in/ Google]|Value4=|Value5=|Value6=|Value7=|Value8=|id=Example}}

===Id===
If you are using more than one drop down list on the same page this parameter is '''very important'''. The Id parameter for each list should be different and unique (if using more than one on the same page). To set the ID type <code> <nowiki>{{Drop down list|id=Your Id name}}</nowiki> </code>
<source lang="html">
<div class="dropdown">
<button class="dropbtn">Dropdown</button>
<div class="dropdown-content">
<a href="#">Link 1</a>
<a href="#">Link 2</a>
<a href="#">Link 3</a>
</div>
</div>
</source>.

}}</noinclude>

[[Category:Layout templates]]

File:MediaWiki Vector skin action arrow.png

2018-11-07T14:44:05Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T14:22:14Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T14:22:00Z

Ahmed:

Protocol Library

2018-11-07T14:09:23Z

Ahmed: Created blank page

MediaWiki:Sidebar

2018-11-07T14:09:11Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T14:04:56Z

Ahmed:

Submissions

2018-11-07T13:41:27Z

Ahmed: Created page with "How to Submit"

How to Submit

MediaWiki:Sidebar

2018-11-07T13:40:44Z

Ahmed:

Secure Client- Server Delegated Computation

2018-11-07T13:11:11Z

Ahmed:

== Functionality Description==
Delegated Computation is the task of assigning computation on hidden data to a powerful untrusted party (a device) by a weak (in terms of computational powers) party while maintaining privacy of hidden data from the powerful party. Protocols under this functionality are commonly called Client (weak party)-Server (powerful party) protocols. Delegated Quantum Computation (DQC) protocols involve partially/fully classical Client delegating a quantum computation to fully powerful single/multiple quantum Server/Servers. All DQC protocols involve three main stages, Preparation Stage, Computation Stage and Output Correction Stage. The roles of Client and Server in the different stages may differ according to the type of communication used. It can be performed via classical and quantum communication. If it is carried out only during Preparation and Correction stage, it is called offline communication else if the communication is carried out during the computation stage, it is online communication. If the outcome can be verified by the Client it is a verifiable delegated quantum computation protocol. Hence, based on the above requirements, DQC protocols can be classified as follows.
===Classical Online Communication-Quantum Offline Communication===
It involves a partially quantum Client who can prepare and send quantum states use quantum offline communication to send input to the Server, in the preparation Stage and to receive outputs from the Server, during output correction. Client and Server then use classical online communication to exchange classical messages during computation phase. Universal Blind Quantum Computation (UBQC) falls under this category, where Client hides his input, output and computation from the Server using [[Supplementary Information#Measurement Based Quantum Computation|'''MBQC''']]. If the task performed by Server can be verified by the Client, it is Verifiable Universal Blind Quantum Computation (VUBQC). Classes of protocols under this category are:
*[[Prepare and Send-Universal Blind Quantum Computation|'''Prepare and Send UBQC''']]
*[[Prepare and Send Verifiable Universal Blind Quantum Computation|'''Prepare and Send VUBQC''']].
[[Category:Two Party Protocols]]

===Classical Online Communication-Quantum Online Communication===
It involves a partially quantum Client who can measure quantum states use quantum and classical communication throughout the protocol. Client performs the hidden [[Supplementary Information|MBQC]] on states prepared by Server using her measurement device in the computation Stage. She then corrects her classical outcomes in Correction Stage. Classes of protocols under this category are:
*[[Measurement Only-Universal Blind Quantum Computation|'''Measurement Only UBQC''']]
*[[Measurement Only Verifiable Universal Blind Quantum Computation|'''Measurement Only VUBQC''']]

===Classical Online Communication-No Quantum Communication===
It involves a fully classical Client with no quantum power exchanging classical messages with the server throughout. This can be done using protocols for generating secret random qubits, under the functionality, Secret Random Qubit Generator (SQRG). One could append SQRG with UBQC to eliminate quantum communication. A verification protocol using SQRG is still an open question. Class of protocols for SQRG:
*[[Pseudo-Secret Random Qubit Generator|'''Pseudo-Secret Random Qubit Generator (PSRQG)''']].

===Classical Offline Communication-Quantum Offline Communication===
It involves a partially classical Client who can generate entanglement, use both classical and quantum communication with the Server during the preparation stage and output correction. There is no communication between the two parties during computation stage. Quantum Fully Homomorphic Encryption (QFHE) falls under this category, where Client hides her input states with the help of classical [[Supplementary Information#Homomorphic Encryption|'''Homomorphic Encryption''']]. In addition to this she also prepares some quantum gadgets (using [[Supplementary Information#entanglement|entanglement]]) which she sends with the encrypted state to Server, in the prepapration stage. Server uses the quantum gadgets for computation on the encrypted state. Such gadgets require steps which cannot be realized by classical HE scheme. Later Client decrypts/deciphers the outcome sent by Server to get the correct result, in the correction Stage. If the task performed by the Server can be verified by the Client, the protocol is called, Verifiable Quantum Fully Homomorphic Encryption (VQFHE). Classes of protocols under this category are:
*[[Prepare and Send Quantum Fully Homomorphic Encryption|'''Prepare and Send QFHE''']]
*[[Prepare and Send Verifiable Quantum Fully Homomorphic Encryption|'''Prepare and Send VQFHE''']]

===Classical Offline Communication-No Quantum Communication===
It involves a fully classical Client assign quantum computation to a Server on her classical input/output using only classical communication during the preparation stage and output correction. There is no communication between the two parties during computation stage. It uses only classical [[Supplementary Information#Homomorphic Encryption|Homomorphic Encryption]] and no quantum gadgets to realize a quantum function/computation. Quantum offline communication would be needed in case of quantum input/output. A verification scheme for such protocols is still an open question. Class of protocols under this category are:
*Quantum Capable Classical Fully Homomorphic Encryption [[Classical Fully Homomorphic Encryption for Quantum Circuits|'''(FHE) for Quantum Circuits''']]

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Multiparty Delegated Quantum Computation|Multiparty Delegated Quantum Computation]], [[Quantum Enhanced Classical Delegated Computation|Quantum Enhanced Classical Delegated Computation]]

[[Category:Universal Task]]

Secure Client- Server Delegated Computation

2018-11-07T13:10:27Z

Ahmed: /* Classical Online Communication-Quantum Offline Communication */

Secure Client- Server Delegated Computation

2018-11-07T13:09:46Z

Ahmed:

== Functionality Description==
Delegated Computation is the task of assigning computation on hidden data to a powerful untrusted party (a device) by a weak (in terms of computational powers) party while maintaining privacy of hidden data from the powerful party. Protocols under this functionality are commonly called Client (weak party)-Server (powerful party) protocols. Delegated Quantum Computation (DQC) protocols involve partially/fully classical Client delegating a quantum computation to fully powerful single/multiple quantum Server/Servers. All DQC protocols involve three main stages, Preparation Stage, Computation Stage and Output Correction Stage. The roles of Client and Server in the different stages may differ according to the type of communication used. It can be performed via classical and quantum communication. If it is carried out only during Preparation and Correction stage, it is called offline communication else if the communication is carried out during the computation stage, it is online communication. If the outcome can be verified by the Client it is a verifiable delegated quantum computation protocol. Hence, based on the above requirements, DQC protocols can be classified as follows.
===Classical Online Communication-Quantum Offline Communication===
It involves a partially quantum Client who can prepare and send quantum states use quantum offline communication to send input to the Server, in the preparation Stage and to receive outputs from the Server, during output correction. Client and Server then use classical online communication to exchange classical messages during computation phase. Universal Blind Quantum Computation (UBQC) falls under this category, where Client hides his input, output and computation from the Server using [[Supplementary Information#Measurement Based Quantum Computation|'''MBQC''']]. If the task performed by Server can be verified by the Client, it is Verifiable Universal Blind Quantum Computation (VUBQC). Classes of protocols under this category are:
*[[Prepare and Send-Universal Blind Quantum Computation|'''Prepare and Send UBQC''']]
*[[Prepare and Send Verifiable Universal Blind Quantum Computation|'''Prepare and Send VUBQC''']].

===Classical Online Communication-Quantum Online Communication===
It involves a partially quantum Client who can measure quantum states use quantum and classical communication throughout the protocol. Client performs the hidden [[Supplementary Information|MBQC]] on states prepared by Server using her measurement device in the computation Stage. She then corrects her classical outcomes in Correction Stage. Classes of protocols under this category are:
*[[Measurement Only-Universal Blind Quantum Computation|'''Measurement Only UBQC''']]
*[[Measurement Only Verifiable Universal Blind Quantum Computation|'''Measurement Only VUBQC''']]

===Classical Online Communication-No Quantum Communication===
It involves a fully classical Client with no quantum power exchanging classical messages with the server throughout. This can be done using protocols for generating secret random qubits, under the functionality, Secret Random Qubit Generator (SQRG). One could append SQRG with UBQC to eliminate quantum communication. A verification protocol using SQRG is still an open question. Class of protocols for SQRG:
*[[Pseudo-Secret Random Qubit Generator|'''Pseudo-Secret Random Qubit Generator (PSRQG)''']].

===Classical Offline Communication-Quantum Offline Communication===
It involves a partially classical Client who can generate entanglement, use both classical and quantum communication with the Server during the preparation stage and output correction. There is no communication between the two parties during computation stage. Quantum Fully Homomorphic Encryption (QFHE) falls under this category, where Client hides her input states with the help of classical [[Supplementary Information#Homomorphic Encryption|'''Homomorphic Encryption''']]. In addition to this she also prepares some quantum gadgets (using [[Supplementary Information#entanglement|entanglement]]) which she sends with the encrypted state to Server, in the prepapration stage. Server uses the quantum gadgets for computation on the encrypted state. Such gadgets require steps which cannot be realized by classical HE scheme. Later Client decrypts/deciphers the outcome sent by Server to get the correct result, in the correction Stage. If the task performed by the Server can be verified by the Client, the protocol is called, Verifiable Quantum Fully Homomorphic Encryption (VQFHE). Classes of protocols under this category are:
*[[Prepare and Send Quantum Fully Homomorphic Encryption|'''Prepare and Send QFHE''']]
*[[Prepare and Send Verifiable Quantum Fully Homomorphic Encryption|'''Prepare and Send VQFHE''']]

===Classical Offline Communication-No Quantum Communication===
It involves a fully classical Client assign quantum computation to a Server on her classical input/output using only classical communication during the preparation stage and output correction. There is no communication between the two parties during computation stage. It uses only classical [[Supplementary Information#Homomorphic Encryption|Homomorphic Encryption]] and no quantum gadgets to realize a quantum function/computation. Quantum offline communication would be needed in case of quantum input/output. A verification scheme for such protocols is still an open question. Class of protocols under this category are:
*Quantum Capable Classical Fully Homomorphic Encryption [[Classical Fully Homomorphic Encryption for Quantum Circuits|'''(FHE) for Quantum Circuits''']]

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Multiparty Delegated Quantum Computation|Multiparty Delegated Quantum Computation]], [[Quantum Enhanced Classical Delegated Computation|Quantum Enhanced Classical Delegated Computation]]

[[Category:Two Party Protocols]]
[[Category:Universal Task]]

Secure Client- Server Delegated Computation

2018-11-07T13:08:48Z

Ahmed:

== Functionality Description==
Delegated Computation is the task of assigning computation on hidden data to a powerful untrusted party (a device) by a weak (in terms of computational powers) party while maintaining privacy of hidden data from the powerful party. Protocols under this functionality are commonly called Client (weak party)-Server (powerful party) protocols. Delegated Quantum Computation (DQC) protocols involve partially/fully classical Client delegating a quantum computation to fully powerful single/multiple quantum Server/Servers. All DQC protocols involve three main stages, Preparation Stage, Computation Stage and Output Correction Stage. The roles of Client and Server in the different stages may differ according to the type of communication used. It can be performed via classical and quantum communication. If it is carried out only during Preparation and Correction stage, it is called offline communication else if the communication is carried out during the computation stage, it is online communication. If the outcome can be verified by the Client it is a verifiable delegated quantum computation protocol. Hence, based on the above requirements, DQC protocols can be classified as follows.
===Classical Online Communication-Quantum Offline Communication===
It involves a partially quantum Client who can prepare and send quantum states use quantum offline communication to send input to the Server, in the preparation Stage and to receive outputs from the Server, during output correction. Client and Server then use classical online communication to exchange classical messages during computation phase. Universal Blind Quantum Computation (UBQC) falls under this category, where Client hides his input, output and computation from the Server using [[Supplementary Information#Measurement Based Quantum Computation|'''MBQC''']]. If the task performed by Server can be verified by the Client, it is Verifiable Universal Blind Quantum Computation (VUBQC). Classes of protocols under this category are:
*[[Prepare and Send-Universal Blind Quantum Computation|'''Prepare and Send UBQC''']]
*[[Prepare and Send Verifiable Universal Blind Quantum Computation|'''Prepare and Send VUBQC''']].

===Classical Online Communication-Quantum Online Communication===
It involves a partially quantum Client who can measure quantum states use quantum and classical communication throughout the protocol. Client performs the hidden [[Supplementary Information|MBQC]] on states prepared by Server using her measurement device in the computation Stage. She then corrects her classical outcomes in Correction Stage. Classes of protocols under this category are:
*[[Measurement Only-Universal Blind Quantum Computation|'''Measurement Only UBQC''']]
*[[Measurement Only Verifiable Universal Blind Quantum Computation|'''Measurement Only VUBQC''']]

===Classical Online Communication-No Quantum Communication===
It involves a fully classical Client with no quantum power exchanging classical messages with the server throughout. This can be done using protocols for generating secret random qubits, under the functionality, Secret Random Qubit Generator (SQRG). One could append SQRG with UBQC to eliminate quantum communication. A verification protocol using SQRG is still an open question. Class of protocols for SQRG:
*[[Pseudo-Secret Random Qubit Generator|'''Pseudo-Secret Random Qubit Generator (PSRQG)''']].

===Classical Offline Communication-Quantum Offline Communication===
It involves a partially classical Client who can generate entanglement, use both classical and quantum communication with the Server during the preparation stage and output correction. There is no communication between the two parties during computation stage. Quantum Fully Homomorphic Encryption (QFHE) falls under this category, where Client hides her input states with the help of classical [[Supplementary Information#Homomorphic Encryption|'''Homomorphic Encryption''']]. In addition to this she also prepares some quantum gadgets (using [[Supplementary Information#entanglement|entanglement]]) which she sends with the encrypted state to Server, in the prepapration stage. Server uses the quantum gadgets for computation on the encrypted state. Such gadgets require steps which cannot be realized by classical HE scheme. Later Client decrypts/deciphers the outcome sent by Server to get the correct result, in the correction Stage. If the task performed by the Server can be verified by the Client, the protocol is called, Verifiable Quantum Fully Homomorphic Encryption (VQFHE). Classes of protocols under this category are:
*[[Prepare and Send Quantum Fully Homomorphic Encryption|'''Prepare and Send QFHE''']]
*[[Prepare and Send Verifiable Quantum Fully Homomorphic Encryption|'''Prepare and Send VQFHE''']]

===Classical Offline Communication-No Quantum Communication===
It involves a fully classical Client assign quantum computation to a Server on her classical input/output using only classical communication during the preparation stage and output correction. There is no communication between the two parties during computation stage. It uses only classical [[Supplementary Information#Homomorphic Encryption|Homomorphic Encryption]] and no quantum gadgets to realize a quantum function/computation. Quantum offline communication would be needed in case of quantum input/output. A verification scheme for such protocols is still an open question. Class of protocols under this category are:
*Quantum Capable Classical Fully Homomorphic Encryption [[Classical Fully Homomorphic Encryption for Quantum Circuits|'''(FHE) for Quantum Circuits''']]

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Multiparty Delegated Quantum Computation|Multiparty Delegated Quantum Computation]], [[Quantum Enhanced Classical Delegated Computation|Quantum Enhanced Classical Delegated Computation]]

[[Category:Two Party Protocols|ABC]]
[[Category:Universal Task]]

Secure Client- Server Delegated Computation

2018-11-07T13:03:20Z

Ahmed:

== Functionality Description==
Delegated Computation is the task of assigning computation on hidden data to a powerful untrusted party (a device) by a weak (in terms of computational powers) party while maintaining privacy of hidden data from the powerful party. Protocols under this functionality are commonly called Client (weak party)-Server (powerful party) protocols. Delegated Quantum Computation (DQC) protocols involve partially/fully classical Client delegating a quantum computation to fully powerful single/multiple quantum Server/Servers. All DQC protocols involve three main stages, Preparation Stage, Computation Stage and Output Correction Stage. The roles of Client and Server in the different stages may differ according to the type of communication used. It can be performed via classical and quantum communication. If it is carried out only during Preparation and Correction stage, it is called offline communication else if the communication is carried out during the computation stage, it is online communication. If the outcome can be verified by the Client it is a verifiable delegated quantum computation protocol. Hence, based on the above requirements, DQC protocols can be classified as follows.
===Classical Online Communication-Quantum Offline Communication===
It involves a partially quantum Client who can prepare and send quantum states use quantum offline communication to send input to the Server, in the preparation Stage and to receive outputs from the Server, during output correction. Client and Server then use classical online communication to exchange classical messages during computation phase. Universal Blind Quantum Computation (UBQC) falls under this category, where Client hides his input, output and computation from the Server using [[Supplementary Information#Measurement Based Quantum Computation|'''MBQC''']]. If the task performed by Server can be verified by the Client, it is Verifiable Universal Blind Quantum Computation (VUBQC). Classes of protocols under this category are:
*[[Prepare and Send-Universal Blind Quantum Computation|'''Prepare and Send UBQC''']]
*[[Prepare and Send Verifiable Universal Blind Quantum Computation|'''Prepare and Send VUBQC''']].

===Classical Online Communication-Quantum Online Communication===
It involves a partially quantum Client who can measure quantum states use quantum and classical communication throughout the protocol. Client performs the hidden [[Supplementary Information|MBQC]] on states prepared by Server using her measurement device in the computation Stage. She then corrects her classical outcomes in Correction Stage. Classes of protocols under this category are:
*[[Measurement Only-Universal Blind Quantum Computation|'''Measurement Only UBQC''']]
*[[Measurement Only Verifiable Universal Blind Quantum Computation|'''Measurement Only VUBQC''']]

===Classical Online Communication-No Quantum Communication===
It involves a fully classical Client with no quantum power exchanging classical messages with the server throughout. This can be done using protocols for generating secret random qubits, under the functionality, Secret Random Qubit Generator (SQRG). One could append SQRG with UBQC to eliminate quantum communication. A verification protocol using SQRG is still an open question. Class of protocols for SQRG:
*[[Pseudo-Secret Random Qubit Generator|'''Pseudo-Secret Random Qubit Generator (PSRQG)''']].

===Classical Offline Communication-Quantum Offline Communication===
It involves a partially classical Client who can generate entanglement, use both classical and quantum communication with the Server during the preparation stage and output correction. There is no communication between the two parties during computation stage. Quantum Fully Homomorphic Encryption (QFHE) falls under this category, where Client hides her input states with the help of classical [[Supplementary Information#Homomorphic Encryption|'''Homomorphic Encryption''']]. In addition to this she also prepares some quantum gadgets (using [[Supplementary Information#entanglement|entanglement]]) which she sends with the encrypted state to Server, in the prepapration stage. Server uses the quantum gadgets for computation on the encrypted state. Such gadgets require steps which cannot be realized by classical HE scheme. Later Client decrypts/deciphers the outcome sent by Server to get the correct result, in the correction Stage. If the task performed by the Server can be verified by the Client, the protocol is called, Verifiable Quantum Fully Homomorphic Encryption (VQFHE). Classes of protocols under this category are:
*[[Prepare and Send Quantum Fully Homomorphic Encryption|'''Prepare and Send QFHE''']]
*[[Prepare and Send Verifiable Quantum Fully Homomorphic Encryption|'''Prepare and Send VQFHE''']]

===Classical Offline Communication-No Quantum Communication===
It involves a fully classical Client assign quantum computation to a Server on her classical input/output using only classical communication during the preparation stage and output correction. There is no communication between the two parties during computation stage. It uses only classical [[Supplementary Information#Homomorphic Encryption|Homomorphic Encryption]] and no quantum gadgets to realize a quantum function/computation. Quantum offline communication would be needed in case of quantum input/output. A verification scheme for such protocols is still an open question. Class of protocols under this category are:
*Quantum Capable Classical Fully Homomorphic Encryption [[Classical Fully Homomorphic Encryption for Quantum Circuits|'''(FHE) for Quantum Circuits''']]

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Multiparty Delegated Quantum Computation|Multiparty Delegated Quantum Computation]], [[Quantum Enhanced Classical Delegated Computation|Quantum Enhanced Classical Delegated Computation]]

[[Category:Two Party Protocols]]
[[Category:Universal Task]]

Category:Two Party Protocols

2018-11-07T13:02:20Z

Ahmed:

Following is a list of Two Party Quantum Communication Protocols.

[[Category:Categories]]

MediaWiki:Sidebar

2018-11-07T13:00:23Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T12:58:15Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T12:57:01Z

Ahmed:

Category:Building Blocks

2018-11-07T12:54:19Z

Ahmed: Ahmed moved page Building Blocks to Category:Building Blocks

This page lists all the protocols which could act as a building block to set up Quantum Network and Communication

*[[Entanglement Purification and Distillation|Entanglement Purification and Distillation]]
*[[Hash Functions|Hash Functions]]
*[[Network Routing|Network Routing]]
*[[Quantum Cloning|Quantum Cloning]]
*[[Quantum Deleting|Quantum Deleting]]
*[[Quantum Key Distribution (QKD)|Quantum Key Distribution (QKD)]]
*[[Quantum Memory|Quantum Memory]]
*[[Quantum Teleportation|Quantum Teleportation]]
*[[Superposition of Unknown Quantum States|Superposition of Unknown Quantum States]]

Quantum Digital Signature

2018-11-07T12:50:15Z

Ahmed:

==Functionality==
Digital Signatures (DS) allow for the exchange of single or multiple bit classical messages from sender to multiple recipients, with a guarantee that the signature has come from a genuine sender and the properties of transferability, non-repudiation and unforgeability (see [[Properties]]).

==Protocols==
For simlicity, most protocols use the case of three parties, one sender (Seller) and two recipients (Buyer and Verifier) exchanging one-bit classical messages signed by Quantum Digital Signatures (QDS).

*[[Quantum Digital Signature with Quantum Memory]]
*[[Prepare and Measure Quantum Digital Signature]]
*[[Measurement Device Independent Quantum Digital Signature (MDI-QDS)]]

==Use Case==
Signing e-Marksheet, Financial Transactions, Software Distribution, Cryptocurrencies, e-voting

Tags: [[Multi Party Protocols|Multi Party]], [[Quantum Enhanced Classical Functionality]], [[Specific Task]], [[Blind Quantum Digital Signature]], [[Arbitrated Signature]], [[Quantum Proxy Signature]], [[Designated Verifiable Quantum Signature]], [[Limited Delegation of Quantum Signature]]

==Properties==
All QDS protocols are divided into two phases, distribution and messaging. Distribution phase enables sender to generate private keys (kept secret with sender) and public keys (distributed to recipients) while messaging phase enables exchange of messages using the above keys.
*A QDS scheme is correct if a message signed by a genuine sender is accepted by a recipient with unit probability.
*A QDS scheme is secure if no one but the sender can sign a message such that it is accepted by a recipient with non-negligible probability.
*'''Transferability''' means that at any point a recipient (buyer) can prove it to another recipient (verifier) that the concerned message has been signed by the claimed sender (Seller).
*'''Unforgeability''' ensures that a dishonest recipient (buyer) can neither alter a DS nor sign a message with a fake DS (DS that has not come from a genuine sender) and forward it to other recipients (verifier) successfully.
*'''Non-Repudiation''' implies that at any point a dishonest sender (seller) cannot deny having signed the message sent to a genuine recipient (Buyer).

==Discussion==
(Review Paper by Petros)
[[Category:Multi Party Protocols]]

MediaWiki:Sidebar

2018-11-07T12:45:33Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T12:44:44Z

Ahmed:

Category:Universal Task

2018-11-07T12:43:28Z

Ahmed:

Following is a list of Universal Tasks carried out by quantum communication protocols.

*[[Secure Delegated Quantum Computation|Quantum Fully Homomorphic Encryption]]
*[[Pseudo-Secret Random Qubit Generator|Secret Random Qubit Generator (SQRG)]]
*[[Secure Delegated Quantum Computation|Universal Blind Quantum Computation]]
[[Category:Categories]]

Category:Specific Task

2018-11-07T12:43:12Z

Ahmed:

Following is a list of Specific Tasks carried out by Quantum Communication Protocols

*[[Quantum Digital Signature|Digital Signature (DS)]]
*[[Quantum Money|Money]]
*[[Quantum Secret Sharing|Secret Sharing]]
[[Category:Categories]]

Category:Network Stages

2018-11-07T12:41:21Z

Ahmed:

The different stages as stated by Stephanie Wehner's paper to which the various protocols belong are listed here.

[[Category:Categories]]

Category:Multi Party Protocols

2018-11-07T12:40:55Z

Ahmed:

Following is a list Multy Party (more than two) Quantum Communication Protocols

*[[Quantum Digital Signature|Quantum Digital Signature (QDS)]]
*[[Quantum Key Distribution|Quantum Key Distribution (QKD)]]
*[[Quantum Money| Quantum Money]]
[[Category:Categories]]

Category:Universal Task

2018-11-07T12:39:54Z

Ahmed: Ahmed moved page Universal Task to Category:Universal Task

Category:Specific Task

2018-11-07T12:38:53Z

Ahmed: Ahmed moved page Specific Task to Category:Specific Task

Category:Network Stages

2018-11-07T12:38:22Z

Ahmed: Ahmed moved page Network Stages to Category:Network Stages

The different stages as stated by Stephanie Wehner's paper to which the various protocols belong are listed here.

Category:Multi Party Protocols

2018-11-07T12:36:57Z

Ahmed: Ahmed moved page Multi Party Protocols to Category:Multi Party Protocols

Category:Two Party Protocols

2018-11-07T12:35:26Z

Ahmed:

Following is a list of Two Party Quantum Communication Protocols.

*[[Secure Delegated Quantum Computation|Delegated Computation/Client-Server]]
*[[Pseudo-Secret Random Qubit Generator|Secret Random Qubit Generator (SQRG)]]

[[Category:Categories]]

Category:Two Party Protocols

2018-11-07T12:35:10Z

Ahmed:

Category:Two Party Protocols

2018-11-07T12:34:56Z

Ahmed:

MediaWiki:Sidebar

2018-11-07T12:33:15Z

Ahmed:

Category:Categories

2018-11-07T12:31:58Z

Ahmed: Created blank page

Pseudo-Secret Random Qubit Generator (PSQRG)

2018-11-07T12:24:57Z

Ahmed:

==Functionality Description==
Secret Random Qubit Generator (SQRG) enables fully-classical parties to generate secret single qubit states using only public classical channels and a single quantum Server. This functionality could be used to replace a quantum channel completely such that a classical Client can perform various quantum applications over classical network connected to a quantum Server. An application of this functionality could be to carry out [[Secure Delegated Quantum Computation#Classical Online Communication-No Quantum Communication|Secure Delegated Quantum Computation]] by just classical online communication and no quantum communication. It allows a fully classical Client to hide her data such that she instructs Server to generate random single qubit states hiding her inputs, outputs, circuit and perform quantum computation on it via [[Prepare and Send-Universal Blind Quantum Computation|UBQC]] or [[Verifiable Universal Blind Quantum Computation|VUBQC]]. It can also find use cases in other protocols like Quantum Money, Quantum Digital Signatures etc.. which need user to share his/her private quantum key over a quantum channel.

==Use Case==
*Replacing quantum channels by classical channels for quantum cloud computing
*Generating random qubits for protocols like quantum-key-distribution, quantum money, quantum coin-flipping, quantum signatures, two-party quantum computation, multiparty quantum computation etc.

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Secure Delegated Quantum Computation#Classical Online Communication-No Quantum Communication|Secure Delegated Quantum Computation]], Classical Online Communication, [[Supplementary Information#Superposition|Superposition]], [[Supplementary Information#Collision Resistant Functions|Collision Resistant Functions]], [[Supplementary Information#Learning With Errors|Learning With Errors]]

== Outline ==
The general idea is that a classical Client gives instructions to a quantum Server to perform certain actions (quantum computation). Those actions lead to the Server having as output a single qubit, which is randomly chosen from within a set of chosen (by the Client) states. On the other hand, Client is supposed to know the classical description of Server's output qubit. To achieve this task, the instructions/quantum computation the Client uses are based on a family of trapdoor, two regular, one-way functions with certain extra properties (see Properties and Definitions). Trapdoor one-way functions are hard to invert (e.g. for the Server) unless someone (the Client in this case) has some extra “trapdoor” information. Two-regular functions have two pre-images for every value in the range of the function. This extra information helps the Client classically reproduce the quantum computation to recover the classical description of the single qubit state, while it is still hard to classically reproduce for the Server, the same information as Client. Simple modifications to the protocol could achieve other similar sets of states.<br/><br/>
The protocol can be divided into two stages, Pre-images Superposition, where Client instructs the Server to generate superposition using the function with above properties and, Squeezing, where the Server is instructed by the Client to measure his output qubits and deliver outcomes, which she (Client) would use to classically compute the value of r.
*'''Preparation.''' Client randomly selects a function with required properties, which is public (Server knows), but the trapdoor information needed to invert the function is known only to the Client.
*'''Preimages Superposition.''' Server prepares two quantum registers (system comprising multiple qubits), first being control (containing inputs) and second being target (containing output of the function). Client instructs Server to create a superposition of input states by applying [[Hadamard|Hadamard gate]] (quantum fourier transform) on control register. She then instructs Server to apply a [[unitary gate|unitary gate]] (all quantum gates are represented by unitary matrices) which computes output of the function in the target register, taking input from the control register, thus yielding an entangled state from the Server's superposition state. Server is required to measure the target register in the computational basis (along Z axis) and get an outcome. This action would reduce the control register into a superposition of two pre-images corresponding to the measurement outcome of the target register. He conveys this outcome to the Client who computes, classically, the two pre-images using her trapdoor. This pair of pre-image would have some isolated similar qubits (without superposition) and a superposition of dissimilar qubits. The dissimilar qubits can be written as a superposition of isolated 0s and isolated 1s (a GHZ state), with [[X(NOT)|X (NOT) gates]] applied to qubits depending on the state of qubit in both the pre-images. If the last qubit belongs to the set of similar qubits, then Client aborts and this Stage is repeated.
*'''Squeezing.''' Client instructs Server to measure all the qubits of the control register in some basis chosen randomly by the Client, except the last one, and return to her the outcomes. The last unmeasured state contains the randomly prepared qubit hidden from the Server. Client can then compute the value of r by an equation (see Pseudo Code). This equation depends only on Client’s measurement basis angles, Server’s measurement outcome and the location of random X’s (unknown to the Server). Thus, the Client knows the state of her secret qubit prepared by the Server.

Figure
==Requirements==

==Pseudo-Code==
*Notations
**<math>f_k</math>, function for target register
**<math>t_k</math>, trapdoor for function <math>f_k</math>
**<math>U_{f_k}</math>, Unitary operated on the target register taking first register as control, used to compute output of the function in the target register
**y, measurement outcome of the target register
**<math>x,x'</math>, pre-image pair for a given measurement outcome y
**<math>x_i</math> value of qubit i for pre-image x
**<math>x_i'</math> value of qubit i for pre-image x’
**<math>\alpha_i</math>, Client’s measurement angles for qubit i in the control register
**<math>b_i</math>, Server’s measurement outcome for qubit i in the control register
**<math>\theta</math>, classical description of the hidden input state

==='''Stage1''' Preimages superposition===
*'''Input:''' Client uniformly samples a set of random three-bits strings α = (α1,··· ,αn−1) where αi ← {0,1}3, and runs the algorithm (k,tk) ← GenF(1n). The α and k are public inputs (known to both parties), while tk is the “private” input of the Client, A public function family F = {fk : {0,1}n → {0,1}m} of trapdoor one-way functions that are quantum safe, two-regular and collision resistant (or second preimage resistant) (See Supplementary Information for Function Construction)

#Client: instructs Server to prepare one register at ⊗nH |0i and second register initiated at |0im
#Client: returns k to Server and the Server applies Ufk using the first register as control and the second as target
#Server: measures the second register in the computational basis, obtains the outcome y and returns this result y to the Client. Here, an honest Server would have a state (|xi + |x0i) ⊗ |yi with fk(x) = fk(x0) = y and y ∈ =fk.
Client can rewrite the superposition in the control register for herself as,
{missing equation}
where G¯ is the set of bits positions where x,x0 are identical, G is the set of bits positions where the preimages differ, while suitably changing the order of writing the qubits.

==='''Stage2''' Squeezing===
*'''Output''': If the protocol is run honestly, when there is no abort, the state that Server has is |+θi, where the Client (only) knows the classical description.
#Client: instructs the Server to measure all the qubits (except the last one) of the first register in the basis. Server obtains the outcomes b = (b1,··· ,bn−1) and returns the result b to the Client
#Client: using the trapdoor tk computes x,x0. Then check if the nth bit of x and x0 (corresponding to the y received in stage 1) are the same or different. If they are the same, returns abort, otherwise, obtains the classical description of the Server’s state.

== Properties ==
*<math>f_k</math>, the function with required properties as given below in point 4.
*n, number of qubits in the control register.
*This protocol assumes an honest Client and proves security only for an adversarial Server.
*This protocol takes the assumption of a Quantum Honest But Curious (QHBC) adversary setting i.e. the protocol is secure against an honest Server who just wants to know Client’s hidden data but not modify it without Client’s consent.
*The function used for the protocol is required to satisfy the following properties: one-way, trapdoor, two-regular, collision resistance, quantum-safe (See Definitions).
*This protocol is secure under learning with errors assumption i.e. it relies on assumption over a quantum Server to be unable solve a computationally hard problem.
*The protocol assumes that all quantum operators are described by polynomially-sized circuits.
*The randomness of the output qubit is due to the (fundamental) randomness of quantum measurements that are part of the instructions that the Client gives.
*The Server cannot guess the state any better than if he had just received that state directly from the Client (up to negligible probability).
*''Correctness'' If both the Client and the Server follow the protocol, the protocol aborts when {missing equation}, while otherwise the Server ends up with the output (single) qubit being in the state ), where <math>\theta</math> is given by [[equation|equation]] (see Pseudo Code).
* The single qubit state generated by the protocol remains private against a QHBC Server.

==Definitions (informal)==
*''Quantum-Safe'' A protocol/function is quantum-safe (also known as post-quantum secure), if all its properties remain valid when the adversaries are quantum polynomial-time (QPT).
*''One-Way'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is one-way if there exists a QPT algorithm that can compute <math>f_k(x)</math> for any k, any input x ∈ D, and any QPT algorithm can invert <math>f_k</math> with at most negligible probability over the choice of k.
*''Second pre-image Resistant'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is second pre-image resistant if there exists a QPT algorithm that can compute <math>f_k(x)</math> for any index function k, any input x ∈ D, and given an input x, it can find a different input <math>x_0</math> such that <math>f_k(x) = f_k(x')</math> with at most negligible probability over the choice of k.
*''Collision Resistant'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is collision resistant if there exists a QPT algorithm that can compute <math>f_k(x)</math> for any index function k, any input <math>x \epsilon D</math>, any QPT algorithm can find two inputs <math>x \neq x'</math> such that <math>f_k(x) = f_k(x')</math> with at most negligible probability over the choice of k.
*''Two-regular'' A deterministic function <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is two-regular if <math>\forall y \epsilon Im(f)</math>, we have <math>|f^{-1}(y)| = 2</math>
*''Trapdoor Function'' A family of functions <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math> is a trapdoor function if there exists a QPT algorithm Gen which on input <math>1^n</math> outputs <math>(k,t_k)</math>, where k represents the index of a function, <math>\{f_k : D \rightarrow R\}_{k\epsilon \{0,1\}}</math>, where <math>f_k</math> is a one-way function, then there exists a QPT algorithm Inv, which on inputs <math>t_k</math> (which is called the trapdoor information) which was output by Gen(<math>1^n</math>), and <math>y = f_k(x)</math> can invert y (by returning all pre-images of y with non-negligible probability over the choice of <math>(k,t_k)</math> and uniform choice of x.

==Relevant Papers==

[[Category:Two Party Protocols]]

Secure Client- Server Delegated Computation

2018-11-07T12:23:13Z

Ahmed:

== Functionality Description==
Delegated Computation is the task of assigning computation on hidden data to a powerful untrusted party (a device) by a weak (in terms of computational powers) party while maintaining privacy of hidden data from the powerful party. Protocols under this functionality are commonly called Client (weak party)-Server (powerful party) protocols. Delegated Quantum Computation (DQC) protocols involve partially/fully classical Client delegating a quantum computation to fully powerful single/multiple quantum Server/Servers. All DQC protocols involve three main stages, Preparation Stage, Computation Stage and Output Correction Stage. The roles of Client and Server in the different stages may differ according to the type of communication used. It can be performed via classical and quantum communication. If it is carried out only during Preparation and Correction stage, it is called offline communication else if the communication is carried out during the computation stage, it is online communication. If the outcome can be verified by the Client it is a verifiable delegated quantum computation protocol. Hence, based on the above requirements, DQC protocols can be classified as follows.
===Classical Online Communication-Quantum Offline Communication===
It involves a partially quantum Client who can prepare and send quantum states use quantum offline communication to send input to the Server, in the preparation Stage and to receive outputs from the Server, during output correction. Client and Server then use classical online communication to exchange classical messages during computation phase. Universal Blind Quantum Computation (UBQC) falls under this category, where Client hides his input, output and computation from the Server using [[Supplementary Information#Measurement Based Quantum Computation|'''MBQC''']]. If the task performed by Server can be verified by the Client, it is Verifiable Universal Blind Quantum Computation (VUBQC). Classes of protocols under this category are:
*[[Prepare and Send-Universal Blind Quantum Computation|'''Prepare and Send UBQC''']]
*[[Prepare and Send Verifiable Universal Blind Quantum Computation|'''Prepare and Send VUBQC''']].

===Classical Online Communication-Quantum Online Communication===
It involves a partially quantum Client who can measure quantum states use quantum and classical communication throughout the protocol. Client performs the hidden [[Supplementary Information|MBQC]] on states prepared by Server using her measurement device in the computation Stage. She then corrects her classical outcomes in Correction Stage. Classes of protocols under this category are:
*[[Measurement Only-Universal Blind Quantum Computation|'''Measurement Only UBQC''']]
*[[Measurement Only Verifiable Universal Blind Quantum Computation|'''Measurement Only VUBQC''']]

===Classical Online Communication-No Quantum Communication===
It involves a fully classical Client with no quantum power exchanging classical messages with the server throughout. This can be done using protocols for generating secret random qubits, under the functionality, Secret Random Qubit Generator (SQRG). One could append SQRG with UBQC to eliminate quantum communication. A verification protocol using SQRG is still an open question. Class of protocols for SQRG:
*[[Pseudo-Secret Random Qubit Generator|'''Pseudo-Secret Random Qubit Generator (PSRQG)''']].

===Classical Offline Communication-Quantum Offline Communication===
It involves a partially classical Client who can generate entanglement, use both classical and quantum communication with the Server during the preparation stage and output correction. There is no communication between the two parties during computation stage. Quantum Fully Homomorphic Encryption (QFHE) falls under this category, where Client hides her input states with the help of classical [[Supplementary Information#Homomorphic Encryption|'''Homomorphic Encryption''']]. In addition to this she also prepares some quantum gadgets (using [[Supplementary Information#entanglement|entanglement]]) which she sends with the encrypted state to Server, in the prepapration stage. Server uses the quantum gadgets for computation on the encrypted state. Such gadgets require steps which cannot be realized by classical HE scheme. Later Client decrypts/deciphers the outcome sent by Server to get the correct result, in the correction Stage. If the task performed by the Server can be verified by the Client, the protocol is called, Verifiable Quantum Fully Homomorphic Encryption (VQFHE). Classes of protocols under this category are:
*[[Prepare and Send Quantum Fully Homomorphic Encryption|'''Prepare and Send QFHE''']]
*[[Prepare and Send Verifiable Quantum Fully Homomorphic Encryption|'''Prepare and Send VQFHE''']]

===Classical Offline Communication-No Quantum Communication===
It involves a fully classical Client assign quantum computation to a Server on her classical input/output using only classical communication during the preparation stage and output correction. There is no communication between the two parties during computation stage. It uses only classical [[Supplementary Information#Homomorphic Encryption|Homomorphic Encryption]] and no quantum gadgets to realize a quantum function/computation. Quantum offline communication would be needed in case of quantum input/output. A verification scheme for such protocols is still an open question. Class of protocols under this category are:
*Quantum Capable Classical Fully Homomorphic Encryption [[Classical Fully Homomorphic Encryption for Quantum Circuits|'''(FHE) for Quantum Circuits''']]

'''Tags:''' [[Two Party Protocols|Two Party]], [[Universal Task|Universal Task]], [[Multiparty Delegated Quantum Computation|Multiparty Delegated Quantum Computation]], [[Quantum Enhanced Classical Delegated Computation|Quantum Enhanced Classical Delegated Computation]]

[[Category:Two Party Protocols]]