Verifiable Revelation of Shared Secrets Using Schnorr Protocol
Last updated
Was this helpful?
Last updated
Was this helpful?
Ty Everett (ty@projectbabbage.com)
This BRC presents a solution to the limitations identified in concerning Method 1 of key linkage revelation. The proposed method utilizes a Schnorr-based zero-knowledge proof (ZKP) scheme to enable provers to reveal a shared secret between their identity key and a counterparty's key while allowing verifiers to independently confirm its validity without accessing private keys. This approach ensures trustless verification of shared secrets, enhancing the security and practical utility of key linkage revelations in privacy-preserving systems.
aims to provide methods for revealing key associations under the key derivation scheme. However, as highlighted in , Method 1 suffers from a critical limitation: verifiers cannot confirm the authenticity of the revealed shared secret without knowing the private keys of the prover or counterparty. This dependency undermines the trustless nature of the system and limits its applicability in scenarios requiring independent verification.
To address this issue, we propose leveraging a Schnorr-based zero-knowledge proof scheme. Schnorr protocols are well-known for allowing one party to prove knowledge of a secret (e.g., a private key) without revealing it, and they can be adapted to prove the correctness of a shared secret computation. By employing this cryptographic technique, we can enable verifiers to confirm that the prover knows the private key corresponding to their public key and has correctly computed the shared secret with the counterparty's public key, all without revealing any private keys.
This solution restores the trustless verification capability of Method 1, enhancing the overall security and practicality of key linkage revelations in the BSV ecosystem.
The proposed method allows a prover to generate a zero-knowledge proof demonstrating that:
They possess the private key corresponding to their public key A.
They have correctly computed the shared secret S with the counterparty's public key B.
The verifier can then use this proof to confirm the validity of the shared secret S without access to any private keys.
Prover: The entity revealing the shared secret and proving its correctness.
Verifier: The entity verifying the authenticity of the shared secret.
Counterparty: The other party involved in the shared secret computation.
Let a be the prover's private key.
Let A = a * G be the prover's public key.
Let B be the counterparty's public key.
Let S = a * B be the shared secret computed by the prover.
Let n be the order of the elliptic curve group.
Let G be the generator point of the elliptic curve.
Let r be a random nonce chosen by the prover.
Let R = r * G be the prover's nonce public key.
Let S' = r * B be the nonce shared secret.
Let e be the challenge scalar computed via a hash function.
Let z be the prover's response scalar.
Compute the Shared Secret:
Compute S = a * B.
Choose a Random Nonce:
Select a random nonce r from [1, n-1].
Compute Nonce Public Key and Nonce Shared Secret:
Compute R = r * G.
Compute S' = r * B.
Compute the Challenge:
Compute e = H(A || B || S || S' || R) mod n, where H is a cryptographic hash function (e.g., SHA-256), and || denotes concatenation.
Compute the Response Scalar:
Compute z = (r + e * a) mod n.
Provide the Proof:
Send the proof consisting of (R, S', z) to the verifier.
Compute the Challenge:
Compute e = H(A || B || S || S' || R) mod n.
Verify the Proof:
Verify that z * G = R + e * A.
Verify that z * B = S' + e * S.
Both equations must hold true for the proof to be valid.
Zero-Knowledge Property: The proof does not reveal the prover's private key a or the random nonce r, preserving the confidentiality of sensitive information.
Unforgeability: Without knowing the prover's private key, it is computationally infeasible for an attacker to produce a valid proof.
Trustless Verification: Verifiers can independently confirm the correctness of the shared secret S without accessing any private keys.
The prover demonstrates knowledge of a and the correct computation of S without revealing a.
The verifier uses only public information and the proof to validate the shared secret.
The use of cryptographic hash functions ensures that e is unpredictable and unique for each proof, preventing replay attacks.
Revelation Payload: The prover includes the shared secret S and the proof (R, S', z) in the payload sent to the verifier.
Verification: The verifier uses the prover's public key A, the counterparty's public key B, the shared secret S, and the proof to verify the authenticity of the shared secret without requiring any private keys.
Random Nonce Security: The nonce r must be securely generated using a cryptographically secure random number generator to prevent nonce reuse attacks.
Hash Function Collision Resistance: The hash function H used in computing the challenge e should be collision-resistant (e.g., SHA-256).
No Private Key Exposure: At no point are private keys a or r exposed to the verifier or any third party.
See .
Encryption: As per , the payload can be encrypted using to ensure confidentiality during transit.
By incorporating a Schnorr-based zero-knowledge proof protocol, we provide a solution to the limitations identified in for Method 1 of . This method allows provers to reveal shared secrets while enabling verifiers to independently confirm their validity without accessing private keys. This enhancement restores trustless verification capabilities, strengthening the security and practicality of key linkage revelations in privacy-preserving applications within the BSV blockchain ecosystem.