Pith. sign in

REVIEW 2 major objections 4 minor 85 references

Towards the ideals of Self-Recovery and Metadata Privacy in Social Vault Recovery

T0 review · 2 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Apollo is the first social key recovery framework that lets a user recover her vault after device loss without remembering any recovery metadata, while an adversary who sees every distributed packet still cannot tell trustees from…

desk verdict A clever recovery protocol with a real scalability fix, but the security headline rests on unvalidated simulation parameters and the 'self-recovery' claim overreaches on RM1/RM2. read the letter →

arxiv 2507.19484 v1 pith:TYQLAYG7 submitted 2025-05-14 cs.CR cs.HC

Shailesh Mishra , Simone Colombo , Pasindu Tennage , Martin Burkhart , Bryan Ford This is my paper · ORCID
classification cs.CRcs.HC
keywords socialkeyrecoveryself-recoverymetadataprivacymulti-layeredsecretsharinganonymitysetvaultindistinguishablepackets
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that vault recovery can be both self-recovering and metadata-private: a user who loses her device and forgets who holds her recovery shares can still get her key back by reconnecting with people she knows, while an adversary who obtains the entire distribution of backup packets cannot tell which contacts are trustees. To do this, Apollo gives every contact in the address book an indistinguishable packet—key shares for trustees, random data for non-trustees—so the trustees sit inside an anonymity set spanning the whole address book. A two-layer secret sharing scheme, MLSS, keeps the recovery computation from blowing up combinatorially. If the claims hold, existing social recovery's implicit memory burden—the trustee list, threshold, and procedure—disappears, and malicious recovery becomes unlikely under the paper's stated assumptions.

What carries the argument

The central object is an indistinguishable packet: an array of blobs that are either polynomial secret shares carrying salted-hash tags for successful recovery, or random look-alike shares held by non-trustees. The second mechanism is multi-layered secret sharing (MLSS): the vault key is split into additive subsecrets, each subsecret is then split with a small fixed absolute threshold α, and each contact holds the same number of shares, preserving indistinguishability. This lets the recovery algorithm check only combinations of α shares per subsecret and test the reconstructed subsecrets against salted hashes, avoiding the exponential growth of trying all thresholds in a single-layer design while keeping trustees and non-trustees indistinguishable.

What would settle it

A field measurement in which a real attacker, knowing only the public packet distribution and social graph, successfully obtains blobs from more than 75% of sampled contacts while being reported in fewer than about 5% of attempts would contradict the threat model; under the paper's Fig. 12 that parameter regime yields roughly 88% malicious-recovery probability. Alternatively, an attacker who compromises the devices of a threshold's worth of contacts wholesale recovers the key directly, bypassing Apollo's anonymity-set defense.

Watch

Extended reading notes

Core claim

This paper answers affirmatively the question of whether a user can recover a vault even if she forgets all recovery metadata while the metadata stays private. It defines recovery metadata as vault existence, recovery procedure, trustee details, and threshold, and argues that existing schemes force users to remember at least some of these. Apollo distributes a packet to every contact in the user's address book, with key shares to trustees and random chaff to non-trustees, in an indistinguishable form; because packets are identical, trustees are concealed in an anonymity set, and the user only needs to reconnect with people she knows. An adversary must guess whom to extort, faces probabilistic resistance per attempt, and risks being reported. The paper's simulations report malicious-recovery probabilities between 0.005% and 1.8% under its stated threat model, and the multi-layered secret sharing scheme keeps the brute-force search over share combinations practical rather than exponential.

Load-bearing premise

The security claim rests on the threat model where each extortion attempt on a contact succeeds with probability at most about 75% and carries a reporting risk that halts the attack; if an adversary can coerce any contact cheaply and almost never gets reported, the anonymity set only slows her down rather than stopping her.

Editorial extensions

If this is right

  • A user can recover her vault even with high memory error; the recovery probability tends to 1 as she keeps reconnecting with her social circle.
  • An adversary who obtains every distributed packet cannot identify trustees from packet contents, so the effective anonymity set is the user's entire address book.
  • MLSS keeps recovery computation practical: at 30 reconnections Apollo takes about 0.12 seconds versus more than 25 hours for the single-layered approach, and it can handle 850 reconnections in about 155 seconds.
  • Under the paper's threat model, malicious recovery success ranges from 0.005% to 1.8% for phishing-style adversaries, and reporting risk is what mainly stops stronger adversaries.
  • The user no longer needs to remember the recovery procedure, the threshold, or the trustee list, replacing them with a vague recollection of her social ties.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same design pattern could generalize beyond vaults: any service that must survive the loss of both a secret and its metadata could distribute indistinguishable shares across a user's existing social graph, turning 'remember the answer' into 'reconnect with people.'
  • If reporting probabilities are materially lower than 5% in high-coercion settings, Apollo's defense degrades to the anonymity set alone; the paper's own figure of 88% malicious-recovery success for an unreported 75%-extortion adversary marks that boundary.
  • MLSS makes the effective recovery threshold probabilistic: a user may need to contact more than the τ-fraction of trustees she expects, and the appendix's T-Apollo and H-Apollo variants trade recovery effort against adversary success, so choosing among them is a policy decision rather than a purely technical one.
  • A natural testable extension would measure real reporting behavior and per-contact extortion resistance, converting the simulation parameters k_obt and p_rpt from plausible assumptions into calibrated inputs.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper formalizes the notion of recovery metadata in social key recovery, defines the two ideals of self-recovery and recovery metadata privacy, and proposes Apollo, a protocol that distributes indistinguishable packets across a user's entire address book so that trustees are hidden among non-trustees. A user recovers her vault key by reconnecting with contacts and collecting enough shares, while an adversary trying to extort shares must locate and coerce trustees without being able to distinguish relevant from random data. To make recovery computationally practical, Apollo introduces a multi-layered secret sharing (MLSS) scheme that fixes a small absolute threshold for share reconstruction and avoids the exponential blow-up of a single-layered strawman. The paper reports a Go prototype, measurements showing large latency reductions of MLSS over the strawman, and Monte Carlo simulations of user and adversary recovery probabilities under assumed memory-error, extortion-success, and reporting probabilities.

Significance. If the claims are supported, the paper makes a useful contribution: a taxonomy of recovery metadata, a concrete protocol that decouples recovery from remembering trustees and threshold, and a performance technique (MLSS) that makes an indistinguishability-based design scalable. The authors are explicit about several threat-model parameters and about leaving user-study validation to future work, which is honest and helps the reader interpret the empirical security numbers. However, the central claim that Apollo achieves full self-recovery is overstated with respect to the paper's own definition, and the headline security probabilities rest on unvalidated, load-bearing assumptions. These are correctable framing and evidence issues rather than fundamental flaws in the protocol's cryptographic core, so the work deserves a major revision rather than rejection.

major comments (2)
  1. [Sections 3.2, 5.2, and Table 1] The claim that Apollo achieves self-recovery, and specifically that it removes the need to remember RM1 (vault existence) and RM2 (recovery procedure), is not supported by the protocol description. The recovery flow in Section 5.2 begins with the user getting a new device and reconnecting with people she knows, and step 1 says the user's device queries a reconnected person's device for a packet. This presupposes that the user remembers that she has a vault and that she should run Apollo recovery. Trustee privacy (Section 3.3) explicitly keeps contacts oblivious of their trustee status, so contacts cannot prompt a user who has forgotten about the vault. Thus the design removes the need to remember trustees and threshold, but not the need to remember vault existence and the recovery procedure. The Abstract's unconditional 'eliminates the need to memorize recovery metadata' and Table 1's checkmarks for RM1 and RM2 overstate what Apollo delivers; the claims should be re-scoped or an explicit recovery-trigger mechanism should be added.
  2. [Sections 4.3, 6.6, and 7.2] The security headline that Apollo reduces malicious recovery probability to 0.005%–1.8% is a Monte Carlo output, not a demonstrated property, and it depends on assumed parameter values that the paper does not validate. The 25% extortion-success probability is taken from a phishing study, the 5% reporting probability is set as half of that study's reporting figure, and the memory-error values (40%/60%) are assumptions; Section 7.2 explicitly concedes that no precise values for k_err, k_obt, and p_rpt are provided and that validation requires future user studies. The load-bearing nature of these parameters is visible in Figure 12: when there is no reporting and extortion succeeds with probability 75%, the adversary recovers the key 88% of the time. Since unauthorized-access mitigation is a stated system goal and the abstract reports absolute numbers, the paper should either present these results explicitly as conditional on validated parameters, or provide a sensitivity analysis showing which parameter regimes actually support the claimed defense. As written, the security claim is not yet established.
minor comments (4)
  1. [Table 1] The table's symbol semantics are not defined in the caption or text; the reader cannot tell whether a checkmark means 'this metadata must be remembered' or 'this metadata is handled without memorization', and the existing-solution rows appear inconsistent with the prose in Section 3.1.
  2. [Figures 11 and 12] The y-axis labels appear as '10 6' and '10 1', which read as positive powers; the text and probabilities make clear that negative exponents are intended (e.g., 10^-6 for 0.005%). The exponent minus signs should be added.
  3. [Throughout] There are numerous typos and copy-paste errors, for example 'straighforward' (Section 5.3), 'enoughtrustees' (Section 5.4), 'here device(s)' (Section 5.5), 'Aneeds' (Appendix), and 'the user to choose the users to choose an adequate trustee set' (Section 3.3). A careful proofreading pass is needed.
  4. [Section 3.3] The reference to forgetting studies appears as '[19], [19], [39]' with [19] duplicated; one duplicate citation should be removed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: security and performance results are simulation/implementation outputs with external parameters; no fitted-input or self-citation chain.

full rationale

Apollo's derivation chain is self-contained and non-circular. The central security numbers (0.005%–1.8% malicious recovery, Figs. 11–12) are outputs of Monte Carlo simulations; the input parameters (25% extortion success, 5% reporting probability, 40%/60% trustee-selection error) are taken from an external phishing study [45] and explicitly flagged as needing future user studies in Section 7.2, not fitted to reproduce the outputs. The user-side recovery probabilities (Fig. 7) are likewise simulation outputs from a memory-error coin toss; claim C1 only asserts eventual recovery given enough reconnections, which follows from the threshold property. MLSS's latency gains are measured by implementing both the multi-layered and single-layered strawman algorithms and comparing CPU/wall-clock times (Sections 6.4–6.5), so the 1.1x–740kx numbers are not defined to equal the design choice. The only self-citation is CALYPSO [53] in related work, used to distinguish Apollo from blockchain-based recovery, not as load-bearing evidence. The self-recovery claim does rely on an assumption that the user remembers to reconnect and initiate Apollo (Section 5.2), which is an overreach relative to the RM1/RM2 definition in Section 3, but that is an internal-consistency concern, not a circular reduction: no quantity is fitted to itself, no prediction is constructed from its own target, and no theorem is imported from the authors' prior work. Therefore no circularity is present.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The protocol relies on standard cryptographic primitives and a set of behavioral assumptions about users, contacts, and adversaries. The behavioral assumptions (reconnection, extortion success, reporting) are the least supported and carry the security claims. No new physical or cryptographic entities are postulated.

free parameters (4)
  • k_err: ratio of adversary error in identifying trustees to user memory error = User 40% error, adversary 40% to 60% error
    Chosen for the simulations in Section 6.6; the paper says these percentages require a user study to validate (Section 7.2).
  • k_obt: ratio of user acquisition probability to adversary extortion probability = Extortion success 25% base, 50% and 75% for strong adversary
    Base value set from phishing study [45]; strong-adversary values are hypothetical extensions plotted in Fig. 12.
  • p_rpt: probability an extortion attempt gets reported = 5%
    Set to half the reporting probability in [45]; without reporting, the strong-adversary success rises to 88%.
  • System defaults: address book 150, trustees 20, tau=0.5, alpha=3, gamma=2, beta=6 = n=150, n_T=20, tau=0.5, alpha=3, gamma=2, beta=6
    Defaults chosen from literature (Dunbar's number, Pew ties) and from Fig. 10a showing rapid growth for alpha>3; they drive all simulation and performance results.
assumptions (6)
  • standard math Shamir's secret sharing is correct and secure under polynomial interpolation.
    Invoked in Sections 5.1 and 5.4 for generating key shares and subsecret shares.
  • standard math SHA-256 behaves as a random oracle, making real and random blobs indistinguishable.
    Invoked in Sections 5.3 and 5.4 to argue packet indistinguishability.
  • domain assumption A user can reconnect with enough of her social circle after device loss and will do so.
    Invoked in Sections 4.2 and 4.4; self-recovery depends on the user approaching contacts.
  • domain assumption Contacts' devices are responsive, store blobs, and do not tamper with the data.
    Invoked in Section 4.3; the paper excludes data-integrity attacks.
  • domain assumption An adversary's extortion succeeds with bounded probability and risks being reported, which halts the attack.
    Invoked in Section 4.3 and used throughout Section 6.6; the security percentages are conditional on this.
  • domain assumption The default parameters (n_T=20, n=150, tau=0.5, alpha=3, gamma=2) represent realistic users.
    Used in Section 6.3 for all simulations; not empirically validated in the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards the ideals of Self-Recovery and Metadata Privacy in Social Vault Recovery." pith.science (2026). https://pith.science/paper/TYQLAYG7

@misc{pith2026250719484,
  author       = {Pith},
  title        = {Pith review of: Towards the ideals of Self-Recovery and Metadata Privacy in Social Vault Recovery},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TYQLAYG7}},
  note         = {Machine review of arXiv:2507.19484}
}
read the original abstract

Social key recovery mechanisms enable users to recover their vaults with the help of trusted contacts, or trustees, avoiding the need for a single point of trust or memorizing complex strings. However, existing mechanisms overlook the memorability demands on users for recovery, such as the need to recall a threshold number of trustees. Therefore, we first formalize the notion of recovery metadata in the context of social key recovery, illustrating the tradeoff between easing the burden of memorizing the metadata and maintaining metadata privacy. We present Apollo, the first framework that addresses this tradeoff by distributing indistinguishable data within a user's social circle, where trustees hold relevant data and non-trustees store random data. Apollo eliminates the need to memorize recovery metadata since a user eventually gathers sufficient data from her social circle for recovery. Due to indistinguishability, Apollo protects metadata privacy by forming an anonymity set that hides the trustees among non-trustees. To make the anonymity set scalable, Apollo proposes a novel multi-layered secret sharing scheme that mitigates the overhead due to the random data distributed among non-trustees. Finally, we provide a prototype implementation of Apollo and report on its performance. Apollo reduces the chances of malicious recovery to between 0.005% and 1.8%, depending on the adversary's ability to compromise. The multi-layered design shows a latency reduction from 1.1x to 740kx compared to a single-layered approach, depending on the number of reconnections.

Figures

Figures reproduced from arXiv: 2507.19484 by the authors.

Figure 1
Figure 1. Overview of working of Apollo. that the number of possible combinations remains small and manageable, sidestepping the exponential growth issue. Thus, Apollo achieves scalability without compromising self-recovery or recovery metadata privacy. We implemented Apollo in Go [22] and evaluate the performance of the recovery. Apollo provides an exponential saving in the running time of the recovery algorithm, and we obse… view at source ↗
Figure 2
Figure 2. Key backup: figure does not include devices of contacts for clarity. [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Key recovery. tries combinations containing shares obtained from the most recent packet. The combinations contain both key as well as random shares, and the key is reconstructed after the user reconnects with enough trustees. Thus, Apollo enables key recovery without requiring the user to remember the recovery metadata. We next provide the details on the multi-layered secret sharing. As a warmup for Apollo’s multi-l… view at source ↗
Figures from the paper (18 more)
Figure 4
Figure 4. Figure 4: Structure of a blob in the single-layered approach. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Secret distribution structure. Multi-layered secret sharing (MLSS) addresses the scal￾ability issue of the single-layered approach. Unlike the single-layered approach, which uses only one layer of shares, MLSS employs two. Instead of backing up Shamir’s secret shares o…
Figure 6
Figure 6. Figure 6: Structure of a blob in MLSS; ss depicts the subsecret to which [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Impact of memory error: (a) variation of key recovery probability [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Computation time after every reconnection. [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 10
Figure 10. Figure 10: Total computation time: (a) variation with address book size; [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 9
Figure 9. Figure 9: Size of data distributed across the address book. [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]
Figure 11
Figure 11. Figure 11: Security of Apollo: Adv-40-25-5 depicts an adversary with 40% [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]
Figure 13
Figure 13. Figure 13: Non-recovery of key despite exceeding threshold since the [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 12
Figure 12. Figure 12: Security against a strong adversary; Adv-40-50-5 shows an [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]
Figure 14
Figure 14. Figure 14: Configuration of shares obtained to reconstruct the key with less [PITH_FULL_IMAGE:figures/full_fig_p018_14.png]
Figure 15
Figure 15. Figure 15: Configuration of shares obtained to reconstruct the key with less [PITH_FULL_IMAGE:figures/full_fig_p020_15.png]
Figure 16
Figure 16. Figure 16: Wallclock time: total recovery time. 0 100 200 300 400 500 600 700 800 No. of reconnections 0 5 10 15 20 25 30 35 40 Computation time per reconnection (in mins) Double-layered Single-layered [PITH_FULL_IMAGE:figures/full_fig_p022_16.png]
Figure 17
Figure 17. Figure 17: Wallclock time: time taken per reconnection. [PITH_FULL_IMAGE:figures/full_fig_p022_17.png]
Figure 18
Figure 18. Figure 18: Probability of secret recovery: for (a) and (b), dashed curves correspond to the single-layered approach for the solid curve; for (c) and (d), [PITH_FULL_IMAGE:figures/full_fig_p023_18.png]
Figure 19
Figure 19. Figure 19: Reduction in the no. of connections needed [PITH_FULL_IMAGE:figures/full_fig_p023_19.png]
Figure 20
Figure 20. Figure 20: Structure of a blob in Thresholded-MLSS design serves two main purposes in key recovery. Firstly, it increases the probability of key recovery after contacting ⌊τnT ⌋ people, thus ameliorating the issue of non-recovery in MLSS ( [PITH_FULL_IMAGE:figures/full_fig_p024…
Figure 21
Figure 21. Figure 21: Structure of a blob in Hinted-MLSS 5.4. Security Implications. With T-Apollo, U needs to reconstruct lesser subsecrets with the same number of people holding the shares as in the case of MLSS. Since one needs to obtain τS fraction of the total shares for reconstructin…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

85 extracted references · 79 canonical work pages

  1. [1]

    1Password

    1Password, “1Password.” https://1password.com/, 2025

    2025

  2. [2]

    Dashlane

    Dashlane, “Dashlane.” https://www.dashlane.com/, 2025

    2025

  3. [3]

    Bitwarden

    Bitwarden, “Bitwarden.” https://bitwarden.com/, 2025

    2025

  4. [4]

    Apple, “iCloud.” https://www.icloud.com/, 2024

    2024

  5. [5]

    OneDrive

    Microsoft, “OneDrive.” https://www.microsoft.com/en-us/microsoft- 365/onedrive/online-cloud-storage, 2024

    2024

  6. [6]

    Coinbase

    Coinbase, “Coinbase.” https://www.coinbase.com/en-gb/, 2024

    work page 2024

  7. [7]

    Metamask

    Metamask, “Metamask.” https://docs.metamask.io/, 2024

    work page 2024

  8. [8]

    Trezor Safe 5

    Trezor, “Trezor Safe 5.” https://trezor.io/trezor-safe-5, 2024

    work page 2024

Show all 85 references
  1. [9]

    Stefan Thomas: The Man Behind Bitcoin’s Lost Millions

    coinpaper, “Stefan Thomas: The Man Behind Bitcoin’s Lost Millions.” https://coinpaper.com/6899/stefan-thomas-the-man- behind-bitcoin-s-lost-millions, 2025

    2025

  2. [10]

    Man who lost $800 million bitcoin in landfill wants to buy the garbage dump

    CNN, “Man who lost $800 million bitcoin in landfill wants to buy the garbage dump.” https://edition.cnn.com/2025/02/14/uk/ james-howells-landfill-bitcoin-gbr-intl-scli/index.html, 2025

    2025

  3. [11]

    Why Password Managers Are Great Until You Lose Your Password

    CNET, “Why Password Managers Are Great Until You Lose Your Password.” https://www.cnet.com/tech/services-and-software/ password-managers-great-until-you-lose-access-world-password- day/, 2025

    2025

  4. [12]

    Keybase

    Keybase, “Keybase.” https://keybase.io/, 2025

    2025

  5. [13]

    Keeper, “Keeper.” https://www.keepersecurity.com/en GB/, 2025

    2025

  6. [14]

    Introducing free wallet recovery

    Argent, “Introducing free wallet recovery.” https://www.argent.xyz/ blog/off-chain-recovery/, 2021

    2021

  7. [15]

    Regain access to your loopring smart wallet or trans- fer the wallet to another device

    Loopring, “Regain access to your loopring smart wallet or trans- fer the wallet to another device.” https://docs-wallet.loopring.io/ troubleshooting/recovery, 2023

    2023

  8. [16]

    Hyperledger Indy SDK: Decentralized Key Manage- ment

    H. Indy, “Hyperledger Indy SDK: Decentralized Key Manage- ment.” https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/ docs/design/005-dkms/README.html, 2025

    2025

  9. [17]

    Secure your secrets with decentralized recovery

    DeRec Alliance, “Secure your secrets with decentralized recovery.” https://derecalliance.org/, 2023

    2023

  10. [18]

    A Social Wallet Scheme with Robust Private Key Recovery,

    A. Rathnavibhushana, T. Thamaranga, S. Kaveesha, and C. Gamage, “A Social Wallet Scheme with Robust Private Key Recovery,” in2023 IEEE 17th International Conference on Industrial and Information Systems (ICIIS), pp. 1–6, 2023

    2023

  11. [19]

    Replication and Analysis of Ebbinghaus’ Forgetting Curve,

    J. M. J. Murre and J. Dros, “Replication and Analysis of Ebbinghaus’ Forgetting Curve,”PLOS ONE, vol. 10, no. 7, p. e0120644, 2015

    2015

  12. [20]

    The need to belong: Desire for interpersonal attachments as a fundamental human motivation,

    R. F. Baumeister and M. R. Leary, “The need to belong: Desire for interpersonal attachments as a fundamental human motivation,” Psychological Bulletin, pp. 497–529, 1995

    1995

  13. [21]

    Social connection as a critical factor for mental and physical health: evidence, trends, challenges, and future implications,

    J. Holt-Lunstad, “Social connection as a critical factor for mental and physical health: evidence, trends, challenges, and future implications,” World Psychiatry, vol. 23, no. 3, pp. 312–332, 2024

    2024

  14. [22]

    The Go Programming Language,

    J. Meyerson, “The Go Programming Language,”IEEE Software, vol. 31, no. 5, pp. 104–104, 2014

    2014

  15. [23]

    Coercion-resistant elec- tronic elections,

    A. Juels, D. Catalano, and M. Jakobsson, “Coercion-resistant elec- tronic elections,” inProceedings of the 2005 ACM Workshop on Privacy in the Electronic Society, WPES ’05, (New York, NY , USA), p. 61–70, Association for Computing Machinery, 2005

    2005

  16. [24]

    V oteAgain: A scalable coercion-resistant voting system,

    W. Lueks, I. Querejeta-Azurmendi, and C. Troncoso, “V oteAgain: A scalable coercion-resistant voting system,” in29th USENIX Security Symposium (USENIX Security 20), pp. 1553–1570, USENIX Associ- ation, Aug. 2020

    2020

  17. [25]

    Revisiting Practical and Usable Coercion-Resistant Remote E-V oting,

    E. Estaji, T. Haines, K. Gjøsteen, P. B. Rønne, P. Y . A. Ryan, and N. Soroush, “Revisiting Practical and Usable Coercion-Resistant Remote E-V oting,” inElectronic Voting, (Cham), pp. 50–66, Springer International Publishing, 2020

    2020

  18. [26]

    On Practical Aspects of Coercion- Resistant Remote V oting Systems,

    K. Krips and J. Willemson, “On Practical Aspects of Coercion- Resistant Remote V oting Systems,” inElectronic Voting, (Cham), pp. 216–232, Springer International Publishing, 2019

    2019

  19. [27]

    Dropbox

    Dropbox, “Dropbox.” https://www.dropbox.com/, 2024

    2024

  20. [28]

    Google Drive

    Google, “Google Drive.” https://www.google.com/drive/, 2024

    2024

  21. [29]

    RedSafe: Frequently asked questions

    International Committee of the Red Cross, “RedSafe: Frequently asked questions.” https://www.icrc.org/en/about-redsafe-app, 2024

    2024

  22. [30]

    Ledger Flex

    Ledger, “Ledger Flex.” https://shop.ledger.com/pages/ledger-flex, 2024

    2024

  23. [31]

    Safepal S1

    Safepal, “Safepal S1.” https://safepal.com/en/store/s1, 2024

    2024

  24. [32]

    Why we need wide adoption of social recovery wallets

    V . Buterin, “Why we need wide adoption of social recovery wallets.” https://vitalik.eth.limo/general/2021/01/11/recovery.html, 2021

    2021

  25. [33]

    Set up an account recovery contact

    Apple, “Set up an account recovery contact.” https: //support.apple.com/en-gb/102641, 2024

    2024

  26. [34]

    How to Share a Secret,

    A. Shamir, “How to Share a Secret,”Communications of the ACM, vol. 22, no. 11, pp. 612–613, 1979

    1979

  27. [35]

    HTC EXODUS 1

    HTC, “HTC EXODUS 1.” https://www.htcexodus.com/eu/support/ exodus-one/category howto/about-social-key-recovery.html, 2025

    2025

  28. [36]

    It’s Not What You Know, But Who You Know: A social approach to last-resort au- thentication,

    S. Schechter, S. Egelman, and R. W. Reeder, “It’s Not What You Know, But Who You Know: A social approach to last-resort au- thentication,” inProceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’09, (New York, NY , USA), p. 1983–1992, Association for...

    1983

  29. [37]

    Secretive and close? How sharing secrets may impact perceptions of distance,

    M. E. Jaff ´e, M. Douneva, and E. A. Albath, “Secretive and close? How sharing secrets may impact perceptions of distance,”PLOS One, vol. 18, no. 4, p. e0282643, 2023

    2023

  30. [38]

    Social influence: Compliance and conformity,

    R. B. Cialdini and N. J. Goldstein, “Social influence: Compliance and conformity,”Annu. Rev. Psychol., vol. 55, no. 1, pp. 591–621, 2004

    2004

  31. [39]

    One hundred years of forgetting: A quantitative description of retention,

    D. C. Rubin and A. E. Wenzel, “One hundred years of forgetting: A quantitative description of retention,”Psychological Review, vol. 103, no. 4, pp. 734–760, 1996

    1996

  32. [40]

    An Empirical Study of a Decen- tralized Identity Wallet: Usability, Security, and Perspectives on User Control,

    M. Korir, S. Parkin, and P. Dunphy, “An Empirical Study of a Decen- tralized Identity Wallet: Usability, Security, and Perspectives on User Control,” inEighteenth Symposium on Usable Privacy and Security (SOUPS 2022), (Boston, MA), pp. 195–211, USENIX Association, 2022

    2022

  33. [41]

    The slow forgetting of emotional episodic memories: an emotional binding account,

    A. P. Yonelinas and M. Ritchey, “The slow forgetting of emotional episodic memories: an emotional binding account,”Trends in Cogni- tive Sciences, vol. 19, no. 5, pp. 259–267, 2015

    2015

  34. [42]

    AlDanial, “CLOC.” https://github.com/AlDanial/cloc, 2025

    2025

  35. [43]

    The Strength of Internet Ties

    Pew Research Center, “The Strength of Internet Ties.” https://www.pewresearch.org/internet/2006/01/25/the-strength- of-internet-ties/, 2006

    2006

  36. [44]

    Dunbar,How many friends does one person need? Dunbar’s number and other evolutionary quirks

    R. Dunbar,How many friends does one person need? Dunbar’s number and other evolutionary quirks. Harvard University Press, 2010

    2010

  37. [45]

    Phishing in organizations: Findings from a large-scale and long-term study,

    D. Lain, K. Kostiainen, and S. ˇCapkun, “Phishing in organizations: Findings from a large-scale and long-term study,” in2022 IEEE Symposium on Security and Privacy (SP), pp. 842–859, IEEE, 2022

    2022

  38. [46]

    Digital 2024 April Global Statshot Report

    Datareportal, “Digital 2024 April Global Statshot Report.” https:// datareportal.com/reports/digital-2024-april-global-statshot, 2024

    2024

  39. [47]

    SoK: Secure Data Deletion,

    J. Reardon, D. Basin, and S. Capkun, “SoK: Secure Data Deletion,” in 2013 IEEE Symposium on Security and Privacy, pp. 301–315, 2013

    2013

  40. [48]

    Secure Data Deletion from Persistent Media,

    J. Reardon, H. Ritzdorf, D. Basin, and S. Capkun, “Secure Data Deletion from Persistent Media,” CCS ’13, (New York, NY , USA), p. 271–284, Association for Computing Machinery, 2013

    2013

  41. [49]

    Deleting Secret Data with Public Verifiability,

    F. Hao, D. Clarke, and A. F. Zorzo, “Deleting Secret Data with Public Verifiability,”IEEE Transactions on Dependable and Secure Computing, vol. 13, no. 6, pp. 617–629, 2016

    2016

  42. [50]

    Secret sharing with certified dele- tion

    J. Bartusek and J. Raizes, “Secret sharing with certified dele- tion.” Cryptology ePrint Archive, Paper 2024/736, 2024. https: //eprint.iacr.org/2024/736

    2024

  43. [51]

    CanDID: Can-Do De- centralized Identity with Legacy Compatibility, Sybil-Resistance, and Accountability,

    D. Maram, H. Malvai, F. Zhang, N. Jean-Louis, A. Frolov, T. Kell, T. Lobban, C. Moy, A. Juels, and A. Miller, “CanDID: Can-Do De- centralized Identity with Legacy Compatibility, Sybil-Resistance, and Accountability,” in2021 IEEE Symposium on Security and Privacy (SP), pp. 1348...

    2021

  44. [52]

    Acsesor: A New Framework for Auditable Custodial Secret Storage and Recov- ery

    M. Chase, H. Davis, E. Ghosh, and K. Laine, “Acsesor: A New Framework for Auditable Custodial Secret Storage and Recov- ery.” Cryptology ePrint Archive, Paper 2022/1729, 2022. https: //eprint.iacr.org/2022/1729

    2022

  45. [53]

    CALYPSO: Private Data Management for Decentralized Ledgers,

    E. Kokoris-Kogias, E. C. Alp, L. Gasser, P. Jovanovic, E. Syta, and B. Ford, “CALYPSO: Private Data Management for Decentralized Ledgers,”Proceedings of the VLDB Endowment, vol. 14, p. 586–599, dec 2020

    2020

  46. [54]

    How to Recover a Cryptographic Secret From the Cloud

    D. Adei, C. Orsini, A. Scafuro, and T. Verber, “How to Recover a Cryptographic Secret From the Cloud.” Cryptology ePrint Archive, Paper 2023/1308, 2023

    2023

  47. [55]

    SafetyPin: Encrypted backups with Human-Memorable secrets,

    E. Dauterman, H. Corrigan-Gibbs, and D. Mazi `eres, “SafetyPin: Encrypted backups with Human-Memorable secrets,” in14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20), pp. 1121–1138, USENIX Association, Nov. 2020

    2020

  48. [56]

    Secret Key Recovery in a Global-Scale End-to-End Encryption System,

    G. Connell, V . Fang, R. Schmidt, E. Dauterman, and R. A. Popa, “Secret Key Recovery in a Global-Scale End-to-End Encryption System,” in18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24), (Santa Clara, CA), pp. 703–719, USENIX Association, July 2024

    2024

  49. [57]

    Trusted Execution Envi- ronments: Properties, Applications, and Challenges,

    P. Jauernig, A.-R. Sadeghi, and E. Stapf, “Trusted Execution Envi- ronments: Properties, Applications, and Challenges,”IEEE Security & Privacy, vol. 18, no. 2, pp. 56–60, 2020

    2020

  50. [58]

    A survey of published attacks on Intel SGX,

    A. Nilsson, P. N. Bideh, and J. Brorsson, “A survey of published attacks on Intel SGX,”arXiv preprint arXiv:2006.13598, 2020

    2006 arXiv

  51. [59]

    Password- protected secret sharing,

    A. Bagherzandi, S. Jarecki, N. Saxena, and Y . Lu, “Password- protected secret sharing,” inProceedings of the 18th ACM Conference on Computer and Communications Security, CCS ’11, (New York, NY , USA), p. 433–444, Association for Computing Machinery, 2011

    2011

  52. [60]

    Highly-Efficient and Composable Password-Protected Secret Sharing (Or: How to Protect Your Bitcoin Wallet Online),

    S. Jarecki, A. Kiayias, H. Krawczyk, and J. Xu, “Highly-Efficient and Composable Password-Protected Secret Sharing (Or: How to Protect Your Bitcoin Wallet Online),” in2016 IEEE European Symposium on Security and Privacy (EuroS&P), pp. 276–291, 2016

    2016

  53. [61]

    Dynamic and verifiable hierarchical secret sharing,

    G. Traverso, D. Demirel, and J. Buchmann, “Dynamic and verifiable hierarchical secret sharing,” inInformation Theoretic Security: 9th International Conference, ICITS 2016, Tacoma, WA, USA, August 9- 12, 2016, Revised Selected Papers 9, pp. 24–43, Springer, 2016

    2016

  54. [62]

    Hierarchical threshold secret sharing,

    T. Tassa, “Hierarchical threshold secret sharing,”Journal of cryptol- ogy, vol. 20, pp. 237–264, 2007

    2007

  55. [63]

    Ideal hierarchical secret sharing schemes,

    O. Farras and C. Padr ´o, “Ideal hierarchical secret sharing schemes,” IEEE transactions on information theory, vol. 58, no. 5, pp. 3273– 3286, 2012

    2012

  56. [64]

    Over- coming security limitations of Secret Share techniques: the Nested Secret Share,

    A. Galletta, J. Taheri, M. Fazio, A. Celesti, and M. Villari, “Over- coming security limitations of Secret Share techniques: the Nested Secret Share,” in2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), (Los Alam...

    2021

  57. [65]

    Proactive secret sharing or: How to cope with perpetual leakage,

    A. Herzberg, S. Jarecki, H. Krawczyk, and M. Yung, “Proactive secret sharing or: How to cope with perpetual leakage,” inAdvances in Cryptology—CRYPT0’95: 15th Annual International Cryptology Conference Santa Barbara, California, USA, August 27–31, 1995 Proceedings 15, pp. 339–...

    1995

  58. [66]

    Churp: dynamic-committee proactive secret sharing,

    S. K. D. Maram, F. Zhang, L. Wang, A. Low, Y . Zhang, A. Juels, and D. Song, “Churp: dynamic-committee proactive secret sharing,” inProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, pp. 2369–2386, 2019

    2019

  59. [67]

    Long live the honey badger: Robust asynchronous{DPSS}and its applications,

    T. Yurek, Z. Xiang, Y . Xia, and A. Miller, “Long live the honey badger: Robust asynchronous{DPSS}and its applications,” in32nd USENIX Security Symposium (USENIX Security 23), pp. 5413–5430, 2023

    2023

  60. [68]

    Abuse-Resistant Location Tracking: Balancing Privacy and Safety in the Offline Finding Ecosystem

    G. Beck, H. Eldridge, M. Green, N. Heninger, and A. Jain, “Abuse-Resistant Location Tracking: Balancing Privacy and Safety in the Offline Finding Ecosystem.” Cryptology ePrint Archive, Paper 2023/1332, 2023. https://eprint.iacr.org/2023/1332

    2023

  61. [69]

    Where Have You Been? Using{Location-Based}Security Questions for Fallback Authentication,

    A. Hang, A. De Luca, M. Smith, M. Richter, and H. Hussmann, “Where Have You Been? Using{Location-Based}Security Questions for Fallback Authentication,” inEleventh Symposium On Usable Privacy and Security (SOUPS 2015), pp. 169–183, 2015

    2015

  62. [70]

    I know what you did last week! do you? dynamic security questions for fallback authentication on smartphones,

    A. Hang, A. De Luca, and H. Hussmann, “I know what you did last week! do you? dynamic security questions for fallback authentication on smartphones,” inProceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems, pp. 1383–1392, 2015

    2015

  63. [71]

    Secrets, lies, and account recovery: Lessons from the use of per- sonal knowledge questions at google,

    J. Bonneau, E. Bursztein, I. Caron, R. Jackson, and M. Williamson, “Secrets, lies, and account recovery: Lessons from the use of per- sonal knowledge questions at google,” inProceedings of the 24th international conference on world wide web, pp. 141–150, 2015

    2015

  64. [72]

    Personal knowledge questions for fallback authentication: Security questions in the era of Facebook,

    A. Rabkin, “Personal knowledge questions for fallback authentication: Security questions in the era of Facebook,” inProceedings of the 4th Symposium on Usable Privacy and Security, SOUPS ’08, (New York, NY , USA), p. 13–23, Association for Computing Machinery, 2008

    2008

  65. [73]

    On the Security of Trustee-Based Social Authentications,

    N. Z. Gong and D. Wang, “On the Security of Trustee-Based Social Authentications,”IEEE Transactions on Information Forensics and Security, vol. 9, no. 8, pp. 1251–1263, 2014

    2014

  66. [74]

    Social authentication ap- plications, attacks, defense strategies and future research directions: a systematic review,

    N. Alomar, M. Alsaleh, and A. Alarifi, “Social authentication ap- plications, attacks, defense strategies and future research directions: a systematic review,”IEEE Communications Surveys & Tutorials, vol. 19, no. 2, pp. 1080–1111, 2017

    2017

  67. [75]

    All your face are belong to us: Breaking facebook’s social authentication,

    I. Polakis, M. Lancini, G. Kontaxis, F. Maggi, S. Ioannidis, A. D. Keromytis, and S. Zanero, “All your face are belong to us: Breaking facebook’s social authentication,” inProceedings of the 28th annual computer security applications conference, pp. 399–408, 2012

    2012

  68. [76]

    Social Authentication: Harder Than It Looks,

    H. Kim, J. Tang, and R. Anderson, “Social Authentication: Harder Than It Looks,” inFinancial Cryptography and Data Security, pp. 1– 15, Springer, 2012. Appendix

    2012

  69. [77]

    We use the notations provided in Table 2

    Security of Single Layered Approach In this section, we analyze the security provided by the single-layered design of Section 5.3. We use the notations provided in Table 2. We consider a user or an adversary approaching people in an arbitrary order, i.e., the contact which is ...

  70. [78]

    Security of Multi-Layered Secret Sharing 2.1. Loose bounds on key recovery probability.We con- sider a user or an adversary approaching people in an arbitrary order, i.e., the contact which is to be approached is chosen in a uniformly random manner without replacement. For MLS...

  71. [79]

    DEFAULTVALUES Parameter Default Value No

    Then, this section proceeds to an analysis of threshold TABLE 3. DEFAULTVALUES Parameter Default Value No. of trustees 20 Anonymity Set Size 150 Percentage threshold (τ) 0.5 Absolute Threshold (α) 3 No. of shares per person (γ) 2 No. of subsecrets (β) 6 provided by the multi-l...

  72. [80]

    This design reduces the overall security because some subsecrets have their threshold less than the value set by the user

    shares and some of them will have⌊ α τ⌋) shares. This design reduces the overall security because some subsecrets have their threshold less than the value set by the user. 2)Increasing the number of subsecrets and distributing less shares:The second idea is to enhance the secu...

  73. [81]

    The number of computationsNCin this case is given by the expression NC = tX i=2 n i .(36) As shown in Eq

    Computation Complexity Consider the scenario where a user has to contact up to ttrustees out ofncontacts in her address book to recover her secret key. The number of computationsNCin this case is given by the expression NC = tX i=2 n i .(36) As shown in Eq. (36), the number of...

  74. [82]

    Apollo Lite This extension is for shifting the expected probability of recovery to that of a single-layered approach. Instead of defining the minimum number of trustees that should be contacted, such users define the threshold in terms of the expected number of trustees that s...

  75. [83]

    The design of TMLSS is similar to that of MLSS, except the fact that TMLSS uses Shamir’s secret shares in the subsecrets layer

    T-Apollo Thresholded-Apollo or T-Apollo uses a modified ver- sion of MLSS, which we refer to as thresholded-MLSS or TMLSS. The design of TMLSS is similar to that of MLSS, except the fact that TMLSS uses Shamir’s secret shares in the subsecrets layer. Using a threshold for subs...

  76. [84]

    Particularly, H-Apollo stores somehintsin the blobs held by trustees that provide the name of trustees holding shares of another subsecret

    H-Apollo Hinted-Apollo or H-Apollo modifies the way key re- covery works in Apollo using the recovery address book. Particularly, H-Apollo stores somehintsin the blobs held by trustees that provide the name of trustees holding shares of another subsecret. The hints are encrypt...

  77. [85]

    22, we compare the probability of key recovery using Apollo and the variants described above

    Comparison with Apollo In Fig. 22, we compare the probability of key recovery using Apollo and the variants described above

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.