For a 2.19-megapixel test photo, ZK-JPEG turned a 6.3MB bitmap into a 971KB JPEG, then sent 34.08GB from the prover for the Poseidon-based proof. That ratio frames the achievement in a new cryptography paper: a publisher can prove that a JPEG came from a committed source image and passed through declared edits, even though lossy compression changed the pixels. The working prototype is still sized for an institutional pipeline, not a phone sharing a photo.
The ZK-JPEG paper, written by Samuel Dittmer, Steve Lu, Kimberlee Model and Joseph Near, was posted to the Cryptology ePrint Archive in September and is listed as published at SCN 2026. The authors describe it as the first implementation of lossy photo compression inside a zero-knowledge proof. That missing compression step matters because normal image handling can break a cryptographic link before a reader ever sees the file.
The signature can fail during an ordinary export
A camera can sign the image it captures. A viewer can then check that signature against the camera manufacturer's certificate chain. Change even a small part of the signed file, however, and a conventional signature no longer matches. JPEG does exactly that on purpose: it throws away some image information to reduce the file size. Cropping, colour correction, blurring a face or adding a watermark creates the same continuity problem.
The current C2PA 2.4 specification handles provenance through signed claims. Assertions can describe creation details and edit actions, while cryptographic bindings associate the manifest with the asset. C2PA is careful about the boundary of that system. Its specification says validation checks that assertions are associated with the asset, correctly formed and free from tampering; it does not decide whether the provenance data is good or bad.
ZK-JPEG tackles a narrower issue inside that boundary. A signature can show who signed a claim, yet the verifier may still have to trust editing software to report its work accurately. The paper adds a mathematical proof that a declared transformation plan actually maps the committed input image to the published output. The original image stays private during that check.
Compression becomes part of the statement
The prover starts with a private 24-bit RGB bitmap, its attestation and a public transformation plan. The verifier receives the output photo, the plan, the source image's commitment and the proof. In the paper's formal statement, the secret input must hash to the published commitment and produce the public output when the declared transformations run. A valid proof ties those two conditions together.
JPEG makes this expensive because compression is a chain of pixel operations. Baseline JPEG converts RGB data into luminance and colour channels, reduces the resolution of the colour channels, applies a discrete cosine transform to 8-by-8 blocks, then quantises the resulting frequencies. Those are the operations that alter the image. ZK-JPEG performs them inside the proof circuit. The final Huffman coding is lossless, so it can happen afterward; a verifier can decode the published file back to the exact quantised blocks checked by the proof.
The design also folds useful edits into that compression pass. It supports contrast and brightness adjustments, white balance, greyscale, box blur, transparency layers and regional redaction. Several colour operations can be combined with JPEG's own colour conversion. Blur and transparency can work on the smaller chroma channels. The authors also use stronger local quantisation to obscure a region with conspicuous JPEG artefacts, providing another form of redaction.
This is the paper's most useful engineering idea. Proving each edit as a separate full-image computation would make an already large circuit worse. Reusing steps that JPEG must perform anyway keeps most edits close to the cost of compression itself. It also gives the verifier a readable edit plan instead of a bare assurance that some approved program ran.
The benchmark is both result and warning
The authors tested on two four-core AWS instances with 16GiB of memory. Their medium image measured 1,800 by 1,216 pixels. With JPEG compression and a Poseidon commitment, the offline PicoZK stage took 664.52 seconds and the interactive LPZK stage took 331.76 seconds under their verifier-side method. The prover sent 34.08GB. Switching the commitment to SHA-256 raised the two reported times to 4,504 seconds and 2,856.93 seconds, with 265.21GB sent by the prover.
Those numbers depend heavily on the chosen proof backend. The authors used LPZK because it keeps prover work and memory down, accepting much higher communication and verifier cost. It is interactive and designed for a designated verifier. The paper does not offer a small, reusable proof that any visitor could check in a browser. Its comparison with earlier systems also warns that different commitment schemes and hardware make direct rankings difficult.
The edit operations themselves are much cheaper than the proof of JPEG. On the medium image with no commitment, plain JPEG took 378.47 seconds in PicoZK and 278.98 seconds in LPZK. Adding greyscale moved those figures to 383.62 and 279.27 seconds. A full-image box blur was heavier at 426.81 and 312.60 seconds. The result supports the authors' decision to place edits inside compression, even as the total job remains slow.
Scaling is roughly linear in pixel count in their tests, with some loss of throughput on larger files. A 10.04-megapixel image, measured without a commitment, took 1,993.81 seconds in PicoZK and 1,512.65 seconds in LPZK. PicoZK used about 6.8GB of memory for that run. The no-commitment figures isolate the JPEG circuit's cost; they are not a secure deployment configuration.
A proof of process is not proof of a scene
A valid ZK-JPEG proof says the disclosed computation was performed on the committed source. It cannot establish that the camera saw an unstaged event. Someone could photograph a screen, arrange a misleading scene or publish an authentic image with a false caption. The paper states these limits directly. Cryptography can preserve a chain of custody without turning the camera into an arbiter of truth.
The prototype also starts from 24-bit RGB bitmap images for simplicity, while professional cameras often use higher-bit-depth RAW or DNG files. It does not prove photographer anonymity or authenticated metadata redactions. The authors outline possible extensions for both, including a second proof that traces a signing key to a root certificate without revealing the photographer's public key. Those extensions were outside this implementation.
Existing camera signatures may need changes too. The paper's appendix argues that input-dependent decoding can make signed JPEGs awkward for zero-knowledge circuits. It suggests signing data at a point before Huffman coding, or using a partially processed format between RAW and JPEG. Either approach asks camera makers and editing tools to agree on where the verifiable handoff occurs.
The next test is a real publishing pipeline
The authors see the present interactive system as plausible for organisation-to-organisation proofs. A newsroom, archive or verification service is a more believable first setting than a consumer social feed, because two institutions can arrange the verifier connection and absorb large transfers. That deployment path is an inference from the paper's design, not a product plan announced by the researchers.
A practical follow-up would pair camera attestation with an actual edit, JPEG export and independent verification, then publish the implementation and measure the full network cost. A succinct backend would have to cut the 34.08GB transfer without pushing prover time or memory beyond what a newsroom can operate. Until that happens, the figure to watch is the gap between the 971KB image people receive and the proof traffic required to vouch for how it got there.