Quantum Protocol Zoo

Welcome to QuPedia- Explore, Learn and Impelement Quantum Porotcols

With the advent of vast number of protocols in the reign of Quantum Information era, we are in urgent need of a standardization process. A process which would account for the way a protocol is presented in a compressed form to communicate with the computer scientists, engineers and physicists at one time. We propose to create QuPedia, a Quantum Protocol Wikipedia, a zoo of quantum protocols linked to each other depending on the functionalities they achieve and the implementation they follow. QuPedia curators takes you on a ride to the world of quantum protocols unveiling the mysterious functionalities and implementations achieved by quantum cryptographers over the century. We present to you the QuPedia Team.

THE ZOO CURATORS

This list of people have built up QuPedia with a minimum contribution of more than ten class of quantum protocols.

Elham Kashefi
Shraddha Singh

CONTRIBUTORS

This list of people have helped the construction of QuPedia by contributing a class of quantum protcols in the best of their knowledge with no less effort.

Getting started

QuPedia directs you to a set of General Description of different quantum and classical functionalities achieved by various by quantum protocols. Is elicits the definition, properties and use cases of a given functionality. Further, it directs you to various different protocols used to achieve the functionality presenting a formal description for each. Every such formal description groups all quantum protocols/articles based on the method described, in the reference section. It also directs one to any related protocol or functionality in the "Tags/See Also" section. We also illustrate use cases for different protocols to bridge the gap between users and protocol designers. Finally, some esoteric concepts used by these quantum protocols are explained via links that would direct you to a wiki page called "Supplementary Information".

Categorisation

We also provide you with different lists of categories used for tags. These tags help one explore QuPedia better.

General Description

Functionalities listed in categories above direct you to a general description where you find the definition, properties, use cases of the functionality. It further segregates protocols covering the functionality based on several different aspects like implementation used by quantum protocols to achieve the concerned functionality. Each section opens up a formal description for a particular implementation. Any protocol linked to a given formal description would be listed in its reference section as illustrated before.

Guidelines

A guideline explaining the structure of these formal descriptions is given below.

Functionality Description

This paragraph gives objective of the protocol in brief. We try to make it as general and complete as possible in order to cover a wide range of protocols under the same functionality and similar methods used. It should be able to give a clear idea about the task to be achieved and roles of the parties involved. No arbitrary names should be given to the parties. This would help avoid any confusion and also, make the functionality (roles) of the parties obvious. Eg. Blind Quantum Computing protocols should be written as Client-Server participating in the protocol, not Alice-Bob. We escape the use of fictional names unless needed, for e.g.- Key Distribution.

Tags: This block should include all different classes of categorization that this protocol belongs to, in the quantum library. Example- Two party crypto/ client-server/multi party(three or more), quantum enhanced classical/fully quantum functionality, specific/ universal task. It would also include the stage of the protocol.

Outline

This section is a simple wordy outline of the protocol. It should tell you what the protocol is, but not the minute details of the protocol. As far as possible, one must refrain from using mathematical notations or variables. It should be kept as a general outline of the Procedure. It should not contain any new terminology that has not been explained before or here itself. If one does, it should be linked to a Wikipedia page or a supplementary draft, whichever preferred. This part should be self-consistent, precise but self-explanatory. If we use bullet points and give steps/levels some name, one should aim at describing the target of the step in the first line and then proceed with the ’what’ and ’how’ of the step. A key point to be noted, we do not aim at answering the ’why’ for different steps nor do we provide with the security proof. That would just make the description as long as the paper. It is redundant and not the aim of this formal description. The reader may refer to the specific paper in order to understand any such detail.

Figure

This section shall be replaced with a picture made using cryptocode package which gives a diagrammatic representation of the protocol. For the time being, one can add pictures of hand-drawn figures. No need to explicitly draw on tikz and waste your time unnecessarily.

Notations

Any mathematical notations or variables used in the Pseudo code can be listed here in order to make the picture clear. It serves the purpose of connecting the wordy outline and the mathematical pseudo code.

Properties

The structure of this section is not specific and would be protocol based. It should highlight any point, parameter, security claim, assumption or clearly anything in the paper that one finds important to emphasize. Contents are preferred to be pointwise to make it limpid.
This section would elicit all the important elements required for the above discussion but not needed to understand the protocol. For example, definitions of any new parameter or threshold used by the parties or agreed universally by everyone for security, assumptions used and the security claims of the protocol. It should be to the point and clear(one line description preferred). Below is a format one could use (you can create your own subsections depending on the protocol).

Parameters
lists all the parameters with the notations used in one line
Adversarial Assumption
States all the assumptions on the adversary. This point is important for most of the protocols.
Setup Assumptions
lists all the assumptions in bullet points.
Security Claim
gives all the security definitions. Any specific property particular to the concerned protocol should be already defined in the functionality description. E.g. in case of Blind Quantum Computation, blindness is claimed. This property should be already mentioned in a well-defined manner in the functionality description.

One could also include definitions like soundness, verifiability and correctness, etc.. if the protocol mentions it. As mentioned earlier the structure is flexible for this section

Pseudo Code

This section contains an algorithm/ pseudo code of the protocol. It would be stepwise description of the protocol with mathematical notations. We try to avoid words as much as possible.

Resources

Yet to be discussed

References

This section mentions all the different protocols under the same functionality description with similar method. With each reference, a one line description of how it is different from the given (discussed) protocol (resources used, type of measurement or storage etc..) is necessary. This list should cover all the papers that one finds easy to understand after reading this formal description.

Use Case

It illustrates all the possible use cases implied by the concerned protocol.

Main Page

Contents