BSBFPSI: Shielding Social Discovery with Blind Signatures and Bloom Filters
Privacy-preserving friendship establishment based on blind signature and bloom filter in mobile social networks
The paper proposes BSBFPSI, a privacy-preserving friendship establishment protocol for Mobile Social Networks (MSNs) that identifies common friends without exposing non-mutual contacts. It combines partially blind signatures with Bloom Filters to achieve high computational efficiency and robust resistance against enumeration attacks.
TL;DR
Mobile Social Networks (MSNs) often use "Common Friend" discovery to build connections, but this process frequently leaks sensitive social graphs. This paper introduces BSBFPSI, a protocol that merges Blind Signatures with Bloom Filters. It not only makes friend discovery lightning-fast for mobile devices but also shuts down "enumeration attacks" where malicious users try to guess your friends one by one.
The Problem: The "Curious" Neighbor and Heavy Math
The "Common Friends" feature is a staple of digital social life, but it presents a privacy paradox. How do you find out if we have mutual friends without telling me all your friends?
Traditional solutions involve Private Set Intersection (PSI). However, traditional PSI often relies on heavy asymmetric cryptography that drains mobile batteries. A recent optimization used Bloom Filters (BFPSI)—compact data structures that allow for quick membership checks. While fast, BFPSI had a fatal flaw: a malicious user could repeatedly initiate the protocol with different "guesses" to eventually map out your entire friend list (an enumeration attack).
Methodology: The "Blind" Matchmaker
The core innovation of this paper is the introduction of Partially Blind Signatures from bilinear pairings into the Bloom Filter workflow.
1. The Interaction Flow
Instead of just checking raw IDs in a Bloom Filter, the protocol uses a multi-step cryptographic handshake:
- Initiator (I): Creates a Bloom Filter populated with signed versions of their friends' IDs.
- Responder (R): Takes their own friends' IDs, "blinds" them (hides them with a random factor), and asks the Initiator to sign these blinded values.
- The Signature: The Initiator signs the blinded IDs without ever seeing who they are.
- The Unblinding: The Responder unblinds the result to get a valid signature from the Initiator.
- The Intersection: The Responder checks these signed IDs against the Initiator's Bloom Filter.
2. Why this stops attacks
Because the signatures are session-specific and require the Initiator's active (but blind) participation, a malicious user cannot easily automate the enumeration of the Initiator's friends without the Initiator detecting repeated, suspicious signature requests.
Fig 1: The BSBFPSI protocol flow showing the interaction between Initiator and Responder.
Experiments: Speed vs. Accuracy
The authors evaluated BSBFPSI against traditional PSI-CA (Cardinality) and the original BFPSI.
Computational Efficiency
The study found that as the number of friends (input size) grows to 500, traditional PSI-CA's processing time spikes significantly due to the complexity of the math. However, BSBFPSI remains nearly flat, completing the task in under 0.5 seconds.
Fig 2: Performance comparison showing BSBFPSI's linear and efficient scaling compared to PSI-CA.
The Trade-off: False Positives
Bloom Filters are probabilistic—there is a tiny chance the protocol might say "Yes, you are mutual friends" when you aren't. The researchers showed that by simply increasing the number of hash functions to 30, the error rate drops to (one in a billion), which is more than acceptable for social networking.
Critical Insight & Conclusion
The genius of this work lies in decoupling. It uses heavy cryptography (Blind Signatures) only for the authentication of the identity, but leaves the heavy lifting of set intersection to the Bloom Filter.
Takeaway: If you are building a privacy-first mobile app, don't rely on raw PSI. The hybrid approach—combining session-based signatures with probabilistic data structures—is the "goldilocks" zone for mobile performance and security.
Limitations: The paper currently assumes a "Honest-But-Curious" model. In a purely malicious environment where users might provide malformed inputs to crash the system, further zero-knowledge proofs might be required, though that would likely impact the performance gains highlighted here.
