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
- What happened
- The attack needs a CKKS deployment that exposes both public coefficient-to-slot evaluation material and a validity-dependent response.
- 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.
- What remains unproven
- 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.
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. Primary analysed source date: 15 October 2026. Earliest linked supporting source: 30 September 2026.
Read the full report · 4 min The evidence, methods, implications and limitations
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]