KeHoSu: Keyed Homoglyph Substitution for Authenticated Text Provenance over Copy-Paste Channels: what it means for business leaders

A keyed scheme writes an authenticated platform-and-account identifier into the choice between Latin letters and identical-looking Cyrillic ones, so a copied excerpt of about one or two sentences can be traced back to the account it was served to.

1. What the method is

KeHoSu marks finished text after it is generated. For each carrier letter (a, c, e, i, j, o, p, s, x, y and their capitals), it writes either the Latin code point or the Cyrillic look-alike that most fonts draw identically, and each choice stores one bit. Those bits hold an identifier made of a platform field, a user field and a truncated authentication tag, encrypted and sealed with AES-256-GCM-SIV under a key that rotates by epoch. Which part of the code a given letter carries depends on a keyed hash of the text around it, not on the letter's position. That is why the mark survives reordered sentences, partial quotes and light edits. An asymmetric mode adds a signature: anyone with the public key can confirm the platform of origin, while only the platform can read the user field. The scheme works on any text from any model and can sit on top of generation-time watermarks such as SynthID.

2. Why the method was developed

Text that matters to a moderator or investigator rarely moves as a file. It is quoted, reposted and forwarded by copy-paste. That strips file metadata such as C2PA content credentials but keeps Unicode code points. Generation-time watermarks change the token distribution of one model, mostly give a yes-or-no or low-bit signal of machine origin, and need long samples: the authors cite about 800 tokens after strong human paraphrasing. Zero-width-character schemes are removed by common input filters, and one of them places its whole message in a single block, which a quote starting after that block loses. The closest earlier homoglyph scheme writes one digit per letter in reading order, with no key and no error correction, so one deleted letter early in the text or any sentence reordering destroys it. The authors wanted a mark that carries a full account identifier, cannot be forged without the key, and survives how people actually reshare text.

3. Who should care

Trust and safety teams get a way to tie a suspicious post back to the platform and account that first received the text, provided that platform marks its output. Product and security leads at companies that serve LLM output could offer per-account marking without touching the model. Security and data-loss teams could mark each recipient's copy of an internal document, so that a leaked excerpt names the person it was sent to. That is probably the cleanest use, because there the people copying the text are not trying to strip the mark. Legal and policy staff should note that the asymmetric mode lets outside investigators confirm where text came from without the platform revealing which user received it. Engineering teams that index, search, compare or deduplicate text should expect marked copies to contain Cyrillic letters inside English words. That is our own concern, not something the paper tests, and our text pipelines would need to normalize confusable characters before they compare strings.

4. How the method works

The embedder seals the identifier, then expands it with a random linear fountain code, which can rebuild the payload from any large enough set of correctly received coded bits. For each carrier letter, it takes a window of surrounding characters, folds every carrier in that window to its Latin form, lower-cases it, and hashes it with BLAKE2b under the key. The hash picks which coded bit the letter writes. The window is cut at sentence boundaries, so each letter's assignment depends only on its own sentence, and dropping or reordering other sentences changes nothing. An edit only disturbs the letters whose windows it overlaps. Letters with identical contexts carry the same bit, and the decoder takes a majority vote across them. To decode, the extractor reads each letter's variant, recomputes the hashes, skips a thin layer of letters at both ends of the excerpt, solves the system using the bits with the strongest votes, retries up to eight times, and accepts only when the authentication tag checks out.

5. How it was evaluated

The authors tested three Project Gutenberg books (Pride and Prejudice, On the Origin of Species and The Federalist Papers) and 40 stories written by Claude Haiku 5.5. For the copy-paste test, they pasted marked text into 18 services and copied it back out, among them X, Facebook, Instagram, WhatsApp Web, Signal, Telegram, Discord, Teams, Gmail, Proton Mail, Google Docs, Google Sheets and Apple Notes. They measured: every sentence order; random sentence subsets and character excerpts, to find the shortest excerpt that still decodes; documents split into shuffled pieces; scattered substitutions, deletions and insertions compared with one contiguous run of edits; and pure erasures. They also tried two alternative decoders, a consensus search and a Reed–Solomon outer code. Other tests covered false accepts on unmarked text with random variants and on plain Latin text, splices of two users' marked text, and a direct comparison with the earlier position-based homoglyph codec. The arXiv rendering we read drops many trial counts and percentages, so this briefing reports only the figures the text keeps.

6. How it performed

The identifier survived all 18 services. Most excerpts were attributed to the correct account from 167 letters on the books (about one sentence) and 178 letters on the stories (about two). Below that length the scheme is unusable. At the decoding threshold, no reordering of sentences changed the result, except in very short documents. Splitting a document at sentence boundaries cost nothing: half a post spread over thirteen replies decoded like one excerpt. Scattered edits did much more damage than the same number of edited characters in one run. Recasing had no effect. No unmarked sample was accepted. A short fragment from one user, appended to a longer text from another user, was never attributed to the first user. The positional codec failed under reordering, but KeHoSu recovered in every case. The authors' own analysis shows the main limit: a simple mixed-script check finds the mark, and anyone who normalizes confusable characters erases it, so it only works against people who are not trying to remove it. Our call: pilot it, for tracing leaks of internal documents, not as a defense against determined adversaries. (Source: arXiv 2611.08046, 2026)