{"id":"c1878faf-1741-49ed-b7a4-4b38157bd109","arxiv_id":"2507.19484","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Apollo lets a user recover a vault key by reconnecting with her social circle, hiding which contacts are real trustees behind indistinguishable random shares.","lead":"Apollo is a new social key recovery system that gives every contact a data packet, either a real key share or an indistinguishable fake, so the owner does not have to remember who holds the key. It aims to make vault recovery possible after device loss while keeping the trustee set private from attackers, using a two-layer secret sharing scheme to keep recovery computation fast.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Self-recovery overreaches: Apollo still requires the user to remember to initiate Apollo recovery; no protocol mechanism covers RM1 (vault existence) or RM2 (recovery procedure), contradicting Table 1.","rationale":"The reader's weakest_assumption focuses on the threat model and the empirical security percentages (k_obt, p_rpt, and Fig. 12). That concern is real: the 0.005%–1.8% malicious-recovery range depends on the 5% reporting probability and user-validated extortion rates, and the paper concedes in Section 7.2 that no user study was conducted. I do not dispute that this weakens the 'unauthorized access mitigation' contribution. However, the more load-bearing concern is about the self-recovery ideal itself, which is half of the central claim. The protocol's own recovery procedure in Section 5.2 requires the user to remember to get a new device, reconnect with people, and have her device query for packets. Trustee privacy prevents contacts from knowing they hold material, so they cannot alert an amnesiac user. Consequently, Apollo does not actually remove the need to remember vault existence (RM1) or the recovery procedure (RM2), despite Table 1 claiming those checkmarks and the abstract saying recovery metadata is eliminated. This is an internal inconsistency with Section 3.1's taxonomy, not an empirical gap. It can be fixed by either adding an explicit automatic trigger (e.g., an OS-level service that monitors reconnections and starts recovery without user recall) or by qualifying the claimed self-recovery to 'recovery without remembering trustees or threshold.' Both the reader's conditional verdict and my concern point to the same bottom line: the paper should not be accepted as-is. I therefore keep the CONDITIONAL verdict, but for a reason that the reader's weakest_assumption did not identify. If the self-recovery gap is left unaddressed, the headline claim of being the first framework to concurrently achieve self-recovery and metadata privacy would be overstated; with a clear revision to scope and an explicit initiation mechanism, the protocol's substantive contributions remain valuable.","tokens_in":34727,"tokens_out":18890,"duration_ms":207691,"concrete_test":"Trace the recovery protocol from Section 5.2 under the assumption that the user remembers neither RM1 nor RM2. Identify the first event that causes the user's new device to request any packet from a contact. If that event is 'the user opens Apollo and chooses recovery' or 'the user asks a contact for a packet,' then self-recovery fails for RM1/RM2. To confirm, patch the prototype (Section 6.1) with all recovery UI hidden and observe whether any automatic OS- or contact-triggered mechanism initiates recovery after a reconnection; if none occurs, the claimed self-recovery property is absent.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The paper's central claim is that Apollo 'eliminates the need to memorize recovery metadata' (Abstract) and Table 1 marks RM1 (vault existence) and RM2 (recovery procedure) as remembered-by-user for all prior schemes but not for Apollo. However, the recovery protocol in Section 5.2 begins with: 'she gets a new device and reconnects with people she knows' and then 'the user's device queries the reconnected person's device for a packet.' This presupposes that the user remembers to run Apollo and to initiate the recovery flow. Nothing in the protocol alerts a user who has forgotten RM1/RM2, and trustee privacy (Section 3.3) explicitly keeps contacts oblivious of their trustee status, so contacts cannot prompt the user. Thus the design achieves recovery without remembering trustee details and threshold, but not without remembering vault existence and recovery procedure. The abstract's unconditional 'eliminates the need to memorize recovery metadata' and Table 1's checkmarks for RM1/RM2 overstate what the protocol delivers. This is an internal inconsistency with the paper's own definition of self-recovery in Section 3.2, not merely a missing user study.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":34941,"tokens_out":5881,"duration_ms":62101,"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":[{"comment":"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.","section":"Sections 3.2, 5.2, and Table 1"},{"comment":"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.","section":"Sections 4.3, 6.6, and 7.2"}],"minor_comments":[{"comment":"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.","section":"Table 1"},{"comment":"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.","section":"Figures 11 and 12"},{"comment":"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.","section":"Throughout"},{"comment":"The reference to forgetting studies appears as '[19], [19], [39]' with [19] duplicated; one duplicate citation should be removed.","section":"Section 3.3"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nThe paper is worth a look: Apollo's trick of handing indistinguishable chaff packets to every contact and using a two-layer sharing scheme to keep recovery search small is a genuine design contribution. The MLSS construction is the real meat - it turns an exponential combination search into something polynomial with a small fixed threshold, and the prototype numbers (740k x speedup at 30 reconnections, 155s for 850 reconnections) are impressive if they hold up. The recovery-metadata taxonomy is a useful framing, though less new.\n\nThe soft spots are real and in proportion. First, the security headline is a simulation with assumed parameters: 40%/60% memory error, 25% extortion success, 5% reporting probability, borrowed from a phishing study. The paper is honest that these need user validation, but the abstract and Section 6.6 present 0.005%-1.8% malicious recovery without that caveat prominently attached. Fig. 12 shows that without reporting, an adversary with 75% extortion succeeds 88% of the time; the security claim is conditional on reporting actually happening and on extortion being uncertain. That's a load-bearing assumption, and the paper should say so in the abstract.\n\nSecond, and more importantly, the self-recovery claim overreaches in a way that is internally inconsistent. Table 1 marks RM1 (vault existence) and RM2 (recovery procedure) as covered by Apollo, but the protocol in Section 5.2 starts with 'she gets a new device and reconnects with people she knows' - which requires remembering that she has a vault and that Apollo exists. Nothing in the protocol helps a user who forgets those. The paper's own definition of self-recovery in Section 3.2 explicitly includes vault existence, so the abstract's 'eliminates the need to memorize recovery metadata' is too strong. The trustee/threshold part is genuinely eliminated, but RM1/RM2 are not.\n\nThe citation pattern looks fair, and the appendix has real bounds (even if approximate) for the combinatorial arguments. The prototype is not released, which weakens the reproducibility of the performance claims.\n\nWho should read this: anyone working on social recovery, decentralized identity, or usable security. It deserves a round of peer review; a revision should release the code, qualify the abstract, and either weaken the RM1/RM2 claims or add a mechanism that prompts the user when recovery is needed. I'd send it to review - it's a solid idea with fixable presentation problems.","headline":"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.","tokens_in":35514,"tokens_out":2793,"would_cite":false,"duration_ms":26709,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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…","keywords":["social key recovery","self-recovery","recovery metadata privacy","multi-layered secret sharing","anonymity set","vault recovery","indistinguishable packets","secret sharing"],"falsifier":"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.","tokens_in":34474,"feed_emoji":"🔐","tokens_out":7484,"duration_ms":73820,"temperature":0.7,"pith_summary":"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.","feed_headline":"Recover a lost vault without remembering any trustee","feed_subtitle":"Apollo hides trustees among all contacts and keeps recovery fast with a two-layer share scheme.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the polynomial threshold secret-sharing scheme used for the key shares and for the per-subsecret shares in MLSS.","marker":"[34]"},{"why":"Establishes the forgetting curve that motivates why users cannot be expected to remember recovery metadata after device loss.","marker":"[19]"},{"why":"Reports an empirical study where users failed to remember three out of four recovery contacts, motivating self-recovery instead of remembered trustee lists.","marker":"[36]"},{"why":"Provides the 25% phishing extortion success and 5% reporting probabilities used to calibrate the adversary simulations.","marker":"[45]"},{"why":"Provides the empirically grounded 150-contact address-book size used in the evaluation.","marker":"[44]"},{"why":"Supports the assumption that humans have a fundamental need to reconnect with social ties, which is what makes recovery by reconnection viable.","marker":"[20]"},{"why":"Represents the existing recovery-contact approach that fixes a small trustee set and still burdens the user with trustee memory, the baseline Apollo improves on.","marker":"[33]"},{"why":"Provides the 20-trustee count used in simulations, based on a study of identifying interpersonal ties.","marker":"[43]"}],"fun_headline_variants":["Forget your trustees: Apollo recovers vaults via social circle","Vault recovery with zero metadata memory and privacy","Apollo: recovery without trustee recall, privacy via chaff","Social vault recovery that hides trustees in your contacts","No trustee memory needed: Apollo's private recovery"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Forget your trustees: Apollo recovers vaults via social circle","Vault recovery with zero metadata memory and privacy","Apollo: recovery without trustee recall, privacy via chaff","Social vault recovery that hides trustees in your contacts","No trustee memory needed: Apollo's private recovery"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000393,"raw_usage":{"total_tokens":2089,"prompt_tokens":992,"completion_tokens":1097,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":608,"completion_tokens_details":{"reasoning_tokens":1019}},"tokens_in":608,"tokens_out":1097,"duration_ms":7368,"temperature":1.0,"reasoning_tokens":1019,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:30:18.272998+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"How to Share a Secret,","cited_arxiv_id":null,"evidence_quote":"Supplies the polynomial threshold secret-sharing scheme used for the key shares and for the per-subsecret shares in MLSS."},{"cited_title":"Replication and Analysis of Ebbinghaus’ Forgetting Curve,","cited_arxiv_id":null,"evidence_quote":"Establishes the forgetting curve that motivates why users cannot be expected to remember recovery metadata after device loss."},{"cited_title":"It’s Not What You Know, But Who You Know: A social approach to last-resort au- thentication,","cited_arxiv_id":null,"evidence_quote":"Reports an empirical study where users failed to remember three out of four recovery contacts, motivating self-recovery instead of remembered trustee lists."},{"cited_title":"Phishing in organizations: Findings from a large-scale and long-term study,","cited_arxiv_id":null,"evidence_quote":"Provides the 25% phishing extortion success and 5% reporting probabilities used to calibrate the adversary simulations."},{"cited_title":"Dunbar,How many friends does one person need? Dunbar’s number and other evolutionary quirks","cited_arxiv_id":null,"evidence_quote":"Provides the empirically grounded 150-contact address-book size used in the evaluation."},{"cited_title":"The need to belong: Desire for interpersonal attachments as a fundamental human motivation,","cited_arxiv_id":null,"evidence_quote":"Supports the assumption that humans have a fundamental need to reconnect with social ties, which is what makes recovery by reconnection viable."},{"cited_title":"Set up an account recovery contact","cited_arxiv_id":null,"evidence_quote":"Represents the existing recovery-contact approach that fixes a small trustee set and still burdens the user with trustee memory, the baseline Apollo improves on."},{"cited_title":"The Strength of Internet Ties","cited_arxiv_id":null,"evidence_quote":"Provides the 20-trustee count used in simulations, based on a study of identifying interpersonal ties."}],"review_version":1}