chloethedev.eth
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Note Insights New
    • Engagement control
    • Make a copy
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Note Insights Versions and GitHub Sync Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Engagement control Make a copy Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       Owned this note    Owned this note      
    Published Linked with GitHub
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    # Secret Leader Election ###### tags: `Tag(HashCloak - Validator Privacy)` Authors: Dan Boneh, Saba Eskandarian, Lucjan Hanzlik, and Nicola Greco3Single Paper: https://eprint.iacr.org/2020/025 Definitions: * PPT - probabilistic polynomial time ### Table of Contents [toc] :::info >Abstract: In a Single Secret Leader Election (SSLE), a group of participants aim to randomly choose exactly one leader from the group with the restriction that the identity of the leader will be known to the chosen leader and nobody else. At a later time, the elected leader should be able to publicly reveal her identity and prove that she has won the election. The election process itself should work properly even if many registered users are passive and do not send any messages. Among the many applications of SSLEs, their potential for enabling more efficient proof-of-stake based cryptocurrencies have recently received increased attention. >This paper formally defines SSLE schemes and presents three constructions that provide varying security and performance properties. First, as an existence argument, we show how to realize an ideal SSLE using indistinguishability obfuscation. Next, we show how to build SSLE from low-depth threshold fully homomorphic encryption (TFHE) via a construction which can be instantiated with a circuit of multiplicative depth as low as 10, for realistically-sized secret leader elections. Finally, we show a practical scheme relying on DDH that achieves a slightly relaxed notion of security but which boasts extremely lightweight computational requirements. ::: ## 1 Introduction Existing proposals for secret leader election work by electing a few potential leaders in expectation and describing a simple run-off procedure such that one of the potential leaders can be recognized as the absolute winner of the election after all potential leaders have revealed themselves. The possibility of several potential leaders, however, can lead to wasted effort and potentially even forks in the blockchain in case of attacks on the run-off procedure.This situation has led to a desire for a new approach to secret leader election that guarantees that one, and only one, leader obtains a valid proof that it won the election. ### 1.1 Our Contributions 1. SSLE from indistinguishability obfuscation. Our first and simplest solution from indistinguishability obfuscation [5, 27] serves to show the feasibility of constructing an SSLE scheme as we define it and gives an example of a scheme that demonstrates all the qualitative properties one could want from an SSLE scheme. 2. SSLE from threshold FHE. Next, we construct an SSLE scheme based on threshold FHE [11]. The core idea is for each user to post an encryption of a secret $s_i$ when they register to participate and use computation under the FHE with the public randomness as input to select one string $s_i$ from the registered set. 3. SSLE from DDH and shuffles. Our final and most lightweight construction assumes only the hardness of DDH in some group. Instead of encrypting each user’s string s*\i as we do with the FHE-based solution, we hide the link between each user and his or her $s_i$ by shuffling $s_i$ into the database of secrets at registration time. ## 3 Defining Single Secret Leader Election **SSLE requirements:** Informally, an SSLE scheme involves $N$ users $U_1$, . . . , $U_N$ with access to each other’s public keys, a shared public ledger, and an unbiased randomness beacon. This group of users needs to repeatedly select exactly one leader $U_{i*}$, such that only $U_{i*}$, knows who she is and other users remain oblivious to the leader’s identity, until she reveals herself. That is, each participant learns whether she is the leader and nothing else. The selected leader can provide a proof that she was selected. **The scheme must satisfy a number of properties:** 1. Uniqueness means that exactly one leader is chosen in each election; 2. Fairness means that each user has a $1/N$ probability of becoming the leader, and as long as there is at least one honest user, a set of malicious users cannot influence the result of an election; and 3. unpredictability means that an adversary who does not control the leader cannot learn which user has been elected. > Ultimately, an SSLE protocol should satisfy a robustness property requiring that a denial of service attack against an $α$ fraction of users succeeds in disrupting the election with probability at most $α$. This is the best-possible security because an attack against a random $α$ fraction of the network hits the randomly-chosen leader with probability $α$, and the election fails if the chosen leader is unable to perform its leadership role. ### 3.2 Formalizing SSLE Definitions We now formally define the syntax and security properties of SSLE: ![](https://i.imgur.com/tadroTP.png) ![](https://i.imgur.com/UqUAjOS.png) We now formalize our security definitions: * Uniqueness requires that exactly one participant in an election can prove that she is the elected leader. * Our definition allows an adversary to corrupt as many users as it wants and still requires that at most one leader be elected in any given election. * We do allow for zero leaders to be elected because if a corrupted participant is elected leader, it may choose not to announce that it is the leader. * We also allow the adversary to produce proofs of leadership after seeing honest parties’ messages to account for an attacker who will use this information to produce fake proofs. ![](https://i.imgur.com/jMz9LF8.png) ![](https://i.imgur.com/LcrnN2i.png) We define unpredictability with a security game where an adversary can control any number of participants in an election and, after participating in several elections, must guess which honest user won a challenge election: ![](https://i.imgur.com/R6Oa1uH.png) ![](https://i.imgur.com/AXhIz6a.png) If the adversary can manipulate an SSLE protocol so that it always controls the winner, our unpredictability definition becomes vacuous. We require fairness to protect against such an adversary. The key idea behind our definition of fairness is that a scheme is fair if the best the adversary can do to be elected is to actually win the election honestly: ![](https://i.imgur.com/ZiHOJ0S.png) ## 4 SSLE from Obfuscation In this section, we answer the question affirmitively by presenting an SSLE protocol built from indistinguishability obfuscation (iO) \[5,27\] that satisfies all the requirements set forth in Section 3, albeit with selective unpredictability and fairness * In this solution, a one-time distributed setup protocol will choose a puncturable PRF \[15, 17, 36\] key k and embed it in an obfuscated program. * The program, given a list of public keys, an index, and some public randomness, uses the PRF to choose one key from the list of public keys to be the winner and outputs a commitment to 0 or 1. * If the index matches the winning public key, it outputs a commitment to 1. * Otherwise, it outputs a commitment to 0. > Moreover, the randomness used in the commitment is encrypted to the public key of the input index as a second output. * In order to register to participate in this scheme, a user just needs to generate a key pair and publish the public key * In each round, users run the obfuscated program with the list of participating public keys, their own indexes, and randomness from a public randomness beacon. * After decrypting their respective commitment randomnesses, the leader will find a commitment to 1 whereas all other users will receive a zero. * To prove leadership, the leader publishes the randomness used to commit to the output it received. More precisely, the scheme would begin with a trusted setup phase in which, first, a random key k is chosen from K, the distribution of keys for a puncturable PRF. Let F be a puncturable PRF, (COM.com, COM.verify) a commitment scheme, and (PKE.Encrypt,PKE.Decrypt) a CPA-secure public-key encryption scheme. The output of the setup phase is an obfuscated circuit $\widetilde{P}$ ← O(P ) that is posted to the ledger, where O is an indistinguishability obfuscator and P implements the following function. P((pk$_{(),...,}pk_{n-1}$),i,n,R): ![](https://i.imgur.com/8pv3V1d.png) * For each election with n participants, user $U_i$ sets (c,ct) ← $\widetilde{P}$(($pk_1$, ...,pk),i,n,R) and run COM.verify(c,1,PKE.Dec(sk$_i$,ct)) with the output R of the randomness beacon to recover a bit 1 or 0. * By construction, all users will receive a 0 except the leader, who receives a 1. * Moreover, the choice of leader is determined by the 11 output of the PRF on the list of participant keys and the public randomness, ensuring fairness. * Uniqueness comes from the binding property of the commitment scheme. * Unpredictability comes from the security of the punctured PRF, commitment scheme, encryption scheme, and obfuscator, which together ensure that users can only read their own output from $\widetilde{P}$ . We formalize the protocol below: ![](https://i.imgur.com/hCEyvc5.png) **Extensions** The obfuscation-based approach outlined above can easily accommodate a power table that determines each user’s probability of election by taking an additional input T representing the power table and giving each user $U_i$ a range of values of w mod n for which they would be elected whose size corresponds to their stake. The scheme could also be extended to output multiple encryptions instead of only one in order to elect more than one leader in each election. ## 5 SSLE from TFHE This section shows how to build an SSLE scheme based on threshold fully homomorphic encryption (TFHE) for a shallow circuit. This scheme will require t users to post partial decryptions of a ciphertext in each election, for a threshold t chosen as a parameter to the scheme. However, we maintain resistance against disruption by using threshold encryption so that as long as any t of the participants remain online, the election will succeed. One caveat of this scheme compared to the previous scheme is a more expensive user registration process. * Setup requires a group of $\boldsymbol\ell$ = t users to set up a TFHE scheme and generate a TFHE encryption of a PRF key k. * When a user joins, she needs approval from t existing participants who can generate a new threshold decryption key for that user. * Additionally, users register by uploading a TFHE ciphertext containing a random secret k$_i$∈{0,1}$^λ$, which is appended to a vector of secrets. * To elect a leader, users (loosely speaking) generate randomness inside the TFHE and then use it to randomly select a value of $k_i$ from the vector of secrets. * The user whose secret is chosen knows she has been elected, but nobody else knows that the revealed secret is hers. * . To participate in future elections, she re-registers with a new secret k$^J_i$. To realize this scheme, we need to show, first, how to get secret randomness in the TFHE and, second, how to use it to select a leader. **Generating randomness inside the TFHE** One way to easily generate randomness inside the TFHE is to have many users upload encryptions of random bit vectors and then to xor together users’ contributions and use the result. This approach requires no FHE multiplications, but requires a great deal of communication. **Selecting a leader** > Once we have generated a TFHE ciphertext containing log N random bits, we can use them to select a leader. 1. First, we will expand the random bits to a vector of length N with only one randomly chosen entry set to 1 and all other entries set to 0. * We begin by expanding each random bit b into a vector (b, 1 − b), so that each vector has one 0 and one 1. 2. Then we pair off the vectors produced, take the outer products between them, and reinterpret the output matrices as longer vectors, resulting in vectors of length 4 which will still have 1 in exactly one index and zero elsewhere. We repeat this process until we are left with a single vector v of length N, which will be set to 1 at exactly one index and zero everywhere else. This requires only log N multiplications and has multiplicative depth log log N, making it extremely efficient (e.g. depth 4 for N = 2$^{16}$ participants). Having computed $v$ under the TFHE, we take the inner product between $v$ and $s$ to get the value $s_i$ which determines the leader. This step has a multiplicative depth of 1, bringing the total depth of the entire leader election circuit to as little as 10 for N = 2$^{16}$ participants. **Defending against duplication and modification attacks** The scheme as described thus far remains vulnerable to two attacks that we call duplication and modification attacks. * A duplication attack compromises uniqueness. Two malicious users who choose the same secret $k_i$ can both legitimately claim to be the winner of the election if $k_i$ is chosen as the winning key. * A modification attack targets unpredictability. A malicious user $U_j$registers by uploading a value of $s_j$ that corresponds to the plaintext of $s_j$ plus one for some honest user $U_i$ (and uploading a random value for $k_{jR}$). This ciphertext $s_j$ can easily be obtained because the encryption is homomorphic. Then if $U_j$ “wins” an election, the value $k_i$ + 1 will be revealed. * $U_j$ j cannot prove that he has won this election, but note that in the definition of unpredictability, malicious users are not required to prove they have won an election. * Later, if $U_i$ wins an election, the malicious user can recognize that that the decrypted value $k_i$ matches the one copied from $U_i$ and predict that $U_i$ is the winner before she reveals herself. We defend against this attack by having each user $U_i$ upload a proof of knowledge $\pi{_s}$ of the plaintext corresponding to $s_i$ at registration time, thus ruling out attackers that register by modifying another user’s secrets. ### 5.1 Construction > We now formalize the construction of our TFHE-Based SSLE. After describing the construction itself, we discuss some practical considerations related to the instantiation of the protocol and its applicability ot real use cases Our construction makes use of a subroutine v ← Expand(r ) that takes a random vector r ∈ $F^{logN}_2$ and returns the $r^{th}$ standard basis vector v ∈ $F^{N}_2$, that is zero in all positions except a 1 in the $r^{th}$ position. We show how to instantiate Expand with multiplicative depth log log N after presenting the main construction. ### 5.2 Practical Considerations **Adding users after setup** Our scheme, as written, requires the list of all users of the system to be known at the time TSSLE.Setup runs, but it can easily be extended to allow growth in the number of users after initial setup, so long as t users are available at setup time. **Maintaining security over time** The active parties can periodically refresh the TFHE key using a distributed key generation (DKG) protocol. The DKG protocol generates a new FHE key with new key shares every several elections, thereby making old key shares obsolete. All users must stop using the old TFHE public key every time the TFHE key changes, lest an attacker use an old TFHE secret key to learn the secrets corresponding to users who may be elected in future elections. **Unequal election probabilities** Users who have higher likelihood of being elected are simply allowed to run TSSLE.Register multiple times corresponding to their allotted likelihood of winning an election. The table T is public, so all users know how many times to allow each other to register. Extra registrations have no impact on the multiplicative depth of the $C_e$ circuit, meaning they do not cause ciphertexts to get larger except through a limited number of additional ciphertexts added to the state $\boldsymbol{st.}$ **PRF instantiation and optimization** > It is important to choose a PRF with low multiplicative depth. Fortunately, recent years have seen the development of a number of low-depth block ciphers optimized for the MPC and FHE settings, including MiMC \[1\], LowMC \[2\], Kreyvium \[19\], FLIP \[40\], and Rasta \[24\]. In order to ensure that it is impossible to compute the leader for a future election ahead of time, the next chunk of PRF-generated randomness could be xored with the plaintext randomness R for each election, ensuring that the exact value of the randomness for each election remains unknown until the randomness has become available. **Reducing on-chain costs** We can reduce the final storage costs for each election in a blockchain usecase by making a trade-off where we increase communication and computation for each election. Instead of publicly posting and perpetually storing partial decryptions of the final threshold FHE ciphertext, users can communicate the decryptions to each other off-chain. When the leader reveals herself, she posts a short proof that the partial decryptions communicated during the election successfully decrypted her secret. ## 6 SSLE from DDH and Shuffling This scheme uses only the simplest of cryptographic tools and exhibits costs satisfactory for deployment in practical systems today. In return, it achieves weaker security properties than the preceding constructions. As a step toward our actual scheme, we will consider a simplification that incurs more communication and computation. **A high-communication scheme** In this scheme, the setup operation initializes an empty list l on a public ledger, effectively requiring users to do nothing at all. Registration will involve a user choosing a secret value $k_i$ ∈ $Z_q$ for some λ-bit prime q, uploading a special commitment to $k_i$ to the list, and shuffling/re-randomizing all elements of l. > Moreover, we require each user who shuffles l to post a NIZK proof that they have honestly shuffled l. To elect a leader, the output of a randomness beacon, R, is used to select a row from l. The user to whom the chosen row belongs reveals her commitment as proof of leadership and re registers with a new secret for future rounds. A user can leave the pool of participants by revealing its row so it can be excluded from future elections. In order for this scheme to work, we need a commitment scheme for random strings that can be rerandomized such that the new version is unlinkable to any previous version, yet the owner of the secret $k_i$ can identify a re-randomized commitment as her own after it has been shuffled. To reveal, a user outputs $k_i$ , and the commitment ($u$, $v$) can be verified by checking that $v$ = $u$ $k_i$ . To rerandomize a commitment, anyone can compute Rerand(($u$,$v$), $r^{'}$) = ($u^{r'}$ , $v^{r'}$ ). **Reducing communication** As described, the high-communication scheme above requires each user who registers to compute a shuffle over $N$ list items, re-randomize each, and post the new list along with a proof of honest shuffling and re-randomization. We can reduce communication costs by shuffling new entries into only a part of the list $l$ instead of shuffling the entire list each time a new participant joins, resulting in a linear tradeoff between communication costs and security. **Improving the communication/security tradeoff** We can further improve the unpredictability of our scheme by, instead of deterministically allocating each user to a bucket, assigning new users to a bucket at random when they register. This prevents the adversary from corrupting a disproportionate number of users in one bucket, but introduces the possibility of buckets of different sizes. **Removing NIZKs** We can also remove the need for NIZK proofs that shuffles were carried out honestly, saving even more space and time. Since each shuffle only operates on $\sqrt{N}$ entries, users whose entries were included in a shuffle can check every shuffled entry, requiring only $\sqrt{N}$ exponentiations, to ensure that their entry still appears after the shuffle. **Defending against duplication attacks** It is possible for a malicious user to upload a commitment to a rerandomization of another user’s secret without knowing how to open the commitment, in hopes of disrupting fairness by increasing that user’s chances of winning the election. We have each user check new registrations to ensure that a new registrant has not uploaded a rerandomized commitment to that user’s own secret. #### Conclusion Efficient constructions for SSLE are an important tool in the blockchain space. This paper formally defines SSLE and constructs three SSLE schemes. Our protocols based on obfuscation, FHE, and DDH offer a range of tradeoffs between security and performance, with the last construction providing levels of security and performance that may satisfy practical requirements.

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully