Add an experimental schnorr signature adaptor module #268

ZhePang · 2023-08-19T19:00:18Z

Overview

This PR adds support for Schnorr Adaptor signatures. It is based on the work of Schnorr Signature by @jonasnick and @apoelstra, and the discussion #191.

Schnorr Adaptor Signatures

This implementation is mainly based on the idea of adaptor signatures in BIP-340 specification. It refers to the design and implementation of ECDSA adaptor signatures and MuSig2 adaptor signature.

Instead of having a verification algorithm for the adaptor signature, this module uses extract_t which extracts the adaptor point from the adaptor signature. (graph for complete atomic swap process)

Python

A Python specification of Schnorr Adaptor signatures has also been implemented, which generates all test vectors for the module.

ssantos21 · 2023-08-22T00:25:26Z

Concept ACK.

It might be interesting to include a examples/adaptor.c file.

instagibbs · 2023-08-22T14:23:33Z

It might be interesting to include a examples/adaptor.c file.

this would be great :)

ZhePang · 2023-08-24T15:58:56Z

@ssantos21 @instagibbs Thanks for the advice! I'll for sure add the example code for Schnorr Adaptor.

ZhePang · 2023-08-24T15:59:42Z

This pull request is still under review and most likely will have some modifications. Feel free to give me more suggestions and advice!

siv2r · 2023-08-27T12:28:11Z

The current const time test is failing because:

invalid compressed adaptor point value used (the pt doesn't lie on the secp curve)
pre_sig doesn’t declassify R, and T before using them is gej_add_ge_var

I have fixed these issues in this commit: siv2r@ad1cc6e. Feel free to cherry-pick it using git or simply copy the changes :)

The commit also adds const-time tests for the adapt, and extract_adaptor APIs.

instagibbs · 2023-08-28T15:32:48Z

Pushed an example file, in the pattern of proposed LN PTLC usage: https://github.com/instagibbs/secp256k1-zkp/tree/schnorr-adaptor-signature-example

feel free to cherry-pick as well

include/secp256k1_schnorr_adaptor.h

src/modules/schnorr_adaptor/main_impl.h

ci/cirrus.sh

jonasnick · 2023-10-12T20:55:32Z

We've just merged #270 which means that this PR can be rebased to fix CI. Note that rebasing may require some additional changes that are documented in #271. Let me know if you have any questions.

add schnorr adaptor nonce function that follows BIP-340 and also accepts the adaptor point as input add presign, extract_t, adapt, and extract_adaptor APIs add tests for schnorr adaptor nonce functions and APIs

…daptor point in the nonce function

added new hash tags specifically for schnorr adaptor

jonasnick

The CI tasks fail because .github/workflows/ci.yml does not contain a definition of SCHNORRADAPTOR. Just search for BPPP and add a definition for SCHNORRADAPTOR right next to it that defines SCHNORRADAPTOR to the same value as BPPP ('yes' or 'no').

ci/ci.sh

src/modules/schnorr_adaptor/tests_impl.h

include/secp256k1_schnorr_adaptor.h

remix7531

Over all, what I found challenging using this new feature is the naming of function arguments and the corresponding comments. It led to confusion whether a function takes a pre signature or the Schnorr signature (sig64 vs sig65). Same goes for adaptor point (t33) vs. adaptor (t32)

sig65: Should always named the same. Either "serialized adaptor signature" or "adaptor signature", never just "serialized signature".

include/secp256k1_schnorr_adaptor.h

Tibo-lg · 2023-12-06T01:01:56Z

I was playing around with this, and it's great! Though one issue I encountered is that the schnorr_adaptor_extract_adaptor will sometimes lead to a call to the illegal_callback for invalid adaptor signatures when the extracted public key is invalid (which leads to a panic at the rust layer). This makes is not a very good method for verifying adaptor signatures.

include/secp256k1_schnorr_adaptor.h

ZhePang · 2024-01-02T14:40:15Z

I was playing around with this, and it's great! Though one issue I encountered is that the schnorr_adaptor_extract_adaptor will sometimes lead to a call to the illegal_callback for invalid adaptor signatures when the extracted public key is invalid (which leads to a panic at the rust layer). This makes is not a very good method for verifying adaptor signatures.

Hi @Tibo-lg , we expect users to call schnorr_adaptor_extract (was extract_t) before schnorr_adaptor_extract_sec (was schnorr_adaptor_extract_adaptor) so in this way the adaptor signature passed to 'extract_sec' is valid and would not raise illegal_callback. We'll put that in the documentation, thanks for mentioning it up!

jonasnick · 2024-01-04T18:04:46Z

Hi @Tibo-lg , we expect users to call schnorr_adaptor_extract (was extract_t) before schnorr_adaptor_extract_sec (was schnorr_adaptor_extract_adaptor) so in this way the adaptor signature passed to 'extract_sec' is valid and would not raise illegal_callback. We'll put that in the documentation, thanks for mentioning it up!

Actually we don't. Sorry, I was wrong when we talked about this. Typically, the party that created the adaptor signature would call extract_sec and therefore they know that they created the first byte correctly. But since this cannot be guaranteed in a proper type safe language like rust, I'd prefer if we'd remove the ARG_CHECK and just returned 0 instead.

jonasnick

I've just completed a review of your code and noticed a few areas that could benefit from refinement. I did not find any serious issues. It would be good if we could add another test vector as mentioned in the review comments. As promised, I'll also follow-up with an attempt at a module level documentation.

To further enhance your code's readability, you may want to tweak some of the code comments in the presign, extract, adapt, and extract_sec functions.

include/secp256k1_schnorr_adaptor.h

src/modules/schnorr_adaptor/main_impl.h

include/secp256k1_schnorr_adaptor.h

src/modules/schnorr_adaptor/main_impl.h

jonasnick · 2024-01-05T10:58:34Z

Here's my suggestion for a module level documentation (to be put at the top of include/secp256k1_schnorr_adaptor.h):

/** This module provides an experimental implementation of a Schnorr adaptor
 *  signature protocol variant.
 *
 *  The test vectors have been generated and cross-verified using a Python
 *  implementation of this adaptor signature variant available at [0].
 *
 *  The protocol involves two parties, Alice and Bob. The general sequence of
 *  their interaction is as follows:
 *  1. Alice calls the `schnorr_adaptor_presign` function for an adaptor point T
 *  and sends the pre-signature to Bob.
 *  2. Bob extracts the adaptor point T from the pre-signature using
 *  `schnorr_adaptor_extract`.
 *  3. Bob provides the pre-signature and the discrete logarithm of T to
 *  `schnorr_adaptor_adapt` which outputs a valid BIP 340 Schnorr signature.
 *  4. Alice extracts the discrete logarithm of T from the pre-signature and the
 *  BIP 340 signature using `schnorr_adaptor_extract_sec`.
 *
 *  In contrast to common descriptions of adaptor signature protocols, this
 *  module does not provide a verification algorithm for pre-signatures.
 *  Instead, `schnorr_adaptor_extract` returns the adaptor point encoded by a
 *  pre-signature, reducing communication cost. If a verification function for
 *  pre-signatures is needed, it can be easily simulated with
 *  `schnorr_adaptor_extract`.
 *
 *  Assuming that BIP 340 Schnorr signatures satisfy strong unforgeability under
 *  chosen message attack, the Schnorr adaptor signature scheme fulfills the
 *  following properties as formalized by [1].
 *
 *  - Witness extractability:
 *    If Alice
 *      1. creates a pre-signature with `schnorr_adaptor_presign` for message m
 *         and adaptor point T and
 *      2. receives a Schnorr signature for message m that she hasn't created
 *         herself,
 *    then Alice is able to obtain the discrete logarithm of T with
 *    `schnorr_adaptor_extract_sec`.
 *
 *  - Pre-signature adaptability:
 *    If Bob
 *      1. receives a pre-signature and extracts an adaptor point T using
 *         `schnorr_adaptor_extract`, and
 *      2. obtains the discrete logarithm of the adaptor point T
 *    Then then Bob is able to adapt the received pre-signature to a valid BIP
 *    340 Schnorr signature using `schnorr_adaptor_adapt`.
 *
 *  - Existential Unforgeability:
 *    Bob is not able to create a BIP 340 signature from a pre-signature for
 *    adaptor T without knowing the discrete logarithm of T.
 *
 *  - Pre-signature existiential unforgeability:
 *    Only Alice can create a pre-signature for her public key.
 *
 *  [0] https://github.com/ZhePang/Python_Specification_for_Schnorr_Adaptor
 *  [1] https://eprint.iacr.org/2020/476.pdf
 */

jonasnick · 2024-01-05T10:59:29Z

include/secp256k1_schnorr_adaptor.h

+ */
+SECP256K1_API const secp256k1_adaptor_nonce_function_hardened secp256k1_adaptor_nonce_function_bip340;
+
+/** Create a Schnorr adaptor signature.


Would it make sense to replace the term "adaptor signature" with "pre-signature" to be consistent with the literature (see #268 (comment))?

siv2r · 2024-01-09T20:24:48Z

src/modules/schnorr_adaptor/main_impl.h

+
+const secp256k1_adaptor_nonce_function_hardened secp256k1_adaptor_nonce_function_bip340 = adaptor_nonce_function_bip340;
+
+static int secp256k1_schnorr_adaptor_presign_internal(const secp256k1_context *ctx, unsigned char *presig65, const unsigned char *msg32, const secp256k1_keypair *keypair, secp256k1_adaptor_nonce_function_hardened noncefp, const unsigned char *adaptor, void *ndata) {


Suggested change

static int secp256k1_schnorr_adaptor_presign_internal(const secp256k1_context *ctx, unsigned char *presig65, const unsigned char *msg32, const secp256k1_keypair *keypair, secp256k1_adaptor_nonce_function_hardened noncefp, const unsigned char *adaptor, void *ndata) {

static int secp256k1_schnorr_adaptor_presign_internal(const secp256k1_context *ctx, unsigned char *presig65, const unsigned char *msg32, const secp256k1_keypair *keypair, secp256k1_adaptor_nonce_function_hardened noncefp, const secp256k1_pubkey *adaptor, void *ndata) {

The current design allows the user to input an invalid adaptor point. By making this arg as secp256k1_pubkey, we can catch an invalid 33-byte adaptor point during secp256k1_ec_pubkey_parse.

secp256k1_ecdsa_adaptor_encrypt API does the same.

I am unsure if the change is necessary since we parse the adaptor point using secp256k1_ec_pubkey_parse inside the presign function anyway.

The essence of this modification is to make a design choice about serialization/deserialization.

Option 1: user handles the ser/de-ser of the adaptor point

we receive the adaptor point as secp256k1_pubkey (in presign & extract_adaptor)

Option 2: adaptor interface handles the ser/de-ser of the adaptor point

we receive the adaptor point as unsigned_char * (in presign & extract_adaptor)

Leaving the ser/de-ser to the user makes more sense to me since we already do this for the pubkey point. What’s the libsecp norm here?

I just realized there is already a comment regarding this: #268 (comment). We are going with Option 1.

Yes, I'd say the libsecp norm is to allow avoiding unnecessary costly recomputations such as pubkey deserialization.

src/modules/schnorr_adaptor/tests_impl.h

siv2r · 2024-01-17T11:24:41Z

src/modules/schnorr_adaptor/tests_impl.h

+    /* NULL algo is disallowed */
+    CHECK(adaptor_nonce_function_bip340(nonce, msg, key, t, pk, NULL, 0, NULL) == 0);
+    CHECK(adaptor_nonce_function_bip340(nonce, msg, key, t, pk, algo, algolen, NULL) == 1);
+    /* Other algo is fine */


Some additional edge-case tests that could be added here.

/* Empty algo is fine */ memset(algo, 0x00, algolen); CHECK(adaptor_nonce_function_bip340(nonce, msg, key, t, pk, algo, algolen, NULL) == 1); /* Max algo is fine */ memset(algo, 0xFF, algolen); CHECK(adaptor_nonce_function_bip340(nonce, msg, key, t, pk, algo, algolen, NULL) == 1);

I don't think this test significantly increases test coverage because the nonce function does relatively little with algo. If we test algo = 0 an algo 0xff...f, why not test the same for the other nonce function arguments?

why not test the same for the other nonce function arguments?

I didn't consider this case. I suggested those tests because the ECDSA adaptor had them.

I take back my suggestion. The adaptor_nonce_function_bip340 function passes its arguments to the hash function without checking their values (even their validity), except for algo and aux. Thus, a min-max test for each args seems unnecessary.

Should we add a test for a non-null aux_rand argument? The current tests don't seem to hit the if (data != NULL) branch in adaptor_nonce_function_bip340.

src/modules/schnorr_adaptor/tests_impl.h

siv2r · 2024-01-17T18:21:07Z

src/modules/schnorr_adaptor/tests_impl.h

+    CHECK_ILLEGAL(CTX, secp256k1_schnorr_adaptor_extract(CTX, t2, sig, msg, NULL));
+    CHECK_ILLEGAL(CTX, secp256k1_schnorr_adaptor_extract(CTX, t2, sig, msg, &zero_pk));
+
+    CHECK(secp256k1_schnorr_adaptor_adapt(CTX, sig64, sig, secadaptor) == 1);


nit: we can check this sig64 result using schnorrsig_verify after this line.

siv2r · 2024-01-18T18:12:07Z

src/modules/schnorr_adaptor/tests_impl.h

It would be nice to have a use-case test. For example,

Schnorrsig has test_schnorrsig_taproot

ECDSA adaptor has multi_hop_lock_tests

Musig2 adaptor has scriptless_atomic_swap

Yes, similar to the "correctness" suggestion here: #268 (comment)

siv2r reviewed Aug 29, 2023

View reviewed changes

siv2r reviewed Aug 30, 2023

View reviewed changes

siv2r reviewed Sep 1, 2023

View reviewed changes

src/modules/schnorr_adaptor/main_impl.h Outdated Show resolved Hide resolved

src/modules/schnorr_adaptor/main_impl.h Show resolved Hide resolved

src/modules/schnorr_adaptor/main_impl.h Show resolved Hide resolved

ci/cirrus.sh Outdated Show resolved Hide resolved

jonasnick mentioned this pull request Sep 10, 2023

Add Schnorrsig half aggregation #130

Closed

ZhePang added 3 commits October 24, 2023 14:27

Add an experimental schnorr signature adaptor module

555abe5

add schnorr adaptor nonce function that follows BIP-340 and also accepts the adaptor point as input add presign, extract_t, adapt, and extract_adaptor APIs add tests for schnorr adaptor nonce functions and APIs

updated the implementation and tests by accepting whole 33 bytes of a…

e0b87db

…daptor point in the nonce function

added new hash tags specifically for schnorr adaptor

ed3e2ae

added new hash tags specifically for schnorr adaptor

ZhePang force-pushed the schnorr-adaptor-signature branch from d268b56 to ed3e2ae Compare October 24, 2023 18:49

update the test to follow the new practice

9735b05

jonasnick reviewed Oct 31, 2023

View reviewed changes

ci/ci.sh Show resolved Hide resolved

src/modules/schnorr_adaptor/tests_impl.h Outdated Show resolved Hide resolved

jonasnick reviewed Oct 31, 2023

View reviewed changes

updated test vectors

8c9e169

remix7531 reviewed Nov 30, 2023

View reviewed changes

Bug fixed: all hash tags correct and passed all vector tests

2aa074d

changed variable and function names for clarity and simplicity

094b863

jonasnick reviewed Jan 2, 2024

View reviewed changes

include/secp256k1_schnorr_adaptor.h Outdated Show resolved Hide resolved

jonasnick reviewed Jan 4, 2024

View reviewed changes

jonasnick reviewed Jan 5, 2024

View reviewed changes

siv2r reviewed Jan 9, 2024

View reviewed changes

siv2r mentioned this pull request Jan 10, 2024

Add first byte check for pre-sig ZhePang/Python_Specification_for_Schnorr_Adaptor#7

Closed

siv2r reviewed Jan 17, 2024

View reviewed changes

src/modules/schnorr_adaptor/tests_impl.h Show resolved Hide resolved

siv2r reviewed Jan 17, 2024

View reviewed changes

siv2r reviewed Jan 18, 2024

View reviewed changes

update naming and documentations and some debugs

344620e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add an experimental schnorr signature adaptor module #268

Add an experimental schnorr signature adaptor module #268

ZhePang commented Aug 19, 2023

ssantos21 commented Aug 22, 2023

instagibbs commented Aug 22, 2023

ZhePang commented Aug 24, 2023

ZhePang commented Aug 24, 2023

siv2r commented Aug 27, 2023 •

edited

instagibbs commented Aug 28, 2023

jonasnick commented Oct 12, 2023

jonasnick left a comment

remix7531 left a comment •

edited

Tibo-lg commented Dec 6, 2023

ZhePang commented Jan 2, 2024

jonasnick commented Jan 4, 2024

jonasnick left a comment

jonasnick commented Jan 5, 2024

jonasnick Jan 5, 2024

siv2r Jan 9, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 17, 2024 •

edited

jonasnick Jan 18, 2024

siv2r Jan 17, 2024

jonasnick Jan 18, 2024

siv2r Jan 18, 2024 •

edited

siv2r Jan 18, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 18, 2024 •

edited

jonasnick Jan 18, 2024


		const secp256k1_adaptor_nonce_function_hardened secp256k1_adaptor_nonce_function_bip340 = adaptor_nonce_function_bip340;

		static int secp256k1_schnorr_adaptor_presign_internal(const secp256k1_context ctx, unsigned char presig65, const unsigned char msg32, const secp256k1_keypair keypair, secp256k1_adaptor_nonce_function_hardened noncefp, const unsigned char adaptor, void ndata) {

Add an experimental schnorr signature adaptor module #268

Are you sure you want to change the base?

Add an experimental schnorr signature adaptor module #268

Conversation

ZhePang commented Aug 19, 2023

Overview

Schnorr Adaptor Signatures

Python

ssantos21 commented Aug 22, 2023

instagibbs commented Aug 22, 2023

ZhePang commented Aug 24, 2023

ZhePang commented Aug 24, 2023

siv2r commented Aug 27, 2023 • edited

instagibbs commented Aug 28, 2023

jonasnick commented Oct 12, 2023

jonasnick left a comment

Choose a reason for hiding this comment

remix7531 left a comment • edited

Choose a reason for hiding this comment

Tibo-lg commented Dec 6, 2023

ZhePang commented Jan 2, 2024

jonasnick commented Jan 4, 2024

jonasnick left a comment

Choose a reason for hiding this comment

jonasnick commented Jan 5, 2024

jonasnick Jan 5, 2024

Choose a reason for hiding this comment

siv2r Jan 9, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 17, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 17, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 17, 2024 • edited

Choose a reason for hiding this comment

jonasnick Jan 18, 2024

Choose a reason for hiding this comment

siv2r Jan 17, 2024

Choose a reason for hiding this comment

jonasnick Jan 18, 2024

Choose a reason for hiding this comment

siv2r Jan 18, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 18, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 17, 2024 • edited

Choose a reason for hiding this comment

siv2r Jan 18, 2024 • edited

Choose a reason for hiding this comment

jonasnick Jan 18, 2024

Choose a reason for hiding this comment

siv2r commented Aug 27, 2023 •

edited

remix7531 left a comment •

edited

siv2r Jan 9, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 18, 2024 •

edited

siv2r Jan 18, 2024 •

edited

siv2r Jan 17, 2024 •

edited

siv2r Jan 18, 2024 •

edited