Half-Moon Cookie: Private, Similarity-Based Blocklisting with TOCTOU-Attack Resilience

Abstract: Blocklisting is a common technique for preventing the use of known malicious content. However, conventional blocklisting infrastructures require either the blocklist to be public or clients to reveal their queries to the blocklist server. In this work, we introduce a private blocklisting framework, Half-Moon Cookie, by which a client can check an item against a proprietary blocklist held by a server, to determine whether the item is close to any blocklist element in a metric space. Critically, our design separates the embedding step from the blocklist check, so that performance degrades with their sum and not their product. Still, this check might be too costly to perform on the critical path of using the item, and so our design also supports a very efficient check that an item previously passed the blocklist check. In doing so, we support applications where one client can perform the blocklist check on the item before sending it, and recipients can more efficiently confirm the previous result before using the item, thereby avoiding TOCTOU attacks. We demonstrate how Half-Moon Cookie can be instantiated for similarity-based malware detection, enabling effective identification of malicious executables without revealing client inputs or disclosing the underlying blocklist.

• The paper introduces a novel privacy-preserving framework for similarity-based blocklisting that decouples explicit and implicit checks using secure cryptographic primitives.
• It employs metric embeddings, garbled circuits, and fuzzy PSI to achieve scalable performance, reduced communication overhead, and resilience against TOCTOU attacks.
• Experimental results on malware and email datasets demonstrate significant efficiency gains, validating its practical applicability in cybersecurity.

Private Similarity-Based Blocklisting via Half-Moon Cookie

Motivation and Problem Definition

Blocklisting remains fundamental in operational cybersecurity—especially for mitigating the threat posed by malicious executables, fraudulent emails, or compromised credentials. When the blocklist or the artifact being checked is proprietary, privacy-preserving membership testing is required. Conventional solutions either publicly expose the blocklist or force the client to reveal their query, both of which are often unacceptable for sensitive applications. Moreover, when the check is computationally intensive (e.g., using approximate set intersection over similarity-preserving hashes), performing it on the critical path can induce prohibitive latency or vulnerabilities to time-of-check-to-time-of-use (TOCTOU) attacks.

Half-Moon Cookie introduces a cryptographic framework enabling a client to perform a similarity-based blocklisting check with privacy guarantees—neither party learns more than the verdict. Critically, the explicit policy check is decoupled from its confirmation: the artifact can be efficiently re-checked (implicit check) immediately before usage, ensuring resilience to TOCTOU attacks. The framework leverages metric embeddings, binding and hiding allowlist tokens, and asynchronous verification, all constructed atop cryptographically sound primitives.

Formal Framework and Threat Model

The framework consists of two phases:

• Explicit Check: The sender (client 1) inputs an artifact, which is embedded into a metric space (typically Hamming space over similarity-preserving hashes, e.g., TLSH). The server, holder of the proprietary blocklist, checks whether the artifact's embedding lies within threshold $T$ of any blocklist embedding. If not, the server issues a token, committing the artifact to an allowlist. This token is binding (preventing malfeasance) and hiding (protecting input privacy).
• Implicit Check: Recipient clients (client 2) receive the artifact (and associated token). They interact with the server to verify, via efficient computation and communication, whether the artifact was already checked (token is valid and not revoked).

The threat models addressed include (1) malicious sender attempting to subvert the check and (2) honest-but-curious server attempting to learn artifact content. The framework does not consider malicious server behavior since it is typically an incentivized contracted party (see application rationale).

Cryptographic Building Blocks

Half-Moon Cookie utilizes:

• Metric Embeddings: Artifacts are mapped to vector representations via similarity hashing and injective set-to-vector mappings. For Hamming-distance similarity, fuzzy hashes such as TLSH are used, followed by polynomial interpolation.
• One-Time Pairwise Unpredictable Permutations: Linear combinations of embedding vectors are randomized via cryptographically sound functions, guaranteeing unpredictability across distinct inputs, crucial for binding property of allowlist tokens.
• Garbled Circuits and Reusable Garbled Circuits (RGCs): Embedding computations are performed in garbled circuits, with optimizations for reusability to handle large files efficiently, without leaking garbler input (see CRGC instantiations).
• Distance-Aware Private Set Intersection (PSI): For similarity checks, assumption-free fuzzy PSI protocols are leveraged, supporting private matching in Hamming space without distributional assumptions.
• Non-programmable Random Oracles: Hashing within circuit models rely on fixed hash functions, providing hiding properties against honest-but-curious servers.

Framework Instantiation and Interaction

The blocklist elements are clustered in metric space, and only representatives plus a threshold $T$ are maintained, improving scalability (sum, not product of embedding and blocklist size). After passing explicit check, the server creates a hiding and binding token, indexed by nonce, and stores it in the allowlist.

Figure 1: Framework interaction—explicit and implicit check phases, showing token creation and private verification.

During explicit check, sender and server jointly execute embedding and similarity test via garbled circuits. The server stores the token only if the artifact's embedding is not proximate to blocklisted embeddings. During implicit check, the recipient can efficiently verify authenticity against the allowlist with minimal computational cost, even as blocklist size increases.

Performance Evaluation and Optimizations

Evaluation is carried out by benchmarking C++ implementations (using EMP toolkit for secure computation and CRGC for RGCs) on email attachment datasets (Enron) and malware blocklists (Ember, clustering $16{,}356{,}790$ malware instances):

• Leveraging reusable garbled circuits reduces communication by over two orders of magnitude and response time by at least one order for embedding operations.
• The response time and communication complexity for explicit check scale gracefully with blocklist size, not with input size, by decoupling garbled circuit computation from blocklist enumeration.
• Throughput experiments demonstrate scalable server-side handling, with bottlenecks primarily due to blocklist size rather than input size.

Strong numerical results include:

• For a median-size executable (\SI{5}{\kilo\byte}), embedding cost drops from $6.8 \times 10^4$ MB to $60$ MB communication, and response time from $1.0 \times 10^3$ s to $4.8$ s with RGC optimizations.
• Implicit checks complete in $0.19$ seconds at $7.2\times 10^{-3}$ MB communication, outperforming existing fuzzy PSI solutions by two–three orders of magnitude.

Security Guarantees and Analysis

Security proofs are detailed using game-based analysis, showing negligible advantage for adversaries (malicious senders or honest-but-curious servers) in breaking binding, hiding, or unpredictability properties.

The explicit check ensures that only the artifact's correct embedding can result in a stored token, preventing malicious clients from 'masking' blocklisted artifacts. The implicit check relies on binding tokens constructed via one-time pairwise unpredictable functions, ensuring computational infeasibility for adversaries to forge or collide tokens.

Figure 2: Truth table for XOR gates—illustrating CRGC’s circuit-level indistinguishability used in reusable garbling for input privacy.

Implications and Future Directions

Practically, Half-Moon Cookie enables outsourceable, privacy-preserving malware scanning that remains TOCTOU resilient—a major requirement in cloud-driven content distribution, including secure email, CDN artifact delivery, and corporate security gateways. Since allowlist confirmation is computationally efficient and independent of blocklist size, recipient-side latency is minimized.

Theoretically, this framework demonstrates the decoupling of privacy-preserving similarity tests from artifact embedding—a sum, not product, in complexity. The use of binding and hiding tokens represents a novel form of interactive MAC (or designated-verifier signature), supporting private authentication and revocation in distributed settings.

Possible future directions include:

• Extension to richer metric spaces or more elaborate similarity metrics.
• Integration with public verifiability/digital signature schemes for broader auditability.
• Deployment in federated or decentralized policy settings (e.g., collaborative blocklisting).
• Deeper optimization of garbled circuit techniques for further efficiency improvements.

Conclusion

Half-Moon Cookie provides an efficient and cryptographically robust solution for similarity-based blocklisting with strong privacy and TOCTOU-attack resilience, scaling gracefully to practical artifact and blocklist sizes. It enables a separation of expensive policy checks from lightweight re-verification, with broad applicability across privacy-critical malware detection and content authentication applications.