FROST Trusted Dealer #278

jesseposner · 2023-11-23T19:10:06Z

This PR implements a BIP-340 compatible threshold signature system based on FROST (Flexible Round-Optimized Schnorr Threshold Signatures) with a trusted dealer. This PR does not implement distributed key generation (DKG).

FROST Paper

This PR is based upon the FROST paper by Chelsea Komlo and Ian Goldberg and the draft RFC.

FROST Signing BIP

This PR implements the FROST signing BIP.

Prior Work

This PR is patterned on the APIs, and in many instances duplicates code, from the MuSig2 implementation due to their similarities in nonce generation and signing.

real-or-random

some initial comments, more tomorrow

real-or-random · 2024-04-18T16:05:17Z

include/secp256k1_frost.h

+/** Serialize a FROST share
+ *
+ *  Returns: 1 when the share could be serialized, 0 otherwise
+ *  Args:    ctx: a secp256k1 context object


nit: see bitcoin-core/secp256k1@aa3dd52 for consistent wording here

real-or-random · 2024-04-18T16:06:44Z

include/secp256k1_frost.h

+ *  Each participant _must_ have a secure channel with the trusted dealer with
+ *  which they can transmit shares to each other.
+ *
+ *  A new seed32 _must_ be used for each key generation session. The trusted


nit: s/new/fresh

By the way, we need to say similar things for musig sessions. Feel free to steal some sentences/phrasing ideas from bitcoin-core/secp256k1#1479.

real-or-random · 2024-04-18T16:07:18Z

include/secp256k1_frost.h

+ *  start a new session to generate a new key, they must NOT REUSE their
+ *  respective seed32 again, but instead generate a new one. It is recommended


s/again// ("reuse again" is saying the same thing twice)

real-or-random · 2024-04-18T16:10:12Z

include/secp256k1_frost.h

+    const unsigned char *in32
+) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3);
+
+/** Creates key generation shares


"key shares" or "key generation" shares?

real-or-random · 2024-04-18T16:12:42Z

include/secp256k1_frost.h

+ *  Each participant _must_ have a secure channel with the trusted dealer with
+ *  which they can transmit shares to each other.


Hm, this may be slightly confusing because one could read it as "must have established a secure channel already", but that's of course not necessary. Maybe: "The trusted dealer must transmit shares over secure channels to participants."

real-or-random · 2024-04-18T16:14:15Z

src/modules/frost/keygen_impl.h

+    secp256k1_sha256_write(&sha, polygen, 16);
+    secp256k1_sha256_finalize(&sha, polygen);
+
+    /* Derive share */


s/share/shares

real-or-random · 2024-04-18T16:17:39Z

src/modules/frost/keygen_impl.h

+    for (i = 0; i < n_participants; i++) {
+        secp256k1_scalar share_i, idx;
+
+        secp256k1_scalar_clear(&share_i);


This function is just for nuking memory. Use _scalar_set_int(0) to set to zero. (We should probably have a dedicated function, but we don't have one currently.)

real-or-random · 2024-04-18T16:20:11Z

include/secp256k1_frost.h

+ *  Args:            ctx: pointer to a context object
+ *  Out:          shares: pointer to the key generation shares
+ *             pubshares: pointer to the public verification shares
+ *                    pk: pointer to the x-only public key


Should this be an x-only key? I'm not entirely sure, I would need to think about it.

The function conditionally inverts the shares to guarantee that the private key will match the x-only key.

Since the primary use-case will be on-chain signing, I think it's a useful simplification to take care of the negation during share generation and makes it easier to reason about in secp256k1_frost_pubkey_get and secp256k1_frost_pubkey_tweak.

Upon further reflection, I'm realizing it's not a useful simplification because in practice the output of the DKG will typically be further tweaked by a BIP32 tweak and then a taproot tweak, rather than used directly.

So I now think it would be better to have the DKG output a 33-byte key rather than an x-only key.

I've taken a stab at implementing this change, however, it requires tracking more state during signing.

Currently, nonce_process takes an xonly agg_pk and optionally a tweak_cache and returns a session. partial_sign takes a session and optionally a tweak_cache.

partial_sign only needs to handle negation logic if a tweak_cache is present because the DKG outputs an x-only key. If we change the DKG to output a 33-byte key, then nonce_process will need to take a 33-byte agg_pk and it will need to save a parity bit, serialized as a byte, in the session, so that partial_sign can handle the negation logic for when a tweak_cache is not present.

So while I don't think there's any reason for the protocol to output a 33-byte key, it seems useful to have the implementation do so, because it avoids a serialized byte in the session and I don't see a downside.

I need to compare this approach to the one taken in the signing BIP. The BIP proposes that the pubshares be saved to the session and the 33 byte public key is derived from the pubshares.

siv2r/bip-frost-signing#12

Perhaps the best reason to not output an xonly key from the DKG is that we don't want to encourage FROST DKG outputs being used directly on-chain without an unspendable script path because unlike MuSig, FROST does not randomize the group public key: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-23

The signing BIP now uses signer public shares to initialize the tweak context (name to be updated) rather than the group public key. Hence, it no longer depends on whether the group pubkey (produced by keygen) is plain or x-only.

An alternative design choice here is for trusted_gen to always output tweak_cache and optionally group_pk. This would be similar to how musig_pubkey_agg outputs keyagg_cache and optionally agg_pk.

real-or-random · 2024-04-18T16:23:12Z

In general, I think it would be nice to get this rebase this. (Should be mostly trivial.) Also, CMake support is missing because we have this now for all other -zkp modules (#288 ), but that's currently not essential right now.

siv2r · 2024-04-28T07:49:58Z

src/modules/frost/session_impl.h

+    ARG_CHECK(n_pubnonces > 1);
+    ARG_CHECK(my_id != 0);
+    for (i = 0; i < n_pubnonces; i++) {
+        ARG_CHECK(ids[i] != 0);


should we also ARG_CHECK for 1 <= ids[i] <= max_participant?

The function doesn't currently take max_participant as an input, and I'm not sure if it's worth requiring the extra state to perform this check.

siv2r · 2024-04-29T11:45:47Z

include/secp256k1_frost.h

+    const unsigned char *msg32,
+    const secp256k1_xonly_pubkey *agg_pk,
+    const unsigned char *extra_input32
+) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4);


We can also add pubshare as an input argument. MuSig2 hashes the individual pubkey when generating the nonces, but we don't need to make pubshare a mandatory argument like MuSig2 does (more info).

How do we decide the args supplied to the hash function for generating a nonce? Should we throw in all available signer information into the hash function? For instance, can we include the participant identifier too?

Related issue: siv2r/bip-frost-signing#15, which suggests using tweak_cache instead of agg_pk as the input arg.

jesseposner · 2024-06-17T23:57:19Z

configure.ac

@@ -470,6 +475,14 @@ if test x"$enable_module_ecdsa_adaptor" = x"yes"; then
  SECP_CONFIG_DEFINES="$SECP_CONFIG_DEFINES -DENABLE_MODULE_ECDSA_ADAPTOR=1"
 fi

+if test x"$enable_module_frost" = x"yes"; then
+  if test x"$enable_module_schnorrsig" = x"no"; then
+    AC_MSG_ERROR([Module dependency error: You have disabled the schnorrsig module explicitly, but it is required by the musig module.])


%s/musig/frost

siv2r · 2024-08-07T13:13:01Z

configure.ac

+  if test x"$enable_module_frost" = x"yes"; then
+    AC_MSG_ERROR([FROST module is experimental. Use --enable-experimental to allow.])
+  fi


nit: when we execute ./configure --enable-module-frost, the following error appears:

configure: error: MuSig module is experimental. Use --enable-experimental to allow.

instead of:

configure: error: FROST module is experimental. Use --enable-experimental to allow.

To resolve this issue, we should reposition the FROST module check before the MuSig experimental module check (lines 486-488).

Can you try again? I wasn't able to reproduce the issue.

When I run ./configure --enable-module-frost I get configure: error: FROST module is experimental. Use --enable-experimental to allow..

siv2r · 2024-08-07T13:31:51Z

src/modules/frost/keygen_impl.h

+    secp256k1_sha256_finalize(&sha, polygen);
+
+    /* Derive share */
+    /* See draft-irtf-cfrg-frost-08#appendix-C.1 */


nit: we can update this to refer to the completed RFC: https://datatracker.ietf.org/doc/rfc9591/

siv2r · 2024-08-14T08:58:33Z

src/modules/frost/session_impl.h

+    /* TODO: this doesn't have the same sidechannel resistance as the BIP340
+     * nonce function because the seckey feeds directly into SHA. */


I agree. We must XOR key32 and session_id (in const-time) before feeding them to SHA256

I need to bring these changes over from MuSig: 206017d

siv2r · 2024-08-14T09:04:14Z

src/group.h

+static void secp256k1_point_save_ext(unsigned char *data, secp256k1_ge *ge);
+
+static void secp256k1_point_load_ext(secp256k1_ge *ge, const unsigned char *data);


The libsecp repo defines these functions using different names:

point_save_ext -> ge_to_bytes_ext

point_load_ext -> ge_from_bytes_ext

siv2r · 2024-08-14T09:08:58Z

include/secp256k1_frost.h

+ *  3. Avoid copying (or serializing) the secnonce. This reduces the possibility
+ *     that it is used more than once for signing.
+ *
+ *  Remember that nonce reuse will leak the secret key!


Would it be more precise to say "will leak the agg_share" instead?

siv2r · 2024-08-14T09:15:25Z

src/modules/frost/session_impl.h

+    secp256k1_sha256 sha;
+    unsigned char seed[32];
+    unsigned char i;
+    enum { n_extra_in = 4 };


Suggested change

enum { n_extra_in = 4 };

enum { N_EXTRA_IN = 4 };

siv2r · 2024-08-14T09:33:15Z

src/modules/frost/session_impl.h

+    for (i = 0; i < n_extra_in; i++) {
+        unsigned char len;
+        if (extra_in[i] != NULL) {
+            len = 32;
+            secp256k1_sha256_write(&sha, &len, 1);
+            secp256k1_sha256_write(&sha, extra_in[i], 32);


I like this approach to hashing optional arguments—it’s cleaner than musig’s approach of using a helper function. However, there's a minor issue: the signing BIP encodes the message length as 8 bytes, but here we use 1 byte.

As stated in the BIP's noncegen:

If the optional argument m is not present:

Let m_prefixed = bytes(1, 0)

Else:

Let m_prefixed = bytes(1, 1) || bytes(8, len(m)) || m

I switched over to using the MuSig approach: 35f453d

siv2r · 2024-08-14T09:39:08Z

src/modules/frost/session_impl.h

+    return 1;
+}
+
+static void secp256k1_nonce_function_frost(secp256k1_scalar *k, const unsigned char *session_id, const unsigned char *msg32, const unsigned char *key32, const unsigned char *pk32, const unsigned char *extra_input32) {


Just a note for the future: when writing tests, we should skip two noncegen test vectors—(1) empty message and (2) 38-byte message—since our nonce generation currently only supports 32-byte messages.

siv2r · 2024-08-14T09:53:12Z

src/modules/frost/session_impl.h

+    secp256k1_sha256_finalize(&sha, seed);
+
+    for (i = 0; i < 2; i++) {
+        unsigned char buf[32];
+        secp256k1_sha256_initialize(&sha);


The method of hashing arguments in noncegen deviates from the BIP. I believe it currently computes the nonces as
$$k_i = \mathrm{H}_{\text{no-tag}}(\mathrm{H}_{\text{FROST/nonce}}(\text{optional args}) \;||\; i - 1)$$
but the BIP computes them as
$$k_i = \mathrm{H}_{\text{FROST/nonce}}(\text{optional args} \;||\; i - 1)$$

siv2r · 2024-08-16T10:57:44Z

src/modules/frost/session_impl.h

+    return 1;
+}
+
+int secp256k1_frost_nonce_process(const secp256k1_context* ctx, secp256k1_frost_session *session, const secp256k1_frost_pubnonce * const* pubnonces, size_t n_pubnonces, const unsigned char *msg32, const secp256k1_xonly_pubkey *pk, size_t my_id, const size_t *ids, const secp256k1_frost_tweak_cache *tweak_cache, const secp256k1_pubkey *adaptor) {


This function follows the nonce aggregation technique from FROST1, but the BIP uses FROST3. We may need to split this function into two:

frost_nonce_agg - computes the aggnonce: $\widetilde{R_1} || \widetilde{R_2}$ where,
$\widetilde{R_1} = \sum \limits_{i=1}^{t} R_{i, 1}$ and $\widetilde{R_2} = \sum \limits_{i=1}^{t} R_{i, 2}$

frost_nonce_process - computes the final nonce: $R_{\text{fin}} = \widetilde{R_1} + b \cdot \widetilde{R_2}$

Musig’s implementation follows the same technique

siv2r · 2024-08-16T11:00:21Z

src/modules/frost/session_impl.h

+               the generator (by simply adding the generator to one of the
+               malicious nonces), and this does not change the winning condition
+               of the EUF-CMA game. */
+            aggnonce_pt[i] = secp256k1_ge_const_g;


I believe aggnonce_pt[i] is allowed to be infinity. The NonceAgg specification serializes them using cybtes_ext, so we can use ge_to_bytes_ext here.

Setting the nonce to the generator point only occurs with the final nonce.

siv2r · 2024-08-16T11:02:43Z

src/modules/frost/session_impl.h

+
+/* TODO: consider updating to frost-08 to address maleability at the cost of performance */
+/* See https://github.com/cfrg/draft-irtf-cfrg-frost/pull/217 */
+static int secp256k1_frost_compute_noncehash(const secp256k1_context* ctx, unsigned char *noncehash, const unsigned char *msg, const secp256k1_frost_pubnonce * const* pubnonces, size_t n_pubnonces, const unsigned char *pk32, const size_t *ids) {


FROST3 computes the nonce coefficient as $b = \mathrm{H}_{\text{FROST/noncecoef}}(T || \widetilde{R_1} || \widetilde{R_2} || \widetilde{X} || msg)$, where $T$ is the set of signer ids.

We can remove the ctx object from the function args.

siv2r · 2024-08-16T11:05:37Z

src/modules/frost/session_impl.h

+    return 1;
+}
+
+static int secp256k1_frost_nonce_process_internal(const secp256k1_context* ctx, int *fin_nonce_parity, unsigned char *fin_nonce, secp256k1_scalar *b, secp256k1_gej *aggnoncej, const unsigned char *msg, const secp256k1_frost_pubnonce * const* pubnonces, size_t n_pubnonces, const unsigned char *pk32, const size_t *ids) {


We can remove the ctx object from the function args

siv2r · 2024-08-16T11:06:57Z

src/modules/frost/session_impl.h

+    secp256k1_gej_add_ge_var(&fin_nonce_ptj, &fin_nonce_ptj, &aggnonce[0], NULL);
+    secp256k1_ge_set_gej(&fin_nonce_pt, &fin_nonce_ptj);
+
+    if (secp256k1_ge_is_infinity(&fin_nonce_pt)) {


The BIP sets the final nonce to the generator point if it’s infinity.

siv2r · 2024-08-16T11:10:08Z

src/modules/frost/session_impl.h

+            secp256k1_scalar_add(&session_i.s_part, &session_i.s_part, &e_tmp);
+        }
+    }
+    /* Update the challenge by multiplying the Lagrange coefficient to prepare


I hadn’t considered this option when writing the BIP. So, right now, it computes $\lambda_{i, T}$ during Sign, not in GetSessionValue. Happy to update the BIP if this approach is better.

siv2r · 2024-08-16T11:14:45Z

include/secp256k1_frost.h

+    size_t my_id,
+    const size_t *ids,


In the documentation, we should probably mention that [1] the ids array must have unique elements, and [2] my_id must be included in ids. Otherwise, Lagrange interpolation will return incorrect values.

We could also implement ARG_CHECKs for these, but I'm not sure if it's worth the effort.

In BIP, the DeriveInterpolatingValue function fails if both these conditions aren't met.

siv2r · 2024-08-17T07:23:34Z

include/secp256k1_frost.h

+ *  Args:         ctx: pointer to a context object
+ *  In:     pre_sig64: 64-byte pre-signature
+ *              msg32: the 32-byte message being verified
+ *             pubkey: pointer to an x-only public key to verify with


Suggested change

* pubkey: pointer to an x-only public key to verify with

* agg_pk: pointer to an x-only public key to verify with

siv2r · 2024-08-17T07:28:04Z

include/secp256k1_frost.h

+ *       nonce_parity: the output of `frost_nonce_parity` called with the
+ *                     session used for producing the pre-signature
+ */
+SECP256K1_API int secp256k1_frost_verify_adaptor(


Just pointing out that there's another possible approach here. In single signer Schnorr adaptor, we use extract_adaptor_point API instead of verify_adaptor—more details. Interestingly, MuSig doesn’t include either extract_adaptor_point or verify_adaptor (not sure why).

siv2r · 2024-08-17T13:14:50Z

src/modules/frost/session_impl.h

+        if (secp256k1_fe_is_odd(&cache_i.pk.y) != cache_i.parity_acc) {
+            secp256k1_scalar_negate(&sk, &sk);
+        }


We can use this comment here (taken from musig)

/* Negate sk if secp256k1_fe_is_odd(&cache_i.pk.y)) XOR cache_i.parity_acc. * This corresponds to the line "Let d = g⋅gacc⋅d' mod n" in the * specification. */

siv2r · 2024-08-17T13:20:13Z

src/modules/frost/session_impl.h

+    ARG_CHECK(sig64 != NULL);
+    ARG_CHECK(session != NULL);
+    ARG_CHECK(partial_sigs != NULL);
+    ARG_CHECK(n_sigs > 0);


Suggested change

ARG_CHECK(n_sigs > 0);

ARG_CHECK(n_sigs > 1);

Should we do this instead?
The frost_nonce_process currently has ARG_CHECK(n_pubnonce > 1). We might want to use the same value in both functions, either 1 or 0.

siv2r · 2024-08-18T11:29:32Z

examples/frost.c

In musig's example, every function (except main) is static

siv2r · 2024-08-18T11:30:57Z

examples/frost.c

+        }
+        /* Mark signer as assigned */
+        pubnonces[i] = &signer[signer_id].pubnonce;
+        /* pubkeys[i] = &signer[signer_id].pubkey; */


I think this comment was meant to be removed

siv2r · 2024-08-18T13:41:47Z

src/modules/frost/tests_impl.h

#278 (comment) applies here too.

siv2r · 2024-08-18T13:44:02Z

src/modules/frost/tests_impl.h

+    for (i = 0; i < COUNT; i++) {
+        frost_multi_hop_lock_tests();
+    }


We can move this function call to the previous loop

siv2r · 2024-08-18T13:47:27Z

src/modules/frost/tests_impl.h

+    CHECK(secp256k1_gej_is_infinity(&summed_nonces[1]));
+}
+
+int frost_memcmp_and_randomize(unsigned char *value, const unsigned char *expected, size_t len) {


nit: same function is also used in MuSig's tests, so can we make it a helper function in src/testutil.h?

siv2r · 2024-08-28T14:45:07Z

src/modules/frost/session_impl.h

+    /* Compute "effective" nonce rj = aggnonce[0] + b*aggnonce[1] */
+    /* TODO: use multiexp to compute -s*G + e*pubshare + aggnonce[0] + b*aggnonce[1] */


I think we need to use pubnonce instead of aggnonce: #296

Responds to: BlockstreamResearch#278 (comment)

Based on: BlockstreamResearch@206017d Responds to: BlockstreamResearch#278 (comment)

Based on: 57de68994ae18d20b0b6e1a9e4531c3d88b5ec81 and 3f9bb4d868a2a27caacdaf19b08ce91ce73c1fb4 Responds to: BlockstreamResearch#278 (comment)

Responds to: BlockstreamResearch#278 (comment)

This commit adds the foundational configuration and building scripts and an initial structure for the project.

This commit adds trusted share generation, as well as share serialization and parsing.

This commit adds share verification, as well as computation of public verification shares.

This commits add BIP-341 ("Taproot") and BIP-32 ("ordinary") public key tweaking.

This commits adds nonce generation, as well as serialization and parsing.

This commit adds nonce aggregation, as well as adaptor signatures.

This commit adds signature generation and aggregation, as well as partial signature serialization and parsing.

This commit adds an example file to demonstrate how to use the module.

Add api tests, nonce tests, tweak tests, sha256 tag tests, and constant time tests.

This commit adds a documentation file with detailed instructions for how to use the module properly.

theStack

Only looked at share generation/verification so far, left a few comments below. Fwiw, I've added CMake support, feel free to pull it in: theStack@3b72fbd

theStack · 2024-09-22T10:32:48Z

src/modules/frost/keygen_impl.h

+    /* The x-coordinate must not be zero (see
+     * draft-irtf-cfrg-frost-08#section-4.2.2) */
+    if (secp256k1_scalar_is_zero(indexhash)) {
+        return 0;
+    }


As the chance of this happening is negligible, a VERIFY_CHECK might be sufficient? Then the function could be void, also simplifying the call-sites.

include/secp256k1_frost.h

theStack · 2024-09-22T10:49:08Z

src/modules/frost/keygen_impl.h

+    secp256k1_gej rj;
+    secp256k1_ge rp;
+    size_t i;
+    int ret = 1;


in secp256k1_frost_vss_gen: this value is never changed, so could remove ret and declare the function as void instead, also simplifying the call-site below.

theStack · 2024-09-23T13:01:14Z

include/secp256k1_frost.h

+ */
+typedef struct {
+    unsigned char data[36];
+} secp256k1_frost_share;


naming nit: maybe call it secshare (both for the type and its instances and (de)ser function names in the API), in order to underline that this should be kept in secret? also since the public counterpart is called pubshare.

theStack · 2024-09-23T13:12:26Z

include/secp256k1_frost.h

+ *  workflow. See
+ *  https://blockstream.com/2019/02/18/musig-a-new-multisignature-standard/ for
+ *  more details about the risks associated with serializing or deserializing
+ *  this structure.


Considering that this blog post link has been removed in the MuSig2 PR in the secp256k1 main repo (see bitcoin-core/secp256k1#1479 (comment)), I guess the same should be done here.

theStack · 2024-09-23T13:39:56Z

src/modules/frost/keygen_impl.h

+        if (secp256k1_scalar_eq(&mul, &party_idx)) {
+            continue;
+        }


maybe more a matter of taste, but the "skip for our own id" logic could be implemented before computing the _i_th indexhash by simply comparing the ids, e.g.

if (secp256k1_memcmp_var(ids33[i], my_id33, 33) == 0) { return 0; }

(untested)

src/modules/frost/keygen_impl.h

@theStack

The x-coordinate for the participant is a hash output. This x-coordinate must not be zero, however, the probability of a sha256 output being zero is 1 in 2^256. Thus, it is sufficient to use VERIFY_CHECK, which allows the function to be void, which simplifies the call-sites, as suggested by @theStack.

@theStack

Suggested by @theStack.

Suggested by theStack.

@theStack

Suggested by @theStack.

@theStack

As suggested by @theStack.

Co-authored-by: Sebastian Falbesoner <[email protected]>

jesseposner changed the title ~~Frost trusted dealer~~ FROST Trusted Dealer Nov 23, 2023

jesseposner force-pushed the frost-trusted-dealer branch from 6078d4b to ab3c7a6 Compare December 8, 2023 00:20

real-or-random reviewed Apr 18, 2024

View reviewed changes

siv2r reviewed Apr 28, 2024

View reviewed changes

siv2r reviewed Apr 29, 2024

View reviewed changes

jesseposner force-pushed the frost-trusted-dealer branch from ab3c7a6 to e94367c Compare May 14, 2024 22:30

jesseposner commented Jun 17, 2024

View reviewed changes

siv2r mentioned this pull request Jun 19, 2024

How to blame the disruptive signing participant? siv2r/bip-frost-signing#5

Open

siv2r mentioned this pull request Jul 18, 2024

Determining the inputs for the hash function that produces the nonces siv2r/bip-frost-signing#7

Open

siv2r reviewed Aug 7, 2024

View reviewed changes

siv2r reviewed Aug 14, 2024

View reviewed changes

siv2r reviewed Aug 16, 2024

View reviewed changes

siv2r reviewed Aug 17, 2024

View reviewed changes

siv2r reviewed Aug 18, 2024

View reviewed changes

siv2r reviewed Aug 28, 2024

View reviewed changes

jesseposner added a commit to jesseposner/secp256k1-zkp that referenced this pull request Aug 28, 2024

Update RFC comment

64e8beb

Responds to: BlockstreamResearch#278 (comment)

jesseposner added a commit to jesseposner/secp256k1-zkp that referenced this pull request Aug 28, 2024

Update NonceGen

35f453d

Based on: BlockstreamResearch@206017d Responds to: BlockstreamResearch#278 (comment)

jesseposner added a commit to jesseposner/secp256k1-zkp that referenced this pull request Aug 29, 2024

Update group element helpers

9fcaf25

Based on: 57de68994ae18d20b0b6e1a9e4531c3d88b5ec81 and 3f9bb4d868a2a27caacdaf19b08ce91ce73c1fb4 Responds to: BlockstreamResearch#278 (comment)

jesseposner added a commit to jesseposner/secp256k1-zkp that referenced this pull request Aug 29, 2024

Update comment

ae39a3a

Responds to: BlockstreamResearch#278 (comment)

jesseposner added 7 commits September 9, 2024 18:52

frost trusted dealer: initialize project

6216645

This commit adds the foundational configuration and building scripts and an initial structure for the project.

frost trusted dealer: share generation

833d4d8

This commit adds trusted share generation, as well as share serialization and parsing.

frost trusted dealer: share verification

a64a904

This commit adds share verification, as well as computation of public verification shares.

frost trusted dealer: key tweaking

3787674

This commits add BIP-341 ("Taproot") and BIP-32 ("ordinary") public key tweaking.

frost trusted dealer: nonce generation

9fa15f5

This commits adds nonce generation, as well as serialization and parsing.

frost trusted dealer: nonce aggregation and adaptor signatures

af4dfaf

This commit adds nonce aggregation, as well as adaptor signatures.

frost trusted dealer: signature generation and aggregation

ab1bb83

This commit adds signature generation and aggregation, as well as partial signature serialization and parsing.

jesseposner force-pushed the frost-trusted-dealer branch 3 times, most recently from d53f97e to abb2ee3 Compare September 10, 2024 04:22

jesseposner added 3 commits September 9, 2024 21:53

frost trusted dealer: add example file

aea613b

This commit adds an example file to demonstrate how to use the module.

frost trusted dealer: add tests

fafc1f1

Add api tests, nonce tests, tweak tests, sha256 tag tests, and constant time tests.

frost trusted dealer: add documentation file

f41560c

This commit adds a documentation file with detailed instructions for how to use the module properly.

jesseposner force-pushed the frost-trusted-dealer branch from abb2ee3 to f41560c Compare September 10, 2024 04:54

jesseposner mentioned this pull request Sep 20, 2024

Add frost-secp256k1-tr crate (BIP340/BIP341) [moved] ZcashFoundation/frost#730

Merged

3 tasks

theStack reviewed Sep 22, 2024

View reviewed changes

theStack reviewed Sep 23, 2024

View reviewed changes

theStack and others added 8 commits October 4, 2024 13:38

frost trusted dealer: build: add CMake support

c139f91

Remove unused ret variable

298accf

Suggested by @theStack.

Rename secp256k1_frost_share to secp256k1_frost_secshare

640d61c

Suggested by theStack.

Revise nonce reuse warning

4b387ef

Suggested by @theStack.

Check for equality before computing indexhash

6aa7df2

As suggested by @theStack.

Simplify code

eb543cb

Co-authored-by: Sebastian Falbesoner <[email protected]>

Improve documentation

b8c671c

Co-authored-by: Sebastian Falbesoner <[email protected]>

		* start a new session to generate a new key, they must NOT REUSE their
		* respective seed32 again, but instead generate a new one. It is recommended

		* Each participant _must_ have a secure channel with the trusted dealer with
		* which they can transmit shares to each other.

		/* TODO: this doesn't have the same sidechannel resistance as the BIP340
		* nonce function because the seckey feeds directly into SHA. */

		static void secp256k1_point_save_ext(unsigned char data, secp256k1_ge ge);

		static void secp256k1_point_load_ext(secp256k1_ge ge, const unsigned char data);

	* pubkey: pointer to an x-only public key to verify with
	* agg_pk: pointer to an x-only public key to verify with

		/* Compute "effective" nonce rj = aggnonce[0] + baggnonce[1] /
		/* TODO: use multiexp to compute -sG + epubshare + aggnonce[0] + baggnonce[1] /

FROST Trusted Dealer #278

Are you sure you want to change the base?

FROST Trusted Dealer #278

Conversation

jesseposner commented Nov 23, 2023 • edited Loading

FROST Paper

FROST Signing BIP

Prior Work

real-or-random left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jesseposner Aug 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

real-or-random commented Apr 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

siv2r Aug 18, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

theStack left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jesseposner commented Nov 23, 2023 •

edited

Loading

jesseposner Aug 6, 2024 •

edited

Loading

real-or-random commented Apr 18, 2024 •

edited

Loading

siv2r Aug 14, 2024 •

edited

Loading

siv2r Aug 14, 2024 •

edited

Loading

siv2r Aug 14, 2024 •

edited

Loading

siv2r Aug 16, 2024 •

edited

Loading

siv2r Aug 17, 2024 •

edited

Loading

siv2r Aug 18, 2024 •

edited

Loading

siv2r Aug 18, 2024 •

edited

Loading