[Paper] Bloom Filter Look-Up Tables for Private and Secure Distributed Databases in Web3 (Revised Version)

Source: arXiv - 2602.13167v1

Overview

The paper introduces BFLUT (Bloom Filter Look‑Up Tables), a novel way to store and retrieve cryptographic keys in fully decentralized Web3 databases without ever persisting the raw keys on any node. By marrying Bloom‑filter‑based encoding with IPFS‑based storage stacks (OrbitDB, IPNS), the authors demonstrate a practical path to private, tamper‑resistant key management that survives node compromises.

Key Contributions

• BFLUT algorithm: A Bloom‑filter‑driven encoding scheme that turns a secret key into a private look‑up table, enabling secure retrieval while keeping the key hidden from all storage nodes.
• Decentralized key‑management architecture: Integration of BFLUT with OrbitDB, IPFS, and IPNS to provide consistency, versioning, and simultaneous updates across a peer‑to‑peer network.
• Security guarantees: Formal analysis showing that an adversary controlling up to k compromised nodes cannot reconstruct any stored key, even with full read access to the underlying data structures.
• Performance evaluation: Empirical benchmarks demonstrating sub‑millisecond look‑ups and modest bandwidth overhead (≈ 2–3 × the size of a raw key) on realistic Web3 testnets.
• Prototype implementation: Open‑source reference code that plugs into existing JavaScript/TypeScript IPFS stacks, lowering the barrier for developers to adopt the scheme.

Methodology

1. Key encoding with Bloom filters – Each secret key is hashed into a set of m bits using h independent hash functions. The resulting bit vector is stored as a “lookup table” in a distributed key‑value store (OrbitDB).
2. Distributed storage – The lookup tables are written to IPFS as immutable objects; IPNS pointers provide mutable references for updates. OrbitDB’s CRDT‑based replication ensures eventual consistency across peers.
3. Secure retrieval – A client that knows the original key can recompute the same hash positions and query the Bloom filter. If all bits are set, the client infers that the key is present; otherwise it aborts. No raw key ever leaves the client.
4. Threat model & analysis – The authors assume a Byzantine adversary that may compromise any subset of nodes but cannot break the underlying cryptographic hash functions. They prove that reconstructing a key from the Bloom filter requires solving a pre‑image attack on the hash functions, which is computationally infeasible.
5. Experimental setup – Tests were run on a 5‑node local IPFS cluster and on a public testnet (Filecoin / Polygon). Metrics captured include insertion latency, lookup latency, storage overhead, and resilience to node churn.

Results & Findings

• Security: Even when 3 out of 5 nodes were taken offline and their storage inspected, no key could be reconstructed.
• Scalability: The system handled 10 k concurrent inserts and look‑ups with linear growth in storage, confirming suitability for large‑scale dApps.
• Fault tolerance: Automatic CRDT reconciliation recovered from network partitions without key loss or duplication.

Practical Implications

• Secure wallet & session management – dApps can store session tokens or wallet‑derived keys in a public IPFS pinning service without fearing leakage, enabling “server‑less” authentication flows.
• Decentralized secret sharing – BFLUT can act as a building block for threshold‑cryptography schemes where each participant holds a Bloom‑encoded fragment of a master key.
• Compliance‑friendly data handling – Because raw keys never reside on any node, GDPR‑style “right to be forgotten” can be satisfied by simply revoking the IPNS pointer, rendering the lookup tables inaccessible.
• Low‑overhead integration – Existing OrbitDB‑based projects (e.g., decentralized social networks, supply‑chain trackers) can adopt BFLUT with a few lines of code, gaining cryptographic key protection without redesigning their storage layer.
• Edge‑device security – IoT devices that only have intermittent connectivity can still participate in a Web3 network, uploading Bloom‑encoded keys to IPFS and retrieving them later without exposing secrets to potentially compromised edge gateways.

Limitations & Future Work

• False positives – As with any Bloom filter, there is a non‑zero probability of a lookup succeeding for a non‑existent key; the current parameterization keeps this below 0.1 % but may need tuning for ultra‑high‑security contexts.
• Key size dependency – Larger keys (e.g., post‑quantum primitives) increase the Bloom filter size linearly, which could affect storage costs on public pinning services.
• Dynamic revocation – The scheme currently relies on IPNS pointer updates; rapid revocation of compromised keys could be slower than in centralized key‑vault solutions.
• Formal verification – While the paper provides a security proof under standard hash assumptions, a machine‑checked verification (e.g., using Coq or Isabelle) would strengthen confidence for high‑value deployments.
• Broader ecosystem testing – Future work includes stress‑testing BFLUT on heterogeneous Web3 networks (Polkadot, Solana) and exploring hybrid approaches that combine BFLUT with threshold secret‑sharing for multi‑party computation scenarios.

Authors

• Shlomi Dolev
• Ehud Gudes
• Daniel Shlomo

Paper Information

• arXiv ID: 2602.13167v1
• Categories: cs.DC, cs.CR
• Published: February 13, 2026
• PDF: Download PDF