What Happened
A research team has developed a fully homomorphic encryption (FHE) scheme with chosen-ciphertext attack (CCA) security, based solely on the learning with errors (LWE) assumption in the standard model. This scheme offers stronger security than CCA1 without relying on the random oracle model or non-falsifiable assumptions, which previous CCA-secure FHE constructions required.
This isn't a breach but a cryptographic milestone that shifts the security assumptions your team may need to evaluate in the future.
Timeline
Pre-2012: FHE schemes existed but only with chosen-plaintext attack (CPA) security. Attackers could potentially break these systems by submitting chosen ciphertexts for decryption.
2012-2024: Researchers developed FHE with CCA1 security, but only by incorporating the random oracle model or non-falsifiable assumptions.
Current: The new construction matches the circular-secure LWE assumption needed for basic CPA-secure FHE, offering security against chosen-ciphertext attacks. The team replaced general zero-knowledge succinct non-interactive arguments of knowledge (ZK-SNARKs) with a specialized succinct argument built from batch arguments for NP and a new primitive called predicate extractable commitment.
Missing Controls in Payment Environments
This isn't an incident report, but if you're managing a payment environment, consider what's currently lacking:
No encryption scheme in PCI DSS 4.0 Requirement 3 protects Cardholder Data during computation. You encrypt data at rest (Requirement 3.5.1) and in transit (Requirement 4.2.1). However, when you decrypt a Primary Account Number (PAN) for authorization, tokenization, or fraud scoring, it remains unencrypted in memory.
FHE could allow computations on encrypted PANs without decryption. Until now, FHE schemes with meaningful security against adaptive attacks required unverifiable assumptions in production.
Current cryptographic controls assume attackers can't choose what gets encrypted. CPA security, used in most Point-to-Point Encryption (P2PE), protects against passive observation of ciphertexts. It fails if attackers can submit chosen ciphertexts and observe results. In complex payment flows, this isn't just theoretical.
Lack of a framework for evaluating post-quantum cryptographic claims. LWE is a lattice-based problem believed to resist quantum attacks. When vendors claim "quantum-resistant Point-to-Point Encryption (P2PE)," your compliance team needs criteria beyond "it uses lattices." The difference between CPA and CCA security will be important.
Relevant Standards
PCI DSS 4.0 Requirement 3.5.1 mandates strong cryptography to render Cardholder Data unreadable. The standard doesn't specify algorithms, but NIST SP 800-175B is referenced for cryptographic strength.
NIST SP 800-175B doesn't mention FHE, and FIPS 140-3 doesn't validate FHE modules. There's no approved mode for homomorphic operations on PANs.
Here's the gap: Requirement 3.3.1.3 allows cryptographic hashes with a salt instead of truncation or one-way hashes under specific conditions. But there's no equivalent for computing on encrypted PANs. Implementing FHE for fraud analysis without decrypting transaction data puts you in uncharted territory for your Report on Compliance.
Requirement 12.3.4 requires maintaining an inventory of cryptographic keys and algorithms. When evaluating FHE, document not just the encryption algorithm but also the homomorphic operation set, noise growth parameters, and security assumption (circular-secure LWE). Your QSA will ask about the impact when ciphertext noise exceeds the scheme's threshold.
Action Items for Your Team
Track lattice-based cryptography now. Add NIST's post-quantum cryptography project to your compliance calendar. When NIST finalizes standards for lattice-based encryption, you'll see vendors claiming "quantum-safe" payment products. Understand the difference between a key exchange algorithm and an FHE scheme that computes on encrypted PANs.
Map your decrypt-then-process workflows. Audit every point where your system decrypts Cardholder Data: authorization routing, fraud scoring, tokenization, reporting. Document computations on plaintext PANs. This is your FHE opportunity surface and current exposure to memory scraping attacks.
Update your cryptographic standards matrix. Your Requirement 3.5.1 documentation likely lists AES-256, RSA-2048, and approved modes. Add a column for "homomorphic properties" and mark it "not currently used." When a vendor proposes FHE, record the security model (CPA vs. CCA), underlying assumption (LWE parameters), and validation status.
Prepare for FHE adoption. The standard won't reference advanced cryptographic constructions until they're widely used. By then, competitors may have implemented them. Build your evaluation framework now: What vendor documentation is needed? What questions about key management for homomorphic operations should you ask? How will you test that encrypted computations match plaintext results?
Understand the CCA security model. If attackers can submit ciphertexts to your payment system and observe outcomes, you're in CCA territory. CPA-secure encryption assumes passive observation, which doesn't fit most payment environments. FHE achieving CCA security under standard assumptions means you can start asking vendors for it.
This construction won't appear in payment terminals soon, but the gap between cryptographic research and deployment is shrinking. Your team's task is to bridge the gap between "theoretically possible" and "compliant and auditable" before your QSA questions unvalidated cryptographic operations on Cardholder Data.
