Verifiable Revelation of Shared Secrets Using Schnorr Protocol

Ty Everett (ty@projectbabbage.com)

Abstract

This BRC presents a solution to the limitations identified in BRC-93 concerning Method 1 of BRC-69 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.

Motivation

BRC-69 aims to provide methods for revealing key associations under the BRC-42 key derivation scheme. However, as highlighted in BRC-93, 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.

Specification

Overview

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.

Entities

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.

Notation

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.

Protocol Steps

Prover Side

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.

Verifier Side

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.

Security Analysis

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.

Key Points

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.

Implementation

See Schnorr.ts.

Integration with BRC-69 and BRC-72

Revelation Payload: The prover includes the shared secret S and the proof (R, S', z) in the payload sent to the verifier.
Encryption: As per BRC-72, the payload can be encrypted using BRC-2 to ensure confidentiality during transit.
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.

Security Considerations

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.

Conclusion

By incorporating a Schnorr-based zero-knowledge proof protocol, we provide a solution to the limitations identified in BRC-93 for Method 1 of BRC-69. 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.

References

PreviousLimitations of BRC-69 Key Linkage Revelation NextFormat for Bitcoin Outpoints

Last updated 8 hours ago