# Verifiable Threshold Multi-Party Fully Homomorphic Encryption from Share Resharing
## 3 Module Construction
### Oracle Query  
The share resharing proposed in Section 3.2 requires each party to store a constant-sized state \(sk_{i}^{\prime}\) locally, and it must be aggregatable. During the key reconstruction process, each party can precompute \(\overset{\sim}{sk}_{i}\) and store it locally by running the RS.Receive algorithm after receiving \(\{sk_{j,i}\}_{j\in[N],j\
eq i}\) from other parties. After this, any subset of at least \(t\) parties in the set \(P\) can use the RS.Combine algorithm to compute the additive share of the secret key \(sk\), denoted as \(sk_{i}^{\prime}\). This \(sk_{i}^{\prime}\) will serve as the secret key share for threshold decryption in the final scheme. In dynamic participant settings, when new parties join the computation, the secret resharing process can be re-executed among all current participants to generate updated secret key shares. If some parties go offline or leave the computation after executing the RS.Receive algorithm, as long as the number of remaining online parties exceeds the threshold t, the decryption secret key can still be reconstructed by executing the RS.Combine algorithm, without affecting the correctness of the scheme.  
To accommodate dynamic settings where the set of participating parties may change across computation rounds or differ between key generation and decryption phases, we provide each party with an oracle query interface to determine the set of currently online parties. The oracle determines the online parties via a round of broadcast communication.  
We use \(P_{online}\gets Q(Env)\) to denote querying the set of online parties in the current environment, and \(P_{online}\subseteq P\) to denote the query result given by the oracle. As long as the set of online parties is valid, i.e., \(|P_{online}|\geq t\), it will be broadcast to all parties as a common result; otherwise, it will return \(\bot\). Note that different stages may involve different parties, requiring fresh queries at each stage. However, after the broadcast query, some parties may crash or go offline, causing the secret key shares at the threshold decryption stage to fall short of the threshold requirement, and thus leading to decryption failure. Therefore, we refer to solutions used in practical applications. The decryption protocol sets a maximum time limit for all parties to return partial decryption results, and stipulates that parties handle the situation as follows after timeout, to ensure successful decryption:  
1. Set a timeout for each party, marking the parties that fail to return partial decryption results within the threshold decryption stage as the failed set \(P_{fault}\).
2. Excluding the set \(P_{fault}\), re-execute the oracle query. If the number of remaining online parties does not meet the threshold \(t\), return \(\bot\); otherwise, re-execute the threshold decryption.
3. Before re-executing the threshold decryption stage, add an encryption of 0 to the resulting ciphertext to ensure the security of the decryption process. This prevents the re-decryption from leaking information about the secret key \(sk\) while not changing the decryption result.