Skip to main content
QUICK REVIEW

[Paper Review] Danger of using fully homomorphic encryption: A look at Microsoft SEAL

Zhiniang Peng|arXiv (Cornell University)|Jun 17, 2019
Cryptography and Data Security2 references4 citations
TL;DR

This paper exposes critical security vulnerabilities in Microsoft SEAL, a widely used fully homomorphic encryption (FHE) library, demonstrating that practical use of its IntegerEncoder leaks sensitive information about plaintext operands through ciphertext behavior. Despite FHE's theoretical security, the paper reveals that encoding schemes like IntegerEncoder in SEAL can lead to information leakage, CCA attacks, and integrity issues, rendering applications insecure even when the underlying FHE primitive is secure.

ABSTRACT

Fully homomorphic encryption is a promising crypto primitive to encrypt your data while allowing others to compute on the encrypted data. But there are many well-known problems with fully homomorphic encryption such as CCA security and circuit privacy problem. Despite these problems, there are still many companies are currently using or preparing to use fully homomorphic encryption to build data security applications. It seems that the full homomorphic encryption is very close to practicality and these problems can be easily mitigated in implementation. Although the those problems are well known in theory, there is no public discussion of their actual impact on real application. Our research shows that there are many security pitfalls in fully homomorphic encryption from the perspective of practical application. The security problems of a fully homomorphic encryption in a real application is more severe than imagined. In this paper, we will take Microsoft SEAL as an examples to introduce the security pitfalls of fully homomorphic encryption from the perspective of implementation and practical application

Motivation & Objective

  • To investigate the real-world security risks of deploying fully homomorphic encryption (FHE) in practice, particularly focusing on Microsoft SEAL.
  • To demonstrate that even though FHE primitives are theoretically secure, practical implementations like SEAL introduce severe vulnerabilities through encoding and protocol design.
  • To highlight that common assumptions about FHE security—such as circuit privacy and CCA resistance—do not hold in actual deployments.
  • To show that encoder design in SEAL (especially IntegerEncoder) leaks information about plaintext operands, undermining privacy guarantees.
  • To advocate for caution in using FHE libraries for privacy-preserving applications and to call for stronger security standards in FHE deployment.

Proposed method

  • Analyzed Microsoft SEAL's BFV homomorphic encryption scheme, focusing on the IntegerEncoder and BatchEncoder components.
  • Constructed a multiparty computation scenario (Millionaires’ Problem) to demonstrate how encoding choices leak information about individual inputs.
  • Evaluated the impact of homomorphic operations (addition and multiplication) on ciphertexts to show that different plaintext pairs produce distinguishable ciphertexts.
  • Identified that noise flooding techniques cannot mitigate encoding-based information leakage in SEAL’s IntegerEncoder.
  • Explored the lack of authenticated encryption in FHE, showing that attackers can modify ciphertexts without detection.
  • Proposed using BatchEncoder instead of IntegerEncoder to avoid encoding leakage, treating the latter as a demonstrative tool only.

Experimental results

Research questions

  • RQ1To what extent does the IntegerEncoder in Microsoft SEAL leak information about the plaintext operands through distinguishable ciphertexts?
  • RQ2How do practical implementations of FHE, such as Microsoft SEAL, fail to provide circuit privacy despite theoretical guarantees?
  • RQ3What are the real-world implications of chosen-ciphertext attacks (CCA) in FHE libraries like SEAL?
  • RQ4Why is the absence of authenticated encryption in FHE libraries a critical security flaw for data integrity?
  • RQ5Can existing countermeasures like noise flooding effectively prevent information leakage in FHE encoding schemes?

Key findings

  • The IntegerEncoder in Microsoft SEAL is many-to-one, causing different plaintext pairs to produce distinguishable ciphertexts, thereby leaking information about the operands.
  • Even when the final decrypted result is the same (e.g., sum = 4), the intermediate ciphertexts differ depending on the input values (e.g., (1,3) vs. (2,2)), enabling an attacker to infer the original inputs.
  • The paper demonstrates that an attacker can reconstruct individual inputs in a multiparty computation setting by observing only the sum ciphertext, proving that encoding leakage undermines privacy.
  • Noise flooding does not mitigate this leakage because the distinguishability arises from the encoding structure, not noise levels.
  • FHE libraries like SEAL do not provide authenticated encryption, allowing an adversary to modify ciphertexts without detection, compromising data integrity.
  • The security risks are not limited to SEAL but apply broadly to other FHE libraries, indicating a systemic issue in practical FHE deployment.

Better researchstarts right now

From reading papers to final review, dramatically reduce your research time.

No credit card · Free plan available

This review was created by AI and reviewed by human editors.