Editing
Gottesman and Chuang Quantum Digital Signature
(section)
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!
==Outline== The signature scheme proposed by Gottesman and Chuang is based on [[Glossary#Quantum One Way Function|quantum one way functions]], which takes classical bit string as input and outputs quantum states. Quantum Digital Signature (QDS) protocols can be divided into two phases: the distribution phase, where quantum signals (public keys) are sent to all recipients, and the messaging phase, where classical messages are signed, sent and verified. Here, we take the case of three parties, one sender (referred to as seller) and two receivers (buyer and verifier) sharing a one bit message. Distribution phase can be divided into the following two steps: *'''Key Generation:''' For each message bit (say 0 and 1), seller selects some (say M) classical bit strings randomly. These are chosen to be her private keys for that message bit. Using this private key as input, seller generates output of the quantum one-way function/map, which she calls her public key and as assumed above, distributes them to each recipient, for each message bit. In the end of this step, each recipient has 2M public keys, M for message bit 0 and M for message bit 1. Following are a few suggestions for the quantum one way functions, by the authors. '''Quantum One Way Functions:''' The author suggests [[Gottesman and Chuang Quantum Digital Signature#References|quantum fingerprint states (1)]], [[Gottesman and Chuang Quantum Digital Signature#References|stabilizer states (2)]] to represent classical strings in terms of quantum states. The number of qubits for the quantum state used, to represent each bit in the classical string, depends on which of the above methods is used. Another method where each classical bit is represented by one quantum bit, is also suggested. * '''Key Distribution:''' The authors suggest a few methods for key distribution. One of them is the assumption of a trusted third party who receives public keys from seller, checks all the keys using [[Quantum SWAP Test]] and then if test is passed by each key sent, the trusted party distributes it to the recipients. A second method eliminates the requirement of a trusted third party and instead requires Sender to send two copies of each public key to each recipient, such that, in the end each recipient has 4M keys (2M public keys for each message bit). Both buyer and verifier perform quantum swap test on their supposedly identical copies of public keys. Then, if passed, Buyer sends one copy of his public key to the verifier, who then performs the SWAP test between the received copy and his copy of public key. Similarly, messaging stage can be described as follows: *'''Messaging:''' Seller sends her message bit with the associated private keys to the buyer. Buyer performs the map on the private key (quantum one way function takes the sent private key as input) and then compares the output thus generated with the public key received in the distribution stage. If the number of unmatched bits are below rejection threshold, the message is declared valid, else invalid. If the number of unmatched bits is below acceptance threshold, it is declared transferable, else not transferable. A generalized scheme for more than three parties is given in the article. Also, for multi-bit messages, a scheme using error correcting codes has been suggested in brief.
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