WO2019195989A1 - Preuve de plage de divulgation nulle de connaissance avec engagement réversible - Google Patents

Preuve de plage de divulgation nulle de connaissance avec engagement réversible Download PDF

Info

Publication number
WO2019195989A1
WO2019195989A1 PCT/CN2018/082406 CN2018082406W WO2019195989A1 WO 2019195989 A1 WO2019195989 A1 WO 2019195989A1 CN 2018082406 W CN2018082406 W CN 2018082406W WO 2019195989 A1 WO2019195989 A1 WO 2019195989A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
peer
encrypted
peer network
zkrp
Prior art date
Application number
PCT/CN2018/082406
Other languages
English (en)
Inventor
Teng WU
Meng Yang
Xinjian MA
Yuan YUE
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to CN201880091921.XA priority Critical patent/CN111919416B/zh
Priority to PCT/CN2018/082406 priority patent/WO2019195989A1/fr
Publication of WO2019195989A1 publication Critical patent/WO2019195989A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present disclosure relates generally to cryptographic recordation, and methods and systems for zero-knowledge range proof with reversible commitment.
  • Bitcoin is an example of a cryptocurrency and a payment system that allows peer-to-peer transactions to occur directly between users without relying on a central authority.
  • transactions are verified by peer network nodes of the payment system using various cryptographic techniques, and then recorded as plaintext in a public distributed ledger, such as a blockchain.
  • a public distributed ledger such as a blockchain.
  • the fact that all transactions are recorded in plaintext in the public ledger may be problematic for users that want to keep some details related to a transaction private.
  • a method of cryptocurrency transactions in a peer-to-peer network comprises: receiving, by a peer network node of the peer-to-peer network, cryptosystem parameter values for a zero knowledge range proof reversible commitment (ZKRPRC) algorithm; encrypting, by the peer network node, a transaction amount using the ZKRPRC algorithm in accordance with the selected cryptosystem parameter values to generate a reversible commitment and a ZKRP range proof; and sending, by the peer network node, a transaction from a first user to a second user via an unconfirmed transactions pool (UTP) of the peer-to-peer network, the transaction including the reversible commitment and the ZKRP range proof.
  • ZKRPRC zero knowledge range proof reversible commitment
  • a method of cryptocurrency transactions in a peer-to-peer network comprises: receiving, by a third party, a transaction from an sender of the transaction and an encrypted initial account balance from a recipient of the transaction, the transaction including an encrypted transaction amount and a reversible commitment and zero knowledge range (ZKRP) range proof; verifying, by the third party, that the encrypted transaction amount is within a specified range using the SKRP range proof, and based thereon; and adding, by the third party, the encrypted transaction amount to the encrypted initial account balance to obtain an encrypted resulting account balance, and recording the transaction along with the encrypted resulting account balance to a digitized public ledger.
  • ZKRP reversible commitment and zero knowledge range
  • FIG. 1 is a diagram of a public key infrastructure (PKI) payment system
  • FIG. 2 is a flowchart of an embodiment method for executing a transaction in a cryptographic recordation system
  • FIG. 3 is a flowchart of an embodiment method or executing a transaction in a cryptographic recordation comprising a peer-to-peer network;
  • FIG. 4 is a flowchart of an embodiment method for sending a transaction in a cryptographic recordation system comprising a peer-to-peer network;
  • FIG. 5 is a flowchart of an embodiment method for validating a transaction in a cryptographic recordation system comprising a peer-to-peer network;
  • FIG. 6 is a diagram of an embodiment processing system
  • FIG. 7 is a diagram of an embodiment transceiver.
  • ZKRP zero-knowledge range proof
  • a transaction amount is entered as an input of the ZKRP cryptographic algorithm, which outputs a non-reversible commitment and a ZKRP range proof.
  • the non-reversible commitment and a ZKRP range proof are then sent as contents of the transaction.
  • the non-reversible commitment is a ciphertext of the transaction amount, and is configured to be processed by a third party in accordance with the ZKRP range proof generated by the ZKRP algorithm to verify that the transaction amount is with a range corresponding to the ZKRP range proof.
  • the third party In verifying the transaction, the third party is able to confirm that the transaction amount is within a specified range based on the non-reversible commitment and the ZKRP range proof. However, the third party is not able to confirm the actual value of transaction amount.
  • One shortcoming of the ZKRP algorithm is that the ciphertext of the transaction amount cannot be decrypted in order to validate that the transaction amount is the correct value.
  • Paillier cryptosystem exhibits an additive homomorphic encryption (AHE) property such that the encrypted sum of two transaction values is equal to the crypto sum operation of the two encrypted values it should be appreciated that the “crypto sum operation” is different than arithmetic sum operation) .
  • AHE additive homomorphic encryption
  • the sum of the encrypted transaction amount and encrypted account balance i.e., sum [enc ($10) + enc ($100) ]
  • Paillier cryptosystem One drawback of a Paillier cryptosystem is that some of the cyclic group order information may be leaked to third parties, which allows the third parties to perform Paillier decryption. In the past, this has prevented ZKRP algorithm and Paillier cryptosystem from being used in conjunction with one another because the Paillier cryptosystem leaking of cyclic group order information violates a security assumption of the ZKRP algorithm.
  • Embodiments of this disclosure overcome this limitation by selecting Paillier cryptosystem parameter values in a manner that avoids leaking cyclic group order information to third party during Paillier decoding, while still allowing a third party peer network node that has the correct information to successfully validate the transaction.
  • FIG. 1 is a diagram of an example payment system 100 that uses a public key infrastructure (PKI) to verify transactions.
  • the payment system 100 comprises a peer-to-peer network that includes peer network nodes, entitled Alice 110, Bob 120, and Bank 130 in FIG. 1.
  • the Bank 130 is a third party that verifies transactions between Alice 110 and Bob 120.
  • Alice 110 may want to keep the transaction amount private such that only Bob is privy to the actual transaction amount.
  • the payment system 100 allows Alice 110 to send a transaction 112 to Bob 120.
  • the transaction 112 may be a digital check, a cryptocurrency transfer (e.g., a transfer of “X” Bitcoins) , or any other digital medium of exchange.
  • the bank 130 verifies that the amount in the transaction 112 does not exceed the daily withdraw limit of Alice 110, which is $1000.
  • Alice 110 may want the amount of the transaction (i.e., $10) to remain private so that nobody other than Bob 120 knows the amount transferred.
  • a standard way to achieve is this is to use a public key infrastructure (PKI) , in which a certificate authority (CA) 190 verifies the identity of Alice 110 and Bob 120 and issues digital certificates to both Alice 110 and Bob 120 to authenticate their public key. Thereafter, Alice 110 can send her public key (PubB) of Bob 120 to encrypt the amount in the transaction 112, and Bob 120 can use his corresponding private key (PriB) to decrypt the encrypted transaction to obtain the amount in the transaction 112.
  • PKI public key infrastructure
  • CA certificate authority
  • the transaction between Alice 110 and Bob 120 may be verified using a ZKRP algorithm to allow Alice 110 and Bob 120 to safely and privately transfer any amount as long as the amount is within the allowed range (no overflow) .
  • the encrypted value could be directly appended to the receiver’s other encrypted value without decryption with the application of AHE property, and the range of the encrypted value can be verified by one or more third parties without leaking information about the amount inside the transaction. This verification may be performed by a third party, such as the bank 130.
  • FIG. 2 is a flowchart of an embodiment method 200 for executing a transaction in a cryptographic recordation system in accordance with an embodiment of this disclosure.
  • the method 200 may be performed by a peer network nodes in the cryptographic recordation system implemented as a peer-to-peer network.
  • a system administrator selects Paillier system parameters generated by the cryptographic recordation system during the setup phase.
  • Alice joins the network and generates a public-private key pair.
  • Bob joins the network and generates a public-private key pair.
  • Alice decides to send money to Bob, and inputs an amount ($10) into the zero-knowledge range proof reversible commitment (ZKRPRC) algorithm of the present invention at step 250.
  • ZKRPRC zero-knowledge range proof reversible commitment
  • the ZKRPRC algorithm outputs a reversible commitment (e.g. a ciphertext of the transaction amount) and a ZKRP proof of the reversible commitment.
  • the reversible commitment may a ciphertext, which is an encrypted version of the plaintext of the transaction amount.
  • a third party verifies the transaction amount based on the reversible commitment and the ZKRP proof. It should be appreciated that, prior to step 270, the reversible commitment and the ZKRP proof may be included in a transaction message that is sent to a third party for purposes verification.
  • the third party computes a cryptographic sum of the reversible commitment and updates Bob’s encrypted initial balance, and then records the resulting amount as Bob’s encrypted resulting balance.
  • Bob decrypts the encrypted resulting balance to determine the amount of his resulting balance.
  • Embodiments may use ZKRPRC to preserve privacy in cryptographic recordation systems which are used for digital financial transactions.
  • the peer network nodes uses the ZKRPRC algorithm to encrypt the transaction amount (e.g. the amount to be transferred amount) , and generate a range proof for the encrypted transaction amount.
  • the peer network node can encrypt the exact transaction amount, can include the encrypted transaction amount (e.g. the ciphertext) in the transaction, and can retrieve the transaction amount in the transaction using a corresponding decryption algorithm.
  • the range proof validates the transaction amount included the transaction without decrypting the ciphertext (e.g. the encrypted transaction amount) and revealing the exact transaction amount to other peer network nodes. All other peer network nodes can verify the range proof without interacting with the peer network node that originated the transaction.
  • Embodiments of this disclosure may receive one or more of the following parameters generated by the cryptographic recordation system during step 210 by executing algorithm 1:
  • Publishing the ciphertext, proof, range and public key allows third parties to verify that the numerical plaintext corresponding to the ciphertext is actually within the published range.
  • Alice wants to send a $10 digital check to Bob.
  • the bank has to verify the amount on this check doesn’t exceed the daily withdraw limit of Alice, which is $1000.
  • Embodiments of this disclosure may require that p, q, p ⁇ and q ⁇ are all prime numbers, and that g 1 is the element with l-secret order.
  • g 1 ⁇ s order divides 2pqp ⁇ q ⁇ . If p ⁇ and q ⁇ are not prime numbers, g 1 ⁇ s order may have small factors, which will compromise the security of ZKRP.
  • n must divide g 1 ⁇ s order.
  • aspects may require g 1 ⁇ s order is in l-secret form.
  • Embodiments of this disclosure may require separating g 1 and g 2 to protect the random numbers used in encryption algorithm of the ZKRPRC algorithm. Embodiments of this disclosure may also require that ⁇ is hid by l and T. In this way, if ⁇ leaks information of the order of g 1 , but it is necessary to decrypt, we innovatively hide ⁇ in l and use T as an auxiliary variable to decrypt.
  • the peer network nodes of Alice and Bob generate their individual pair of public and private keys.
  • the key pair created by each peer network node includes the following two keys: h (the public key passed to all the peers to encrypt the transaction amount) and x (the private key that the peer network node must keep secret i and use to decrypt the reversible commitment encrypted by the public key) .
  • Algorithm 2 may be used by each peer network node to generate the individual public and private keys.
  • the encryption algorithm also creates range R and the range-proof proof which is used by peer network nodes of third parties to validate the range inside the ciphertext using, for example, Algorithm 3.
  • the encryption algorithm raises the transaction amount to the power of the generator. Usually, it is impossible to decrypt because this is a discrete logarithm hard problem. Since we carefully choose the system parameters (e.g. p, q, p ⁇ and q ⁇ ) , this power of generator becomes a Paillier ciphertext, which is decrypt-able.
  • the system parameter generation algorithm g 1 and g 2 are used instead g 1 only to protect the secrecy of the random numbers in the encryption algorithm. Without g 2 , a peer network node can decrypt the random number of the encryption and break the encryption (e.g. decrypt the cipertext without the private key) .
  • g 2 is some random power of g 1
  • a nature question is that knowing all the information, whether it is possible to get the random power.
  • both the random power and ⁇ are secure given all the system parameters and public keys.
  • the ciphertext created during encryption may gave one of four values: used for decryption; used for decryption; when decrypted, the message m is returned; and used to hide the order of g.
  • Algorithm 4 may be used for decryption.
  • FIG. 3 is a flowchart of an embodiment method 300 for executing a transaction in another cryptographic recordation system that includes a blockchain (e.g. a digitized, decentralized public ledger of cryptocurrency transactions in accordance with the present invention.
  • the method 300 may be performed by peer network nodes in a peer-to-peer network of the payment system.
  • a peer network node receives the Paillier system parameters generated by the cryptographic recordation system during the setup phase.
  • Alice joins the network and generates a public-private key pair.
  • Bob joins the network and generates a public-private key pair.
  • Alice decides to send money to Bob, and inputs an amount ($10) into the ZKRPRC algorithm at step 350.
  • the ZKRPRC algorithm outputs a reversible commitment and a ZKRP proof of the reversible commitment.
  • the reversible commitment is a ciphertext.
  • Alice generates a transaction that includes the reversible commitment and ZKRP, and sends the transaction 370 to an unconfirmed transaction pool (UTP) .
  • UTP unconfirmed transaction pool
  • a miner peer network node retrieves the transaction from the unfirmed pool, and begins the mining steps.
  • the miner peer network node verifies the transaction based on the reversible commitment and the ZKRP, and determines whether the verification of the transaction was successful at step 384.
  • the peer network node removes the transaction from the local unconfirmed pool at step 388, and the method 300 reverts back to step 382. If the verification of the transaction was successful, then the miner peer network node mines the blockchain at step 390 to record the transaction, and updates Bob’s encrypted balance using the reversible commitment (e.g. the ciphertext of the transaction amount) and crypto operation since the encrypted balance and reversible commitment both include AHE property. At step 394, Bob decrypts his balance using his private key.
  • the reversible commitment e.g. the ciphertext of the transaction amount
  • the cryptographic recordation system may first initialize system parameters using mathematical formulas. These system parameters are used for encryption, for decryption, for generation of range proof, and for validating range proofs.
  • Network may be a group of connected computers, which we call peers, that know the existence each other and see all the communications and all Blockchain contents. Parameters for the network may be shared values between the peers that are used by the peers to do encryption, decryption, range proof generation and verification.
  • Alice and Bob are two peers that are used as example. Alice has her own public-private key pairs, that allows anyone to encrypt a message to her, but only she has the key to decrypt the ciphertext.
  • Transaction amount is the money transferred from one peer to another.
  • Embodiment ZKRPRC algorithm takes the amount, and it outputs a ciphertext and a zero-knowledge range proof.
  • the ciphertext can only be decrypted by Bob, and the ZKRP can be used by any peer on the network to validate the amount inside the transaction ciphertext is within a specified range.
  • a transaction may contain the ciphertext and the ZKRP, as well as the sender and receiver address and the sender signature on the transaction to protect the transaction’s integrity.
  • the network unconfirmed transactions pool, UTP keeps all the transaction that may be mined by peers.
  • the peer may verify that the transaction’s amount is valid using the ZKRP inside the transaction.
  • the peer may compute hashes as the mining method.
  • the first peer that computes the correct hash receives currency of the block chain.
  • AHE property the peer can add the valid encrypted transaction to Bob’s balance. When Bob wants to retrieve his balance, he can decrypt using his private key.
  • FIG. 4 is a flowchart of an embodiment method 400 for sending a ZKRPRC transaction, as may be performed by a peer network node in a cryptographic recordation system for digital financial transactions.
  • the user receives cryptosystem parameter values for a zero knowledge range proof reversible commitment (ZKRPRC) algorithm.
  • ZKRPRC zero knowledge range proof reversible commitment
  • the cryptosystem parameter values may be generated during step 410 according to algorithm 1 (provided above) .
  • the user encrypts a transaction amount using the ZKRPRC algorithm in accordance with the received cryptosystem parameter values to generate a reversible commitment and a ZKRP range proof.
  • a peer network node associated with a user sends a transaction including the reversible commitment and the ZKRP range proof to another a peer network node associated with another use via an unconfirmed transactions pool (UTP) of the cryptosystem system.
  • UTP unconfirmed transactions pool
  • FIG. 5 is a flowchart of an embodiment method 500 for validating a ZKRPRC transaction, as may be performed by a third party network node of a peer-to-peer network of a cryptosystem system for digital financial transactions.
  • the third party network node receives an encrypted initial account balance from a digitized, decentralized public ledger, such as blockchain, and a transaction that includes a reversible commitment and ZKRP range proof from a sender peer network node.
  • the third party network node verifies that the encrypted transaction amount inside the transaction is within a specified range using the ZKRP range proof.
  • the third party network node performs a crypto operation to add the encrypted transaction amount to the encrypted initial account balance to obtain an encrypted resulting account balance.
  • the third party network node records the transaction along with the encrypted resulting account balance to the digitized, decentralized public ledger.
  • FIG. 6 is a block diagram of an embodiment processing system 600 for performing methods described herein, which may be installed in a peer node, such as a peer node corresponding to Alice 110, Bob 120, or a third party as depicted in FIG. 1.
  • the processing system 600 includes a processor 604, a memory 606, and interfaces 610-614, which may (or may not) be arranged as shown in FIG. 6.
  • the processor 604 may be any component or collection of components adapted to perform computations and/or other processing related tasks
  • the memory 606 may be any component or collection of components adapted to store programming and/or instructions for execution by the processor 604.
  • the memory 606 includes a non-transitory computer readable medium.
  • the interfaces 610, 612, 614 may be any component or collection of components that allow the processing system 600 to communicate with other devices/components and/or a user.
  • one or more of the interfaces 610, 612, 614 may be adapted to communicate data, control, or management messages from the processor 604 to applications installed on the host device and/or a remote device.
  • one or more of the interfaces 610, 612, 614 may be adapted to allow a user or user device (e.g., personal computer (PC) , etc. ) to interact/communicate with the processing system 600.
  • the processing system 600 may include additional components not depicted in FIG. 6, such as long term storage (e.g., non-volatile memory, etc. ) .
  • the processing system 600 is in a user-side device accessing a wireless or wireline telecommunications network, such as a mobile station, a user equipment (UE) , a personal computer (PC) , a tablet, a wearable communications device (e.g., a smartwatch, etc. ) , or any other device adapted to access a telecommunications network.
  • a wireless or wireline telecommunications network such as a mobile station, a user equipment (UE) , a personal computer (PC) , a tablet, a wearable communications device (e.g., a smartwatch, etc. ) , or any other device adapted to access a telecommunications network.
  • FIG. 7 is a block diagram of a transceiver 700 adapted to transmit and receive signaling over a telecommunications network.
  • the transceiver 700 may be installed in a peer node, such as peer node corresponding to Alice 110, Bob 120, or a third party as depicted in FIG. 1.
  • the transceiver 700 comprises a network-side interface 702, a coupler 704, a transmitter 706, a receiver 708, a signal processor 710, and a device-side interface 712.
  • the network-side interface 702 may include any component or collection of components adapted to transmit or receive signaling over a wireless or wireline telecommunications network.
  • the coupler 704 may include any component or collection of components adapted to facilitate bi-directional communication over the network-side interface 702.
  • the transmitter 706 may include any component or collection of components (e.g., up-converter, power amplifier, etc. ) adapted to convert a baseband signal into a modulated carrier signal suitable for transmission over the network-side interface 702.
  • the receiver 708 may include any component or collection of components (e.g., down-converter, low noise amplifier, etc. ) adapted to convert a carrier signal received over the network-side interface 702 into a baseband signal.
  • the signal processor 710 may include any component or collection of components adapted to convert a baseband signal into a data signal suitable for communication over the device-side interface (s) 712, or vice-versa.
  • the device-side interface (s) 712 may include any component or collection of components adapted to communicate data-signals between the signal processor 710 and components within the host device (e.g., the processing system 600, local area network (LAN) ports, etc. ) .
  • the transceiver 700 may transmit and receive signaling over any type of communications medium.
  • the transceiver 700 transmits and receives signaling over a wireless medium.
  • the transceiver 700 may be a wireless transceiver adapted to communicate in accordance with a wireless telecommunications protocol, such as a cellular protocol (e.g., long-term evolution (LTE) , etc. ) , a wireless local area network (WLAN) protocol (e.g., Wi-Fi, etc. ) , or any other type of wireless protocol (e.g., Bluetooth, near field communication (NFC) , etc. ) .
  • the network-side interface 702 comprises one or more antenna/radiating elements.
  • the network-side interface 702 may include a single antenna, multiple separate antennas, or a multi-antenna array configured for multi-layer communication, e.g., single input multiple output (SIMO) , multiple input single output (MISO) , multiple input multiple output (MIMO) , etc.
  • the transceiver 700 transmits and receives signaling over a wireline medium, e.g., twisted-pair cable, coaxial cable, optical fiber, etc.
  • Specific processing systems and/or transceivers may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device.
  • a signal may be transmitted by a transmitting unit or a transmitting module.
  • a signal may be received by a receiving unit or a receiving module.
  • a signal may be processed by a processing unit or a processing module.
  • Other steps may be performed by an identifying unit/module and/or a determining unit/module.
  • the respective units/modules may be hardware, software, or a combination thereof.
  • one or more of the units/modules may be an integrated circuit, such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs) .
  • FPGAs field programmable gate arrays
  • ASICs application-specific integrated circuits

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de transactions de cryptomonnaie dans un réseau poste à poste. Le procédé comprend les étapes consistant à : recevoir des valeurs de paramètre de système cryptographique pour un algorithme d'engagement réversible à preuve de plage de divulgation nulle de connaissance (ZKRPRC) ; chiffrer une quantité de transaction à l'aide de l'algorithme ZKRPRC conformément aux valeurs de paramètre de système cryptographique sélectionnées pour générer un engagement réversible et une preuve de plage de ZKRP ; et envoyer une transaction d'un premier utilisateur à un second utilisateur par l'intermédiaire d'un groupe de transactions non confirmé (UTP) du réseau poste à poste, la transaction comprenant l'engagement réversible et la preuve de plage de ZKRP.
PCT/CN2018/082406 2018-04-09 2018-04-09 Preuve de plage de divulgation nulle de connaissance avec engagement réversible WO2019195989A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201880091921.XA CN111919416B (zh) 2018-04-09 2018-04-09 用于具有可逆承诺的零知识范围证明的方法和系统
PCT/CN2018/082406 WO2019195989A1 (fr) 2018-04-09 2018-04-09 Preuve de plage de divulgation nulle de connaissance avec engagement réversible

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/082406 WO2019195989A1 (fr) 2018-04-09 2018-04-09 Preuve de plage de divulgation nulle de connaissance avec engagement réversible

Publications (1)

Publication Number Publication Date
WO2019195989A1 true WO2019195989A1 (fr) 2019-10-17

Family

ID=68162744

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/082406 WO2019195989A1 (fr) 2018-04-09 2018-04-09 Preuve de plage de divulgation nulle de connaissance avec engagement réversible

Country Status (2)

Country Link
CN (1) CN111919416B (fr)
WO (1) WO2019195989A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110766400A (zh) * 2019-10-22 2020-02-07 全链通有限公司 基于区块链的交易记录处理方法、记账节点及介质
CN112367174A (zh) * 2020-11-06 2021-02-12 深圳前海微众银行股份有限公司 一种基于属性值的区块链共识方法及装置
CN112785306A (zh) * 2021-01-28 2021-05-11 武汉天喻聚联科技有限公司 基于Paillier的同态加密方法及应用系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103997407A (zh) * 2013-02-15 2014-08-20 汤姆逊许可公司 用于生成和验证线性同态签名中的承诺的加密设备和方法
CN105024823A (zh) * 2015-07-27 2015-11-04 中国船舶重工集团公司第七0九研究所 基于零知识证明的用户身份隐私保护方法及系统
CN106911470A (zh) * 2017-01-23 2017-06-30 北京航空航天大学 一种比特币交易隐私增强方法
CN106991148A (zh) * 2017-03-27 2017-07-28 西安电子科技大学 一种支持全更新操作的数据库验证系统及方法
US20170366349A1 (en) * 2016-06-16 2017-12-21 International Business Machines Corporation Proofs of Plaintext Knowledge and Group Signatures Incorporating Same

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10440046B2 (en) * 2015-09-25 2019-10-08 Intel Corporation Technologies for anonymous context attestation and threat analytics
PL3073670T4 (pl) * 2015-03-27 2021-08-23 Black Gold Coin, Inc. System i sposób osobistej identyfikacji i weryfikacji
CN107666388B (zh) * 2016-07-28 2019-11-01 郑珂威 基于完全同态加密方法的区块链信息加密方法
CN106549749B (zh) * 2016-12-06 2019-12-24 杭州趣链科技有限公司 一种基于加法同态加密的区块链隐私保护方法
CN106982205B (zh) * 2017-03-01 2020-05-19 中钞信用卡产业发展有限公司杭州区块链技术研究院 基于区块链的数字资产处理方法和装置
CN107169764A (zh) * 2017-05-10 2017-09-15 山东大学 基于区块链的公平数据交易方法
CN107369010A (zh) * 2017-07-25 2017-11-21 光载无限（北京）科技有限公司 一种基于区块链的电子钱包的创建方法
CN107862216B (zh) * 2017-10-13 2021-04-06 布比（北京）网络技术有限公司 用于匿名跨链交易的隐私保护方法、装置和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103997407A (zh) * 2013-02-15 2014-08-20 汤姆逊许可公司 用于生成和验证线性同态签名中的承诺的加密设备和方法
CN105024823A (zh) * 2015-07-27 2015-11-04 中国船舶重工集团公司第七0九研究所 基于零知识证明的用户身份隐私保护方法及系统
US20170366349A1 (en) * 2016-06-16 2017-12-21 International Business Machines Corporation Proofs of Plaintext Knowledge and Group Signatures Incorporating Same
CN106911470A (zh) * 2017-01-23 2017-06-30 北京航空航天大学 一种比特币交易隐私增强方法
CN106991148A (zh) * 2017-03-27 2017-07-28 西安电子科技大学 一种支持全更新操作的数据库验证系统及方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110766400A (zh) * 2019-10-22 2020-02-07 全链通有限公司 基于区块链的交易记录处理方法、记账节点及介质
CN112367174A (zh) * 2020-11-06 2021-02-12 深圳前海微众银行股份有限公司 一种基于属性值的区块链共识方法及装置
CN112785306A (zh) * 2021-01-28 2021-05-11 武汉天喻聚联科技有限公司 基于Paillier的同态加密方法及应用系统
CN112785306B (zh) * 2021-01-28 2023-08-15 武汉天喻聚联科技有限公司 基于Paillier的同态加密方法及应用系统

Also Published As

Publication number Publication date
CN111919416A (zh) 2020-11-10
CN111919416B (zh) 2021-11-19

Similar Documents

Publication Publication Date Title
US11743049B2 (en) Streaming authentication and multi-level security for communications networks using quantum cryptography
US10567165B2 (en) Secure key transmission protocol without certificates or pre-shared symmetrical keys
US10985910B2 (en) Method for exchanging keys authenticated by blockchain
US20170244687A1 (en) Techniques for confidential delivery of random data over a network
EP2073430B1 (fr) Procédés et systèmes pour sécurité de transaction d'initialisation de canal sécurisé basée sur un secret partagé à faible entropie
CN111448779A (zh) 用于混合秘密共享的系统、设备和方法
CN111371790B (zh) 基于联盟链的数据加密发送方法、相关方法、装置和系统
EP4026273A1 (fr) Systèmes et procédés permettant de signer un message
US20180115535A1 (en) Blind En/decryption for Multiple Clients Using a Single Key Pair
EP3570487B1 (fr) Procédé, dispositif et système de génération de clé privée
US20220069995A1 (en) System and method for securing data
CN105812349A (zh) 一种基于身份信息的非对称密钥分发及消息加密方法
WO2019195989A1 (fr) Preuve de plage de divulgation nulle de connaissance avec engagement réversible
KR101765207B1 (ko) 교통 신호 보안 시스템 및 방법
EP1079565A2 (fr) Procédé d'établissement sécurisé d'une liaison sécurisée par l'intermédiaire d'un réseau de communication non sécurisé
CN111433800B (zh) 交易处理方法及相关设备
US10699021B2 (en) Method and a device for secure storage of at least one element of digital information, and system comprising such device
CN111555880A (zh) 数据碰撞方法、装置、存储介质及电子设备
CN116743358A (zh) 一种可否认的多接收者认证方法及系统
KR101793528B1 (ko) 무인증서 공개키 암호 시스템
EP3883178A1 (fr) Système et procédé de chiffrement utilisant une technologie de chiffrement basée sur un groupe de permutation
WO2008004174A2 (fr) Procédé d'établissement d'une voie sécurisée authentifiée
US20190379645A1 (en) System for secure arbitrary data transport
Allam Improving secret key generation for wireless communications in FDD mode
Wicik et al. Cryptographic protection of classified information in military radio communication faced with threats from quantum computers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18914507

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18914507

Country of ref document: EP

Kind code of ref document: A1