# Keleusma Research Spike: What Happens When Error Correction Meets a Signature

DevFeed: [Keleusma Research Spike: What Happens When Error Correction Meets a Signature](<https://devfeed.tech/articles/keleusma-research-spike-what-happens-when-error-correction-meets-a-signature-39756.md>)

Original publisher: [Read original article](<https://sgeos.github.io/engineering/compilers/verification/security/2026/08/10/when_error_correction_meets_a_signature.html>)

Author: Brendan Sechter

Published: 2026-08-10T09:00:00Z

Content type: article

Language: en

Sources: [Brendan A R Sechter's Development Blog](<https://devfeed.tech/sources/brendan-a-r-sechter-s-development-blog.md>)

Topics: [Security, Privacy and Abuse Prevention](<https://devfeed.tech/topics/security-privacy-and-abuse-prevention.md>), [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [Code](<https://devfeed.tech/topics/code.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>)

Tags: [bytecode](<https://devfeed.tech/tags/bytecode.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [compilers](<https://devfeed.tech/tags/compilers.md>), [cryptographic](<https://devfeed.tech/tags/cryptographic.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [integrity](<https://devfeed.tech/tags/integrity.md>), [research](<https://devfeed.tech/tags/research.md>), [security](<https://devfeed.tech/tags/security.md>), [test](<https://devfeed.tech/tags/test.md>), [verification](<https://devfeed.tech/tags/verification.md>)

## AI overview

This case study examines how combining error correction with cryptographic signatures can create an unsafe verification order. Exhaustive analysis of bit errors shows that some damaged inputs are incorrectly repaired or reported as clean, so a clean correction result does not establish integrity.

## Source excerpt

A file carries an error-correcting code so that a flipped bit can be repaired, and a cryptographic signature so that a changed byte is refused. Both are ordinary. Putting them in the same file forces a choice that neither feature announces, and one of the two answers is sound only under an assumption that the error-correcting code exists because it is false. The uncomfortable part is that the two answers are indistinguishable on every input anybody tests. An undamaged file behaves identically under both. They diverge only on damaged input, and damaged input is the case the error-correcting code exists for and the case no test suite exercises, because producing it requires deliberately corrupting your own artefact. Enumerating the fault space of a single 64-bit word exhaustively, rather than sampling it, gives four numbers that decide the design. The space is small enough to enumerate because the number of ways to flip $w$ bits out of 64 is a binomial coefficient, and for $w \le 4$ it stays under a million. \[\binom{64}{1} = 64, \quad \binom{64}{2} = 2{,}016, \quad \binom{64}{3} = 41{,}664, \quad \binom{64}{4} = 635{,}376\] flipped bits patterns repaired exactly wrongly "repaired" invisible 1 64 64 0 0 2 2,016 0 0 0 3 41,664 0 23,364 (56.08%) 0 4 635,376 0 0 5,133 (0.81%) Three flipped bits are reported as a successful repair 56.08 percent of the time, and the repair is wrong every time it happens. Four flipped bits are, 5,133 times, completely invisible, because the code reports the word as clean when the error pattern is itself a valid codeword. The consequence is one sentence, and everything else in this article is either its derivation or its implications. The corrector is not an authority on whether it corrected, and a clean report from it is not evidence of integrity. What this is a case study of The setting is the bytecode format for Keleusma, a language whose value proposition is that a program's worst-case time and memory can be proven before it runs, and wh