Editing
Quantum Conference Key Agreement
Jump to navigation
Jump to search
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
<!-- This is a comment. You can erase them or write below --> <!-- Functionality page describes a general task which can be realised in a quantum network --> <!-- Description: A lucid definition of functionality in discussion.--> ==Functionality== Conference key agreement (CKA), or multipartite key distribution is a cryptographic task where more than two parties wish to establish a common secret key. It is possible to compose bipartite QKD protocols to accomplish this task. However, protocols based on multipartite quantum correlations may be more efficient and practical in future large scale quantum networks. <!-- Tags Any related page or list of protocols is connected by this section--> '''Tags:''' [[:Category: Multi Party Protocols|Multi Party Protocols]], [[:Category: Quantum Enhanced Classical Functionality|Quantum Enhanced Classical Functionality]], [[:Category: Specific Task|Specific Task]] <!-- Use Case (if available) analyses how practical the protocol is--> ==Properties== <!-- All properties that should be satisfied by any protocol achieving the concerned functionality and other common terminologies used in all the protocols.--> An ideal CKA protocol, with <math>N</math> users, Alice, Bob<math>_1</math>, Bob<math>_2</math>, ..., Bob<math>_{N-1}</math> should have the following properties: * '''Correctness:''' A CKA protocol is said to be ''correct'' if all parties receive the same key at the end of the protocol with high probability. : Formally, a CKA protocol is <math>\epsilon_{corr}</math>-correct if: :: <math>p(K_A = K_{B_1} = ... = K_{B_{N-1}}) \geq 1 - \epsilon_{corr}</math> : where <math>K_A, K_{B_i}</math> are the final keys held by Alice and Bob<math>_i</math>, and <math>p(K_A = K_{B_1} = ... = K_{B_{N-1}})</math> is the probability that all final keys are identical. * '''Secrecy:''' A CKA protocol is said to be ''secret'' if an eavesdropper Eve cannot differentiate between the key established and a random bitstring. : Formally, a CKA protocol is <math>\epsilon_{sec}</math>-secret if, for <math>\Omega</math> being the event that the protocol does not abort, :: <math>p(\Omega)\frac{1}{2}||\rho_{K_AE|\Omega} - \tau_{K_A}\otimes\rho_{E|\Omega}|| \leq \epsilon_{sec}</math>, : where <math>p(\Omega)</math> is the probability of the event <math>\Omega</math>, <math>\rho_{K_AE|\Omega}</math> is the state shared by Alice and Eve at the end of the protocol given the event <math>\Omega</math>, <math>\tau_{K_A} = \frac{1}{|S|}\sum_{s_i \in S} |s_i\rangle \langle s_i|</math> is the maximally mixed state over all possible values that the key <math>K_A</math> can assume, and <math>S = \{0,1\}^{\times l}</math> where <math>l</math> is the length of the key <math>K_A</math>. * '''Completeness:''' A quantum CKA protocol is <math>\epsilon_c</math>-complete if there exists an honest implementation of the protocols, such that the probability of not aborting is greater than <math>1-\epsilon_c</math>. ==Generic Protocol Structure== * '''Preparation and distribution:''' A source distributes a multipartite entangled state to the <math>N</math> parties. This step is repeated <math>n</math> * '''Measurements:''' Upon receiving the systems, the parties perform local measurements and record the classical outcome. The measurements are randomly chosen according to the specifications of the protocol. One of the possible measurement settings is used with higher probability and is called the <u>key generation</u> measurements. The other measurements are used for <u>test rounds</u>, which only occasionally occur. * '''Parameter estimation:''' The parties announce the inputs and outputs of their test rounds and of some randomly chosen key generation rounds which are used to estimate their correlation and the potential influence of an eavesdropper. At the end of this step, each party is left with a string of <math>n_{raw} < n</math> bits, which constitute their <u>raw key</u>. * '''Information reconciliation (error correction):''' The parties publicly exchange classical information in order for the Bobs to correct their raw keys to match Alice's string. In the multipartite case, the information reconciliation protocol needs to account for the correction of the strings of all the Bobs. * '''Privacy amplification:''' Alice randomly picks a hash function, chosen among a two-universal family of hash functions, and communicates it to the Bobs. Every party applies the hash function to turn her/his partially secure string of <math>n_{raw}</math> bits into a secure key of <math> l < n_{raw}</math> bits. ==Protocols== * [[Prepare-and-measure Conference Key Agreement]] * [[Anonymous Conference Key Agreement using GHZ states]] * [[W-State based Conference Key Agreement]] * [[Continuous Variable Conference Key Agreement]] * [[Device Independent Conference Key Agreement]] <!--==Further Information== --> <!-- Any issue that could not be addressed or find a place in the above sections or any review paper discussing a feature of various types of protocols related to the functionality. --> ==References== * [https://arxiv.org/abs/2003.10186 Murta et al.(2020)] discusses the properties of the functionality and provides various example protocols <div style='text-align: right;'>''*contributed by Chirag Wadhwa''</div>
Summary:
Please note that all contributions to Quantum Protocol Zoo may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Quantum Protocol Zoo:Copyrights
for details).
Do not submit copyrighted work without permission!
To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:
Cancel
Editing help
(opens in new window)
Navigation menu
Personal tools
Not logged in
Talk
Contributions
Log in
Namespaces
Page
Discussion
English
Views
Read
Edit
View history
More
Search
Navigation
Main page
News
Protocol Library
Certification Library
Nodal Subroutines
Codes Repository
Knowledge Graphs
Submissions
Categories
Supplementary Information
Recent Changes
Contact us
Help
Tools
What links here
Related changes
Special pages
Page information