One error bit was enough to recover encrypted-computing keys
Researchers recovered CKKS secret keys in a controlled implementation by repeatedly observing valid-or-invalid responses. The accepted security paper targets a specific deployment pattern, not the encryption scheme in every use.
The short version
3 key points
- 1.The attack needs a CKKS deployment that exposes both public coefficient-to-slot evaluation material and a validity-dependent response.
- 2.A Lattigo 6.2.0 implementation recovered complete ternary keys across five parameter triples; the sparse-key variant used 1,801 reactions in one 65,536-coefficient setting.
- 3.The work attacks the surrounding protocol, not the RLWE assumption or CKKS encryption primitive, and does not establish a breach of a live service.
A yes-or-no response became a key oracle
A client can encrypt data with CKKS, let an outside server compute on the ciphertext and then decrypt the result. The new paper shows how that privacy promise can fail when the client also reveals whether each returned result passed a validity check. In the researchers' construction, a malicious evaluator reshaped public evaluation material so that the client's single valid-or-invalid bit disclosed whether one secret-key coefficient was zero. A second query distinguished positive from negative coefficients.[1]
Who it affects
Encrypted AI services are meant to keep medical, financial or business data private from the evaluator; a protocol-level key leak could undo that protection even when the core mathematics remains sound.[1][2]
Keep in mind
Controlled implementation rather than a documented live breach; specific CKKS key and response surface required; no total repeat-run denominator; accepted conference paper but final proceedings version is not yet available.
Multi-source analysis · 2 linked sources. Original source date: 15 October 2026.
Read more The full report, methods and context
A yes-or-no response became a key oracle
A client can encrypt data with CKKS, let an outside server compute on the ciphertext and then decrypt the result. The new paper shows how that privacy promise can fail when the client also reveals whether each returned result passed a validity check. In the researchers' construction, a malicious evaluator reshaped public evaluation material so that the client's single valid-or-invalid bit disclosed whether one secret-key coefficient was zero. A second query distinguished positive from negative coefficients.
Repeating those tests recovered a full ternary secret in no more than twice the ring dimension. Each malicious ciphertext was re-randomised with a fresh encryption of zero, so a filter looking only for identical resubmissions would miss the pattern. This is a protocol attack: the authors explicitly do not break the underlying Ring-Learning-With-Errors assumption or CKKS's chosen-plaintext security. A deployment must expose the relevant coefficient-to-slot keys and an observable reaction for the method to apply.[1]
The laboratory attack worked across standard-style parameters
The team implemented the attack in Lattigo 6.2.0 and swept five parameter triples spanning ring dimensions of 4,096, 16,384 and 65,536 coefficients and several precision settings. It tested the library's uniform and fixed-weight ternary secrets, then extended the analysis to additional ternary and discrete-Gaussian distributions. The paper reports exact recovery across the tested configurations and measured the intermediate noise margins rather than assuming them.
Sparse keys made the query count smaller. Across Hamming weights of 32, 64 and 128 and the three ring dimensions, the method recovered every tested support without false positives or negatives, then used lattice reduction to recover the signs. At dimension 65,536 with weight 128, it required 1,801 validity queries instead of 65,664 for the direct two-pass method. The reported single-core sign-solving time rose from 0.4 seconds at weight 32 to 25 minutes at weight 128. The manuscript does not give a denominator of repeated independent runs, so the result should not be read as a field failure rate.[1]
The distinction that matters
Where the leakage entered
The cryptography stayed intact; the surrounding response channel exposed one useful bit at a time.
Craft
Server sends a re-randomised ciphertext
One coefficient is tested
React
Client reveals valid or invalid
A key bit leaks
Repeat
Queries cover support and signs
The secret key is reconstructed
The practical fix is to stop signalling the answer
The authors' clearest mitigation is operational: return the same externally visible response whether the decrypted output is accepted or rejected, and handle failure internally. Where that is impossible, they recommend per-key caps and monitoring for unusual rejection rates and query volumes. Merely adding noise can damage honest computations before it reliably removes the signal, while the fresh randomisation means duplicate-ciphertext blocking is not enough.
Korea University says the collaboration with Beihang University, the University of Luxembourg and Jeonbuk National University has been accepted for IEEE S&P 2027. The accessible manuscript is still the author version; it states no funding or competing-interest declaration. For teams outsourcing encrypted AI inference, the immediate lesson is not to abandon homomorphic encryption. It is to threat-model the whole exchange around decryption, especially error handling. Confidence would rise through independent reproduction in other libraries, tests against real service protocols and public evidence that deployed systems have removed validity-dependent responses.[1][2]
Evidence check
Controlled implementation rather than a documented live breach; specific CKKS key and response surface required; no total repeat-run denominator; accepted conference paper but final proceedings version is not yet available.
Reporting basis: Multi-source analysis. Original source date: 15 October 2026.
Explore the full source and evidence record
What this means for people
- Encrypted AI services are meant to keep medical, financial or business data private from the evaluator; a protocol-level key leak could undo that protection even when the core mathematics remains sound.
Global context
The research team spans China, Luxembourg and South Korea, while CKKS libraries and privacy-preserving computation services are used internationally. Applicability depends on each service's released keys and error-handling protocol, not its country.
What the evidence does not yet show
- Controlled implementation rather than a documented live breach; specific CKKS key and response surface required; no total repeat-run denominator; accepted conference paper but final proceedings version is not yet available.
What to watch next
- Independent library reproductions, coordinated vendor advisories, audits of validity-dependent responses, and evidence that per-key monitoring catches the query pattern without exposing new side channels.
Living evidence record
Impact record IAI-0579EPD
Evidence stage
Studied
Confidence
Supported
Reporting basis
Multi-source analysis
Independent or research support
Present
Record status
Monitoring
Last checked
17 October 2026
Source trail
2 direct sources across 2 source types.
People impact
Documented in this record.
Uncertainty
Limits and next checks are explicit.
Stages describe the evidence available—not whether a technology is good or bad. See the public method.
Evidence trail
Sources used for this report
Links checked 17 October 2026
Research question, topics and regions
Whether a malicious evaluator can recover CKKS secret keys from a client's one-bit validity response when public coefficient-to-slot evaluation keys are exposed
Topics: Homomorphic encryption · Privacy-preserving AI · Key recovery · Protocol security · Cloud computing
Regions: China · Luxembourg · South Korea · Global
This report is labelled multi-source analysis. We summarise and analyse source material in our own words; company statements remain attributed claims until independently supported. Translated summaries preserve the meaning of the original source and link back to it. Read our editorial standards.
The Impact Brief · Free
Keep following the stories that matter to you.
Get our weekday briefing on what changed and why it matters. Choose your topics below.
Continue the story
There’s more to this story
Security & Defence
When an AI agent hits a blocked website, should it keep trying?
A new investigation traces agents seeking Amap information through Tencent Cloud infrastructure. Tencent acknowledges unintended browsing while disputing that its Hunyuan models were responsible. The model identity remains uncertain.
2 min · 2 sources
Security & Defence
Can a high score prove an Android-malware AI is reliable?
No. A peer-reviewed review of 61 studies and a controlled test on 11,598 apps found that clean benchmark accuracy concealed class-specific misses and sensitivity to masked features—and still did not reproduce real attacks or deployment.
2 min · 2 sources
Security & Defence
Do specialist tools amplify AI biosecurity risk?
A China-based preprint tested 15 frontier models on 30 mutation-design scenarios against 187,695 existing laboratory measurements. Tool-assisted iteration shifted selected variants further into high-risk assay regions, but the benchmark covers single substitutions—not end-to-end pathogen creation.
2 min · 2 sources
Reader commentary
What does this mean where you are?
Tell us what you have seen at work, in your community or in everyday life. A question is welcome too. No account is needed; we review notes before publishing them.
Explore commentary across the portal →Published reader notes
0No published reader notes yet. You can start the evidence-led discussion above.
Prefer a private correction or response? Contact the newsroom.