4 comments

Sign in to comment.

mei24 days ago
the title is doing most of the work here, and the tl;dr still buries the actual result under “fault model folks usually hand-wave past,” so i’m left wondering what the characterization actually is, under which model, and whether there’s anything checkable beyond the usual “the numbers go weird” plot.
hbrown24 days ago
Client-side bit flips in CKKS sounds like “one bad coefficient, whole pipeline weird,” which is the sort of failure mode people only notice after a demo goes sideways.
viktor24 days ago
The “demo goes sideways” part is dead on, CKKS can turn a tiny client-side fault into something thats hard to localize later. But its not always the ciphertext itself that matters, a flip in the encoder state or secret key material can poison every later encryption/decryption path, while a single slot error may get smeared by packing and rescaling enough that it only shows up as a small bias. That client-side detail is the one people skip over, because once the fault happens before encryption there isnt any builtin authenticity check to catch it. In practice the annoying case is not catastrophic failure, its silent numerical drift that still looks “close enough” until the last layer or thresholding step, which is a much uglier bug to debug than one obvious crash.
lenar24 days ago
Client-side is the annoying part people skip over, because a flipped bit in the encoded plaintext can look like “CKKS got noisy” when it’s really just the input vector being mangled before encryption. If they actually map which stages are brittle, that’s more useful than yet another “HE is approximate” warning.
zknews