Skip to content

Instantly share code, notes, and snippets.

Last active June 15, 2023 05:58
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save RobinLinus/2e525efd0adeb84cb3695ae56d82282f to your computer and use it in GitHub Desktop.
Mapping a Secret Scalar Value between Elliptic Curve Groups

Mapping a Secret Scalar Value between Elliptic Curve Groups [broken]

This document outlines a method to map a secret scalar value x from one elliptic curve group (secp256k1) to another elliptic curve group (a pairing-friendly curve). This method leverages a variation of the Schnorr signature scheme to prove that the same secret scalar is used in both groups without revealing the value of x. This approach can be useful in applications where compatibility with different cryptographic groups is required. For example, in the context of using the Lightning Network to purchase in a PTLC a key to be used with pairing-based cryptography. In general, it is interesting for Adaptor Signatures, Scriptless Scripts, and Discreet Log Contracts.


  1. Let G_secp256k1 be a generator of the secp256k1 elliptic curve group and G_pairing be a generator of a pairing-friendly elliptic curve group.
  2. Let x be the secret scalar to be ported from the secp256k1 group to the pairing-friendly group.
  3. Compute X_secp256k1 = x * G_secp256k1 and X_pairing = x * G_pairing.


  1. Choose a random nonce r.
  2. Compute public nonces R_secp256k1 = r * G_secp256k1 and R_pairing = r * G_pairing.
  3. Compute a challenge c = H(R_secp256k1 | R_pairing).
  4. Compute the proof of knowledge for x: s = r + c * x.

Send R_secp256k1, R_pairing, and s to the verifier.


  1. Compute the challenge c = H(R_secp256k1 | R_pairing).
  2. Verify s * G_secp256k1 == R_secp256k1 + c * X_secp256k1.
  3. Verify s * G_pairing == R_pairing + c * X_pairing.

By using this adapted proof, the same secret scalar x is shown to be used in both the secp256k1 group and the pairing-friendly group without revealing the value of x. The verifier can be confident that the secret value x * G_secp256k1 is mapped to x * G_pairing.


  • Security is reduced if the scalar x is in the size of the smaller group secp256k1 and not in the size of the pairing-friendly group


This scheme is broken, because s can have meaning only in relation to a particular group order. Since the group orders differ, we need more complex tools like range proofs to give s meaning accross groups of different orders.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment