[llfourn] Rapid fire comments #1

LLFourn · 2023-10-24T06:47:09Z

Here's my first run through.

Nice work at separating the protocol into two. One that has an existing secure authenticated channel and one that doesn't. I made the flow chart below to try and understand what the choices are. It doesn't include the "cerifying network based protocol" idea yet:

I'm not sure if that diagram is the best way to slice it yet. It would be cool if we could make it modular and could figure out which one to use by asking a few questions.

This PR is obviously not meant to be merged but just to discuss a few topics and turn those that need action or further discussion into issues.

jonasnick

Thanks a lot for your feedback! I will continue to address it.

jonasnick · 2023-10-24T16:35:49Z

README.md

@@ -15,13 +15,19 @@ To instantiate a DKG there are many possible schemes which differ by the guarant
 Since DKGs are difficult to implement correctly in practice, this document describes DKGs that are relatively *simple*, namely SimplPedPop and SecPedPop.
 However, the DKG can be swapped out for another one if desired.

+<!-- Can it though? I understood the claim of the "practical" paper was that the keygen and signing must be proved secure together. Is there some way of checking whether a DKG can be replaced with another. Is there some functionality we can simulate or a game we can reduce to? -->


Changed the sentence to

However, the DKG can be swapped out for a different one provided it is proven to be secure when used in FROST.

But it's a good question. Why are the modifications we make to SimplPedPop compared to the paper secure?

jonasnick · 2023-10-24T18:18:30Z

README.md

 The DKG outputs the shared public key and a secret share for each signer.
 It is extremely important that both outputs are securely backed up because losing the share will render the signer incapable of producing signatures.
 In order to reduce the chance of losing the backup, it is possible to encrypt the backup and send it to every other signer.
 If a signer loses the local backup, as long as there's at least one other signer that cooperates and sends back the encrypted backup, the signer can restore (see also [repairable threshold signatures](https://github.com/chelseakomlo/talks/blob/master/2019-combinatorial-schemes/A_Survey_and_Refinement_of_Repairable_Threshold_Schemes.pdf).

+<!-- But then one must back up the deryption key? I think we should clear this up by explaining what your options are in "backup and recover section". This is an option where you have a long lived secret you can encrypt to. The other solution that is always available to you is to use MPC to recover the share with a threshold of parties. This also allows issuing a new share i.e. enrollment. Not suggesting we should specify that here  but for our project at least this is a more appropriate solution. -->


Yes, you must back up the decryption key. But at least that one can be derived from some 24 words.

Good idea to add a dedicated "backup and recover" section. I did that and moved the sentence over there, mentioned the encryption key and the MPC method (although I don't know the specifics of how this would work).

MPC in this context I just mean something like the "repair algorithm" scheme on page 18 on the wonderful slides above i.e. each party splits up their share to other parties and then you do some linear computation on them. Here we Lagrange interpolate and evaluate at a new point on the polynomial to produce a new share which can all be done with additions a multiplication by public scalar.

Ok I actually skimmed the slides now ;) This is pretty useful indeed; I updated the section.

How does the repairing user know that they actually have the right share? Is this it the same share as before? If so, maybe the cert can be reused?

Hmm maybe you can create a cert for it in the scheme you gave but you'd have to restrict the cert to just the public polynomial and your index in it because the artifacts from this protocol are a bit different to the keygen (e.g. no PoPs).

I'd say you convince the new/repaired user of the t public shares of the parties who will create the new share somehow. From that you can Lagrange interpolate the implied public polynomial and from there you can verify that the image of your secret share matches the public polynomial evaluated at your index.

By the way, don't you need a long term secret also for Enrolment RTS, in particular to authorize the enrolment? Without it, anyone could ask for a share.

Interesting point. I actually handn't thought about this workflow even in our context too much yet. To identify the t parties providing input, the secret shares themselves are a natural choice. You can assign the image of the secret share as the public encryption key to create secure channel in the RTS. I am brushing aside composability issues here which would need to be analyzed a bit (intuitively it should be fine).

For the receiver I guess you just have to verify their public key out of band somehow.

A safe way to do it would be to have a session string that consists of the [t share images + indices, index + public key of the receiver] which all parties (including the intended receiver) must agree on before starting the protocol. How you verify that all parties have the same string before starting is context specific (like keygen except you must verify this before starting rather than after!).

jonasnick · 2023-10-24T18:29:36Z

README.md

 Once the DKG concludes successfully, it is recommended to rule out basic mistakes in the setup by having all signers create a FROST signature for some test message.

+<!-- Nice idea. I'd soften the recommendation to "Applications should consider..".  -->


jonasnick · 2023-10-27T09:43:48Z

README.md

@@ -83,7 +91,7 @@ def simplpedpop_finalize(ids, my_id, vss_commits, shares, eta = ()):
            throw BadParticipant(ids[i])
        if not verify_sig(vss_commits[i].sig, vss_commits[i][0], "")
            throw BadParticipant(ids[i])
-    eta += (sig, vss_commit[i])
+        eta += (sig, vss_commit[i])


jonasnick · 2023-10-27T09:44:06Z

README.md

-The public keys are set to each other.
+The public keys are sent to each other.


jonasnick · 2023-10-27T13:58:03Z

README.md

@@ -32,6 +38,8 @@ Without the Algebraic Group Model, section 4](https://eprint.iacr.org/2023/899.p
 - Very rudimentary ability to identify misbehaving signers in some situations.
 - The proof-of-knowledge in the setup does not commit to the prover's id. This is slightly simpler because it doesn't require the setup algorithm to know take the id as input.

+<!-- This is indeed what we do atm but there's a good reason to using small integer indicies: You can ask a user to etch a number onto a 24 seed word backup plate. Also something like BIP93 for when you can backup a short bech32 string. Like bip93 we'd wanna keep the index to ≤ 2⁵ -->


Why would you need to back up the ID? Is this for the enrolment scheme? And if you have the ability to back up seed words, couldn't you derive the ID from the seed? The ID can even be fixed across multiple threshold setups, the index cannot, I think.

As real-or-random pointed out to me in private conversation, you need the ID - your own and those of the other signers - for signing. The current writeup does not forbid using low-entropy IDs such as indices.

Are we talking about seed words that back up your secret share? You certainly can't derive your ID from those.

No, the scenario I had mainly considered is existing wallets integrating threshold signatures. They support single signatures and typically have a seed backup. Is your scenario is pure threshold wallets without a backed up master key?

I see SimplPedPop has since been updated to not take IDs as input

Is your scenario is pure threshold wallets without a backed up master key?

Yes. While we do have a key on each device for our secure channel and device "pairing", we were looking to avoid using these keys for device indexes and needing to back them up

jonasnick

Had a brief look at the diagram in the OP; two comments:

The DKG writeup does not have accountability. Our idea was to keep the protocol simple and accountability seems hard. E.g., the "Certifying network-based protocol" does not have accountability in case a signer equivocated. Maybe there's a simple way to add accountability, but it seems like it would require consensus.
"verify session hash out-of-band" or "verify session hash p2p": It's not exactly clear to me what you mean by session hash. If you mean the signatures and vss_commitments, they are checked in Eq in both cases.

jonasnick · 2023-10-30T20:33:54Z

notes.md

 - Do we need to include the signature in the vss_hash? Probably not, but depending on how the rest is set up, it may not hurt.
 - Should the scheme support deterministic key derivation?
   - Not sure if that's actually that useful. And it only works as long as the code does not change, which we may not want to guarantee.
+   <!-- After a lot of thought on this: no it shouldn't. Everything can reproduced with a threshold of shares via MPC. Polynomials should use runtime randomness and deleted after share generation. -->


Can you explain some of your thought process? Deterministic seed derivation may allow backups that only rely on a single cooperating signer instead of a threshold.

I think I didn't interpret what you said properly. You shouldn't use deterministic derivation to derive your input polynomial for they key generation is what I meant. I am not certain what key you are referring to that we should generate deterministically?

You shouldn't use deterministic derivation to derive your input polynomial for they key generation is what I meant.

My question is why you concluded that you shouldn't do that.

Because there is little value in reproducing the secret polynomial at a later time. The polynomial can only help you recover if you have n-of-n polynomials. But this is strictly worse than recovery schemes that just require t-of-n.

Agree backing up methods described in dkg and repairing make sense for our purposes and more generally.

allow backups that only rely on a single cooperating signer instead of a threshold

Couldn't it at this point be easier to encrypt one's secret share to oneself and sign under a key from the seed, and share this among other parties?

Perhaps other FROST users could want deterministic keygen if it allows them to lazily recover the key with all n preexisting seed phrases.. Or even use a single seed in a number of DKGs, all with this lazy backup method.

edit: ah catching up on https://github.com/jonasnick/bip-frost-dkg/issues/6

jonasnick · 2023-10-30T20:37:14Z

README.md

@@ -32,6 +38,8 @@ Without the Algebraic Group Model, section 4](https://eprint.iacr.org/2023/899.p
 - Very rudimentary ability to identify misbehaving signers in some situations.
 - The proof-of-knowledge in the setup does not commit to the prover's id. This is slightly simpler because it doesn't require the setup algorithm to know take the id as input.

+<!-- This is indeed what we do atm but there's a good reason to using small integer indicies: You can ask a user to etch a number onto a 24 seed word backup plate. Also something like BIP93 for when you can backup a short bech32 string. Like bip93 we'd wanna keep the index to ≤ 2⁵ -->


As real-or-random pointed out to me in private conversation, you need the ID - your own and those of the other signers - for signing. The current writeup does not forbid using low-entropy IDs such as indices.

LLFourn · 2024-08-07T01:13:04Z

stale

[llfourn] Rapid fire comments

6fd435c

LLFourn force-pushed the llfourn-review branch from 9efd62c to 6fd435c Compare October 24, 2023 06:50

jonasnick reviewed Oct 24, 2023

View reviewed changes

jonasnick reviewed Oct 27, 2023

View reviewed changes

README.md

Comment on lines -107 to +115

The public keys are set to each other.

The public keys are sent to each other.

Copy link

Collaborator

jonasnick Oct 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

jonasnick reviewed Oct 30, 2023

View reviewed changes

real-or-random force-pushed the master branch from 3088785 to e169bf0 Compare March 6, 2024 15:45

real-or-random force-pushed the master branch 2 times, most recently from 665ef38 to 94fba6b Compare March 15, 2024 22:37

real-or-random force-pushed the master branch from b3cfdb4 to 62a028f Compare May 24, 2024 10:23

real-or-random force-pushed the master branch 6 times, most recently from ad7ee6d to 82ae3c6 Compare July 4, 2024 21:23

real-or-random force-pushed the master branch 3 times, most recently from e536a4d to c944f66 Compare July 8, 2024 19:36

LLFourn closed this Aug 7, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[llfourn] Rapid fire comments #1

[llfourn] Rapid fire comments #1

LLFourn commented Oct 24, 2023 •

edited

Loading

jonasnick left a comment

jonasnick Oct 24, 2023

jonasnick Oct 24, 2023

LLFourn Oct 25, 2023

jonasnick Oct 25, 2023

LLFourn Oct 26, 2023

jonasnick Oct 27, 2023 •

edited

Loading

LLFourn Oct 30, 2023 •

edited

Loading

jonasnick Oct 24, 2023

jonasnick Oct 27, 2023

jonasnick Oct 27, 2023

jonasnick Oct 27, 2023

jonasnick Oct 30, 2023 •

edited

Loading

LLFourn Oct 31, 2023

jonasnick Oct 31, 2023

nickfarrow Nov 19, 2023

jonasnick left a comment

jonasnick Oct 30, 2023

LLFourn Oct 31, 2023 •

edited

Loading

jonasnick Oct 31, 2023

LLFourn Oct 31, 2023

nickfarrow Nov 19, 2023 •

edited

Loading

jonasnick Oct 30, 2023 •

edited

Loading

LLFourn commented Aug 7, 2024

		Once the DKG concludes successfully, it is recommended to rule out basic mistakes in the setup by having all signers create a FROST signature for some test message.

		<!-- Nice idea. I'd soften the recommendation to "Applications should consider..". -->

		The public keys are set to each other.
		The public keys are sent to each other.

[llfourn] Rapid fire comments #1

[llfourn] Rapid fire comments #1

Conversation

LLFourn commented Oct 24, 2023 • edited Loading

jonasnick 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

jonasnick Oct 27, 2023 • edited Loading

Choose a reason for hiding this comment

LLFourn Oct 30, 2023 • 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

jonasnick Oct 30, 2023 • 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

jonasnick left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LLFourn Oct 31, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nickfarrow Nov 19, 2023 • edited Loading

Choose a reason for hiding this comment

jonasnick Oct 30, 2023 • edited Loading

Choose a reason for hiding this comment

LLFourn commented Aug 7, 2024

LLFourn commented Oct 24, 2023 •

edited

Loading

jonasnick Oct 27, 2023 •

edited

Loading

LLFourn Oct 30, 2023 •

edited

Loading

jonasnick Oct 30, 2023 •

edited

Loading

LLFourn Oct 31, 2023 •

edited

Loading

nickfarrow Nov 19, 2023 •

edited

Loading

jonasnick Oct 30, 2023 •

edited

Loading