Share recovery and refreshing #26

piotr-roslaniec · 2023-01-04T10:07:28Z

Based on Simple threshold decryption #20
- Please review parent PR first
- Already rebased
Closes DKG Key Refreshing via Proactive secret sharing #3
Implement share refreshing and share recovery, or "PSS" (Proactive Secret Sharing)
- For the description of share refreshing, see this abbreviated algorithm
- For the description of share recovery, see section 4.2 of the PSS paper
How to review this PR:
- This PR adds three tests in tpke/src/lib.rs that contain three different PSS flows:
  - simple_threshold_decryption_with_share_refreshing_at_point - refreshes a key share knowing the evaluation point of a selected PSS participant
  - simple_threshold_decryption_with_share_recovery_at_point - recovers a key share with no knowledge of the evaluation point of a selected participant. Effectively, we generate a new key share for a new participant. Uses the same implementation as the previous test (section 4.2)
  - simple_threshold_decryption_with_share_refresh - refreshes all key shares for all existing participants. Uses a slightly different approach than the previous implementations
- You should start by reading the tests and inspecting function calls one by one
- Code specific to PSS is placed in tpke/src/refresh.rs
- Other changes are largely irrelevant (code refactoring, comments, todos, etc.)

tpke/src/lib.rs

tpke/src/refresh.rs

cygnusv · 2023-01-11T10:06:04Z

tpke/src/lib.rs

@@ -140,7 +136,7 @@ pub fn setup<E: PairingEngine>(
 // F_0 - The commitment to the constant term, and is the public key output Y from PVDKG
 // TODO: It seems like the rest of the F_i are not computed?
 let pubkey = g.mul(x);
- let privkey = h.mul(x);
+ let privkey = h.mul(x); // ek_i in PVSS?


Suggested change

let privkey = h.mul(x); // ek_i in PVSS?

let privkey = h.mul(x);

No, this is the private key share, which is different from the protocol-level "private key" (which can be very confusing). Let's call ek_i the (private) blinding key.

cygnusv · 2023-01-11T10:29:04Z

tpke/src/lib.rs

 checked_decrypt_with_shared_secret(&ciphertext, aad, &shared_secret)
 });
 assert!(result.is_err());
 }
+
+ #[test]
+ fn simple_threshold_decryption_with_share_refreshing_at_point() {


I think the name "share refresh" here is confusing. We need to agree on a naming convention. Let's assume N is the original number of shares, and t is the threshold. There are 2 different types of share calculation protocols, used in 3 different ways:

Ñ parties (where t <= Ñ <= N) jointly execute a "share refresh" or "share renewal" algorithm, and the output is M new shares (with M <= Ñ), with each of the M new shares substituting the original share (i.e., the original share is deleted). I personally like "share refresh" but the original paper calls it "share renewal" (also fine).

Ñ parties (where t <= Ñ <= N) jointly execute a "share recovery" algorithm, and the output is 1 new share. There are 2 potential variants here:
2.1. The new share is intended to restore a previously existing share, e.g., due to loss or corruption. It could also be used to on-board a new participant but reusing a previously existing share (sounds like a bad idea, though)
2.2. The new share is independent from the previously existing shares. We can use this to on-board a new participant into an existing cohort.

In this test, you're actually doing 2.1, but the name "share refresh" is confusing to me. Let's settle in a convention for naming algorithms 1, 2.1 and 2.2 and use it consistently.

cygnusv · 2023-01-11T10:30:21Z

tpke/src/refresh.rs

+ d_i
+}
+
+fn evaluate_polynomial<E: PairingEngine>(


Maybe there's an arkworks method for this.

looks like there is https://github.com/arkworks-rs/algebra/tree/master/poly

cygnusv · 2023-01-11T10:31:15Z

tpke/src/refresh.rs

+ let i = p.index;
+ let x_i = p.public_decryption_contexts[i].domain;
+ let eval = evaluate_polynomial::<E>(coeffs, &x_i);
+ let h_g2 = E::G2Projective::from(p.h);


This could be taken outside of the loop, or even moved to a public context, since it's just the H generator in projective representation.

In tpke, public context corresponds to variables shared with other participants, and since they already have h there is no reason to put it there.

The different structs in tpke are going to be refactored so that should bring a bit more clarity.

cygnusv · 2023-01-11T10:39:21Z

tpke/src/lib.rs

@@ -269,6 +265,7 @@ pub fn setup_simple<E: PairingEngine>(
 g,
 g_inv: E::G1Prepared::from(-g),
 h_inv: E::G2Prepared::from(-h),
+ h, // TODO: Remove this sensitive data here


What sensitive data?

It's a left-over TODO. h is just a G2 generator, so it's not sensitive. I didn't know any better when I wrote it, sorry about the confusion.

cygnusv · 2023-01-11T10:48:11Z

tpke/src/lib.rs

+ p.public_decryption_contexts.pop();
+ }
+
+ // Refresh the share


See comment above wrt to naming convention. The method here is called share recovery but the comment here says refresh.

cygnusv · 2023-01-11T10:51:03Z

tpke/src/lib.rs

+ let recovered_key_share = PrivateKeyShare {
+ private_key_shares: vec![y_r.into_affine()],
+ };
+


We don't need to create decryption shares and encryption/decryption. We can simply reconstruct the original secret before and after. To do so, we just need to get the context.private_key_share elements and combine them with the proper lagrange coefficients.

cygnusv · 2023-01-11T10:51:52Z

tpke/src/lib.rs

+ make_decryption_share(&private_share, &ciphertext)
+ })
+ .collect();
+


Same as above. After the share refreshing algorithm, the shared secret should remain the same.

cygnusv · 2023-01-11T10:54:12Z

tpke/src/lib.rs

+ .collect::<Vec<_>>();
+ let lagrange = prepare_combine_simple::<E>(shares_x);
+
+ let shared_secret =


This name is confusing. The ferveo paper call this ephemeral shared secret, but I think the word "shared" is misleading and doesn't add anything. Let's rename this to ephemeral secret.

This is important to avoid confusion with the real shared secret (i.e. the distributed secret after the DKG protocol)

cygnusv · 2023-01-11T10:55:18Z

tpke/src/refresh.rs

+ let i = p.index;
+ let mut new_y = E::G2Projective::from(
+ p.private_key_share.private_key_shares[0], // y_i
+ );


Why they need to be converted into Projective form?

In arkworks, Projective form is preferred since it "is generally more efficient for arithmetic". The PrivateKeyShares are G2Affine and so we convert to it later on.

piotr-roslaniec · 2023-01-12T14:18:18Z

@theref @cygnusv I've addressed your comments, I just need a thumbs up and we can merge this PR.

Co-authored-by: piotr-roslaniec <[email protected]>

piotr-roslaniec mentioned this pull request Jan 4, 2023

Share recovery #21

Closed

piotr-roslaniec marked this pull request as ready for review January 4, 2023 10:34

piotr-roslaniec added the enhancement New feature or request label Jan 4, 2023

piotr-roslaniec mentioned this pull request Jan 4, 2023

Simple threshold decryption #20

Merged

piotr-roslaniec assigned cygnusv and theref Jan 4, 2023

piotr-roslaniec mentioned this pull request Jan 9, 2023

WIP: Add testing to Ferveo create #29

Closed

arjunhassard mentioned this pull request Jan 9, 2023

Is Ferveo viable for our MVP? #76

Closed

6 tasks

piotr-roslaniec requested review from cygnusv and theref January 10, 2023 16:12

piotr-roslaniec unassigned cygnusv and theref Jan 10, 2023

theref reviewed Jan 11, 2023

View reviewed changes

tpke/src/lib.rs Show resolved Hide resolved

tpke/src/refresh.rs Show resolved Hide resolved

tpke/src/refresh.rs Outdated Show resolved Hide resolved

cygnusv reviewed Jan 11, 2023

View reviewed changes

piotr-roslaniec force-pushed the share-recovery branch from dcc095d to 3c6a9a2 Compare January 11, 2023 13:39

piotr-roslaniec changed the base branch from simple-decryption to main January 11, 2023 14:47

piotr-roslaniec added 11 commits January 11, 2023 15:47

initial work on simple threshold decryption

3d0c13b

wip

81870af

failing to create a proper polynomial for recovery

2575edd

fix after rebase

c0df26e

refreshing initial pass

1697924

share refreshing

e4e59c8

fix clippy warnings

2327378

fix after rebase

7d5ecd9

add comments after initial review

5456c42

apply pr suggestions

48732e7

fix after rebase

989415a

piotr-roslaniec force-pushed the share-recovery branch from 3c6a9a2 to 989415a Compare January 11, 2023 14:54

cygnusv mentioned this pull request Jan 12, 2023

Cohort Refresh – research (PSS) & product implications + validation #70

Open

theref approved these changes Jan 12, 2023

View reviewed changes

theref and others added 4 commits January 13, 2023 10:07

Use arkworks for polynomails and benchmark relevant functions

92f6f55

Use debug_assert to make benchmarks more consistent

871fdf4

Co-authored-by: piotr-roslaniec <[email protected]>

Apply PR suggestions

d8d325c

Merge pull request #37 from theref/share-recovery

86a95f3

piotr-roslaniec merged commit 94de0a0 into main Jan 13, 2023

piotr-roslaniec deleted the share-recovery branch January 13, 2023 10:53

arjunhassard mentioned this pull request Jan 22, 2023

Share replacement procedures & naming conventions, based on user/staker actions & application logic #43

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Share recovery and refreshing #26

Share recovery and refreshing #26

piotr-roslaniec commented Jan 4, 2023 •

edited

Loading

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

theref Jan 11, 2023

cygnusv Jan 11, 2023

piotr-roslaniec Jan 11, 2023

cygnusv Jan 11, 2023

piotr-roslaniec Jan 11, 2023 •

edited

Loading

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

cygnusv Jan 11, 2023

piotr-roslaniec Jan 11, 2023

piotr-roslaniec commented Jan 12, 2023

	let privkey = h.mul(x); // ek_i in PVSS?
	let privkey = h.mul(x);

Share recovery and refreshing #26

Share recovery and refreshing #26

Conversation

piotr-roslaniec commented Jan 4, 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-roslaniec Jan 11, 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piotr-roslaniec commented Jan 12, 2023

piotr-roslaniec commented Jan 4, 2023 •

edited

Loading

piotr-roslaniec Jan 11, 2023 •

edited

Loading