Allow sign-to-contract commitments in schnorrsigs [̶a̶l̶t̶e̶r̶n̶a̶t̶i̶v̶e̶]̶ #589

jonasnick · 2019-02-14T19:52:06Z

~~This is an alternative to #588 as requested by @real-or-random which I also slightly prefer~~ (EDIT: this seems to be generally preferred now). The main difference is that the sign-to-contract commitment step happens in the signature function and not the nonce function. Also the nonce_is_negated argument in schnorrsig_sign is replaced by an s2c_opening object. A new argument to schnorrsig_sign is added called s2c_data. There's no need to add a context argument to nonce functions. I also added parsing and serialization for s2c_openings. Manual initialization of s2c_opening is not necessary anymore.

Example:

/* Signer */
secp256k1_s2c_opening opening;
unsigned char s2c_data[32];
secp256k1_schnorrsig_sign(sign, &sig, &opening, msg, sk1, &s2c_data, NULL, NULL);

/* Verifier */
secp256k1_schnorrsig_verify_s2c_commit(ctx, &sig, s2c_data, &opening);

gmaxwell · 2019-02-15T00:17:08Z

That workflow doesn't make it look as easy to implement s2c anti-sidechannel blinding, if I understand it.

jonasnick · 2019-02-15T09:49:25Z

Hm, I've done a quick and dirty rebase of the anti-nonce-sidechannel and it seems straight forward. It's even a bit simpler on the client side.

jonasnick · 2019-02-15T13:36:16Z

I opened PR #590 to show the anti nonce-sidechannel protocol can be built on this PR in a similar way.

real-or-random · 2019-02-15T14:56:16Z

Concept ACK

real-or-random · 2019-02-15T15:01:23Z

I guess this is a more general discussion because it's also in ECDSA:
What's the exact benefit of the user being able to provide a nonce function (and possibly shoot herself in the foot?) I'm not sure if there are meaningful cases,so I'm somewhat curious if anybody currently uses this in practice with ECDSA.

gmaxwell · 2019-02-19T08:45:42Z

@real-or-random IIRC it's actually used by joinmarket to do ECDH with the R value for a stealth payment donation feature. (like one of the outputs pays to P+H(kP)G for some pubkey P). The payments can be found by the recipient simply scanning every signature in the chain, performing ECDH with it, and checking the outputs...

Less cosmically RFC6979 is kind of absurd and actually makes signing measurably slower compared to just a simple hash-- for applications that care about signing speed (like matt's betterhash) substituting it is probably a good idea. Not sure who if anyone is doing that right now, but some things probably should be. (Though those same applications should probably also do batch nonce generation and other stuff that wouldn't really be simple with the current nonce function interface)

Re: footgunnery, I haven't yet seen anyone footgun themselves that way. Creating a working nonce function takes a fair amount of work, so I think it's likely that if anyone bothers they at least have a fighting chance to get it right. I think the best mental model is that we're trying to defend against users that are equal parts lazy and ignorant. Give them a nonce argument and they will set the nonce to private key xor messagehash (actual example which demonstrates lazy+ignorant), but give them a nonce function argument and they'll leave it null unless they actually have a real reason to do otherwise. :)

real-or-random · 2019-02-19T14:54:36Z

Okay, convinced.

I think the best mental model is that we're trying to defend against users that are equal parts lazy and ignorant.

That's indeed a good way to think about it.

Maybe it's still a good idea to make it more prominent in the docs that people should use the default unless they really know what they are doing.

gmaxwell · 2019-02-20T09:53:52Z

Sounds fine to me. I also think we could explicitly say that the nonce function isn't an interface that we particularly care about keeping stable.

src/secp256k1.c

include/secp256k1.h

src/secp256k1.c

include/secp256k1_schnorrsig.h

apoelstra · 2019-02-21T15:33:15Z

valgrind ./tests 1 shows a bunch of branches on uninitialized memory.

src/modules/schnorrsig/main_impl.h

elichai · 2019-07-01T22:04:06Z

src/secp256k1.c

+    return secp256k1_gej_is_infinity(&pj);
+}
+
+static char s2c_opening_magic[8] = { 0x5d, 0x05, 0x20, 0xb8, 0xb7, 0xf2, 0xb1, 0x68 };


Here it's char but in the struct it's unsigned char.

Switched to uint64_t because there's less room for mistakes and it's easier to read.

elichai · 2019-07-01T22:19:42Z

src/modules/schnorrsig/main_impl.h

+    secp256k1_ge_set_gej(&r, &rj);
+    if (s2c_opening != NULL) {
+        secp256k1_s2c_opening_init(s2c_opening);
+        if (s2c_data32 != NULL) {


Maybe add a check if s2c_opening == NULL || s2c_data32 == NULL? Because if that's true I think it means the user made a mistake

You mean CHECK((s2c_opening != NULL) == (s2c_data32 != NULL)) (both should be NULL or both should be non-NULL)? Yes, I'll add an ARG_CHECK

elichai · 2019-07-01T22:43:13Z

include/secp256k1.h

+    /* Public nonce before applying the sign-to-contract commitment */
+    secp256k1_pubkey original_pubnonce;
+    /* Integer indicating if signing algorithm negated the nonce */
+    unsigned char nonce_is_negated;


Is this a computational optimization to avoid computing the jacobi symbol on secp256k1_schnorrsig_verify_s2c_commit?

Yes, we could could compute the ec_commitment of original_pubnonce and data then negate if this is not a valid nonce. But this prevents batch verification. I will mention this in the doc.

added comment to explain this

src/modules/schnorrsig/main_impl.h

elichai · 2019-07-01T22:53:06Z

(I also prefer this design over #588)

real-or-random · 2019-07-04T21:50:20Z

include/secp256k1.h

+    /* Byte indicating if signing algorithm negated the nonce. Alternatively when
+     * verifying we could compute the EC commitment of original_pubnonce and the
+     * data and negate if this would not be a valid nonce. But this would prevent
+     * batch verification of sign-to-contract commitments. */
    unsigned char nonce_is_negated;


nit, feel free to ignore: Boolean values are typically represented by int and not unsigned char.

Yes but ints are the worst. Since nonce_is_negated is only ever 0 or 1 I changed this to int.

jonasnick · 2019-07-04T22:10:36Z

rebased on schnorrsigs PR and squashed

elichai · 2019-07-28T01:48:19Z

include/secp256k1.h

+SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_s2c_opening_parse(
+    const secp256k1_context* ctx,
+    secp256k1_s2c_opening* opening,
+    const unsigned char *input34


Is it worth it to optimize this down to 33 bytes by just using a single bit to mark if the nonce has been negated?(we can use the same byte that we use to signal the parity)

elichai · 2019-07-28T02:19:09Z

src/modules/schnorrsig/main_impl.h

+            secp256k1_pubkey_save(&s2c_opening->original_pubnonce, &r);
+            secp256k1_ec_commit_seckey(ctx, buf, &s2c_opening->original_pubnonce, s2c_data32, 32);
+            secp256k1_scalar_set_b32(&k, buf, NULL);
+            secp256k1_ecmult_gen(&ctx->ecmult_gen_ctx, &rj, &k);


Maybe instead of recomputing the secret key and multiplying by the generator you can compute H(R, data)*G and add that to the R you already have?
(although since all of this is constant time it might result in no performance change? I'm not sure about it)

It's R + H(R, data)*G vs. k*G. The latter is less code and faster (no addition). This is independent of being constant time.

I guess the performance will be a matter of will this wrap around the order or not. (if it will cause a wrap than k*G is gonna be faster, if it doesn't then calculating the H(R,data)*G and adding to R should be faster i think)

No. Adding two curve points is completely separate from "wrapping around the order".

elichai · 2019-07-28T03:14:50Z

src/secp256k1.c

+    /* Return commitment == commitment_tmp */
+    secp256k1_gej_set_infinity(&pj);
+    secp256k1_pubkey_load(ctx, &p, &commitment_tmp);
+    secp256k1_gej_add_ge_var(&pj, &pj, &p, NULL);


You can use secp256k1_gej_set_ge() instead of setting to infinity and adding

jonasnick

Added commit to make the opening serialization 33 bytes instead of 34.

jonasnick · 2019-07-30T16:36:56Z

src/modules/schnorrsig/main_impl.h

+            secp256k1_pubkey_save(&s2c_opening->original_pubnonce, &r);
+            secp256k1_ec_commit_seckey(ctx, buf, &s2c_opening->original_pubnonce, s2c_data32, 32);
+            secp256k1_scalar_set_b32(&k, buf, NULL);
+            secp256k1_ecmult_gen(&ctx->ecmult_gen_ctx, &rj, &k);


It's R + H(R, data)*G vs. k*G. The latter is less code and faster (no addition). This is independent of being constant time.

jonasnick · 2019-07-30T16:52:29Z

include/secp256k1.h

+SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_s2c_opening_parse(
+    const secp256k1_context* ctx,
+    secp256k1_s2c_opening* opening,
+    const unsigned char *input34


jonasnick · 2022-03-24T14:05:49Z

This PR is quite outdated. Sign-to-contract should use the schnorrsig_sign_custom API. PR #1018 is a WIP continuation of this work. Closing.