Steganography Encoder And Decoder Design For Protocol5 IOTA - Source Excerpt 02 - Mapping each method to the Iota converter

Back to Steganography Encoder And Decoder Design For Protocol5 IOTA

Summary

This source excerpt begins near Mapping each method to the Iota converter and preserves the surrounding evidence from Spiralist/agent-file-handoff/Archive/Steganography Encoder and Decoder Design for Protocol5 Iota.md.

**Source path:** Spiralist/agent-file-handoff/Archive/Steganography Encoder and Decoder Design for Protocol5 Iota.md

Zero-width Unicode systems hide bits in invisible characters. The long-running `unicodeSteganographer` project documents a 4-character default alphabet using `U+200C`, `U+200D`, `U+202C`, and `U+FEFF`, implying a payload of about **2 bits per inserted invisible symbol**; it also notes that `U+200B` can be deleted by Gmail in browser mail composition. A recent open-source tool, StegZero, makes the capacity trade-off explicit: an 8-character zero-width alphabet yields **3 bits per symbol**, while a 2-character binary alphabet using `U+200B` and `U+200C` yields **1 bit per symbol** but is more likely to survive aggressive sanitization. citeturn34view0turn35view0

Homoglyph techniques encode data by substituting visually similar characters from different scripts or Unicode blocks. Unicode’s own security standard, UTS #39, treats these as **single-script**, **mixed-script**, and **whole-script confusables**, and provides confusable-detection mechanisms precisely because they are security-relevant. In practice, this means homoglyph stego can be easy for humans to miss but relatively straightforward for software to detect with confusable skeletons and script-mixing rules. Open-source libraries such as `codebox/homoglyph` exist specifically to detect such substitutions. citeturn18search1turn18search2turn36view0

Linguistic schemes use meaning-preserving substitutions or paraphrases rather than invisible formatting. Atallah and colleagues’ early natural-language watermarking work embeds watermark bits in syntactic structure, while Chang and Clark’s work develops more practical synonym-based linguistic steganography with contextual filtering and vertex coding. More recent neural and distributional methods can push capacity upward; for example, a 2026 CBOW-based linguistic stegosystem reports **up to 3 bits per word** by selecting among the top eight predicted candidates, though that is not specific to Iota and should be viewed as a cover-text result rather than a converter guarantee. These schemes are often more semantically natural than format hacks, but they are also vulnerable to paraphrase, editing, and language-model steganalysis. citeturn17search0turn16search1turn16search2turn16search3turn17search2turn15search0turn14search7

Generated linguistic steganography goes further by using a language model itself as the carrier generator. Ziegler, Deng, and Rush show that arithmetic coding with a neural language model can generate cover text while matching the model distribution, which is attractive from a security perspective because the generation process aims to stay on-distribution. But implementation complexity is high, and this family is conceptually orthogonal to Iota: it creates a new language model channel, rather than using Iota itself as a stable deterministic codec. citeturn38view0

Markup-based steganography uses the fact that some source-level structure is not visible in the rendered page. SOAP and webpage steganography papers show payloads hidden through element ordering or other source-level transformations that leave the rendered page looking the same. This makes markup methods especially relevant whenever Iota output is carried inside HTML, XML, or a structured protocol surface. The upside is that the visible Iota string can remain untouched; the downside is that reserialization, minification, canonicalization, or copy-paste to plain text may destroy the payload. citeturn37search6turn37search2

Image and audio steganography are not native to Iota, but they become relevant whenever the Iota output is rendered into another medium. Classical image methods include high-capacity **LSB** embedding and more resistant schemes such as **F5**, which uses matrix encoding and permutative straddling to reduce detectable changes. MP3-oriented audio schemes likewise exploit compressed-audio structure. These are stronger fits when the intended transport is a screenshot, a poster, a video overlay, or audio narration of Iota output, rather than raw Iota text itself. citeturn26search0turn28search0turn27search3turn27search6

The following comparison table is the report’s engineering synthesis of the public sources. Capacity is intentionally heterogeneous because the underlying carriers differ; where source material gives units like bits per symbol or bits per appended columns, those are preserved rather than forced into a misleading common denominator.

| Method | Capacity | Detectability | Robustness | Complexity | Suitability for Iota |
|---|---|---:|---:|---:|---|
| Markup sidecar or source-level metadata | High if explicit metadata is allowed; low-to-medium if only source-order permutations are used | Low in rendered view, medium-to-high in source inspection | Medium in stable HTML/XML pipelines; low across reserialization or copy-paste to plain text | Low to medium | **High** |
| Zero-width Unicode | 1 bit per inserted symbol with binary alphabets; 2 bits with 4-char sets; 3 bits with 8-char sets | Low to humans, medium-to-high to scanners | Low to medium, highly channel-dependent | Low to medium | **Medium** |
| Trailing whitespace or SNOW-style | About 3 bits per 8 appended columns | Medium once whitespace is rendered or diffed | Low on web, email, or editor pipelines that trim or wrap | Low | **Low** |
| Homoglyph or confusable substitution | Usually about 1 bit per substituted character in binary pair schemes; more if larger confusable classes are curated | High with UTS #39-style checks | Medium visually, low against security-aware systems | Medium | **Very low** |
| Synonym or paraphrase substitution | Often about 1–3 bits per eligible word or phrase, depending on vetted alternatives | Medium under language-model or semantic steganalysis | Medium in human prose, but low under Iota’s approximate ranking | High | **Low / experimental** |
| Syntactic transformations | Often about 1 bit per eligible sentence for binary transforms | Medium with parsing or style analysis | Medium | High | **Low / experimental** |
| Neural generated text stego | Variable; potentially medium-to-high per token | Medium, distribution-dependent | Medium | Very high | **Low** as an Iota-coupled method |
| Image or audio wrapper around rendered Iota | High in absolute payload, method-dependent | Low to medium depending on algorithm and steganalysis | Medium to high if compression-aware | Medium to high | **Medium to high** |

These comparative judgments are grounded in the cited method descriptions and in Iota’s explicit public-symbol, normalization, and segmentation rules. citeturn33view1turn34view0turn35view0turn18search1turn36view0turn17search0turn16search1turn38view0turn37search6turn26search0turn3view4turn4view0

## Mapping each method to the Iota converter

The central design question is *where* to place the covert layer relative to Iota’s own pipeline. Because Iota splits input into sentences and segments, ranks concepts approximately, and treats visible glyphs as evidence rather than authority, **pre-conversion** steganography is fragile unless the covert information is carried in a way that does not perturb stored-segment matching or concept ranking. By contrast, **post-conversion** steganography can preserve the visible Iota result and therefore respects the converter’s own interpretability model. citeturn3view0turn3view3turn3view4turn4view0

A useful design rule is therefore:

' ' ' mermaid
flowchart TD
    A[Need covert channel around Iota] --> B{Must visible Iota text stay unchanged?}
    B -->|Yes| C{Carrier can be structured markup?}
    C -->|Yes| D[Use markup sidecar or source-level wrapper]
    C -->|No| E{Plain-text channel preserves zero-width chars?}
    E -->|Yes| F[Use post-conversion zero-width encoding]
    E -->|No| G[Render Iota into image or audio and hide there]
    B -->|No| H{Can both parties inspect pre-conversion text or trace?}
    H -->|Yes| I[Experimental semantic or syntactic encoding]
    H -->|No| J[Avoid linguistic stego with Iota]
' ' ' 

That decision rule follows directly from Iota’s documented approximate semantics and Unicode handling, together with the known robustness profile of text-stego methods. citeturn3view4turn4view0turn35view0turn37search6turn26search0

Applied method-by-method, the fit looks like this. **Markup sidecar** is strongly feasible when the Iota output lives in HTML, XML, UAI-like envelopes, or other structured records, because the visible string can remain exactly the same while the payload rides in source-level structure. Preprocessing is minimal: convert English to Iota first, then wrap the returned glyphs. Postprocessing extracts metadata or source-level order and verifies that the displayed text still matches the original Iota glyph sequence. Capacity is effectively limited by the surrounding transport rather than by Iota itself, which is why this is the best fit. citeturn37search6turn37search2turn3view4