Multi-Key Privacy: Breakthrough in Cloud-Assisted Profile Matching for Social Networks

TL;DR

Mobile Social Networks (MSNs) rely on "Profile Matching" to connect people with similar interests, but this often exposes sensitive personal data. This paper introduces a non-interactive, multi-key privacy-preserving scheme. By using a dual-cloud architecture and Proxy Re-Encryption (PRE) with additive homomorphism, users can discover friends without revealing their private vectors, even when their data is encrypted under different keys.

Problem & Motivation: The Multi-Key Dilemma

In a typical MSN, Alice and Bob want to know if they share hobbies (represented as vectors) without showing each other their specific interests. The state-of-the-art faces three main walls:

1. The Interaction Bottleneck: Traditional Secure Multi-Party Computation (SMC) requires users to stay online and exchange messages constantly, which drains mobile batteries.
2. The "Single Key" Constraint: Most cloud-offloading schemes assume everyone uses the same encryption key—a total non-starter for decentralized social networks.
3. Computational Resource Gap: Mobile devices cannot handle the heavy math of Fully Homomorphic Encryption (FHE).

The authors' insight? Use Proxy Re-Encryption to transform diverse user keys into a temporary cloud-specific key, then use additive homomorphism to calculate the similarity (dot product) without ever seeing the raw data.

Methodology: The Dual-Cloud Dance

The core of the system is the EL (ElGamal-like) scheme and two non-colluding cloud servers: Cloud A (CA) and Cloud B (CB).

1. Data Outsourcing

Users encrypt their preference vectors (e.g., interests in dancing, traveling) using their own public keys and upload them to Cloud A.

2. The Matching Protocol

Since Alice and Bob use different keys, Cloud A cannot simply add their ciphertexts.

• Re-encryption: Using a re-encryption key, Cloud A transforms Alice’s and Bob’s ciphertexts into a format that can be processed under Cloud B's key.
• Blinding & Computation: Cloud A adds random noise (blinding) to the data before sending it to Cloud B. Cloud B performs the dot product calculation and sends the result back.
• Result Delivery: Cloud A removes the noise and sends the encrypted result to Alice.

3. The Dot Product Trick

The scheme calculates the dot product via the identity: $2\sum u_i{v}_i=\sum u_i^2+\sum v_i^2-\sum (u_i-v_i{)}^2$ This allows the servers to compute similarity using only additions and scalar multiplications, which are supported by the EL scheme.

Experiments & Comparison

The paper evaluates the scheme against existing "Fine-grained" matching protocols. Unlike prior work (Zhang et al.), this scheme is non-interactive for users. Once the data is uploaded, the cloud handles everything.

Key Advantages:

• Security: Proven secure under the Honest-But-Curious (HBC) model. Even if a user colludes with one cloud server, the other user's vector remains hidden.
• Efficiency: Moves the $O(n)$ complexity to the cloud. Users only perform $O(1)$ decryption to get the final matching result.

Critical Analysis & Conclusion

The scheme successfully tackles the "Multiple Keys" problem, which is a significant hurdle in real-world deployment. However, it relies heavily on the non-collusion assumption between the two cloud providers. If Cloud A and Cloud B work together, the privacy layer evaporates.

Future Outlook: While this work uses Pollard's kangaroo method for discrete logs (limiting the plaintext range), future iterations could integrate more advanced ECC-based homomorphic schemes to handle higher-precision attributes or larger datasets without losing efficiency.

Takeaway: If you are building a privacy-first MSN, this "Dual Cloud + PRE" architecture provides the best balance between user-side lightweight execution and robust multi-user security.