Author: Jack Kowalski https://entropment.com Patent Pending # Technical Plan for the RIPA Product Code structure and loop with explanations: https://entropment.com/media/downloads/PAPERS_RIPA_QCO_EN.txt Original mathematical explanations: https://entropment.com/media/downloads/PAPERS_notes_for_QCO_in_order.txt 1. Extract the HSM emulator present in the code and move it to an external unit (pluggable via USB or another communication port) with filtered communication (acceptance of commands only, return of a packet only); separate technical input for loading code, keys, etc. (normally such an input is unavailable and the port is usually removed from the board); determine which external module (computer) can perform this - Raspberry Pi, or something weaker (Arduino or FPGA) is sufficient; 2. Prepare a demonstration version of Reed-Solomon (or an equivalent ECC matched to the BER) for the input and output buffers - this is a separate tool; 3. On the tool that accepts buffers under Reed-Solomon, prepare a pipeline for producing fake buffers as input replacing the current random fake-buffer generator; 4. Prepare the application from the prototype version into a production-grade one with memory protection; retain the ability to port to a specific device (Raspberry) and communicate with a computer; this is the communication module itself that accepts message packets (possible to send from any device) and has a fixed architecture plus libm; 5. Integrate the applications and hardware: communication system (e.g. internet) → receiving device (exposed) → airgap → demodulating device with fixed libm + FPU ← airgap ← HSM → demodulated message → ECC → potential client airgap → standard buffer decryption protocol at the client; 6. Potential recipients. ## HSM Feasibility Analysis. 1. ### Goal and functional requirements From the code (HMS_CALL / HMS_RETURN_CURRENT_0, rotate_keyring, history_make, etc.) extract the HSM logic onto a separate device: - Keys (KeyRing) never leave the module. - Communication is exclusively filtered: acceptance of only defined commands, return exclusively of the packed parameter packet ({Mbd, Enoise, QCOpool, Rounds, Flist}). - Separate technical input (provisioning) for loading code, keys and configuration - unavailable in production (physically removed/depopulated or blocked in hardware/software). - Preservation of determinism and result consistency (important for Flist generated from RETURN_BASE_FRACTION / RETURN_FRACTION). - The HSM does not perform heavy sedenion operations or full modulation (CRYPT_MSG_V3) - that remains on the main device. The HSM load is mainly: splitmix/hash, Fisher-Yates on 16 elements, generation of ~52–68 floating-point values (series of roots, powers, divisions). **Option A:** Raspberry Pi Zero 2 W / Compute Module / Pi 4–5; Best for start and production; Full IEEE-754 binary64 + libm (glibc) compatibility, easy USB gadget (CDC serial / HID / custom), low power consumption (Zero), mature tools, easy system lockdown. USB OTG ideal for communication. Preferred; **Option B:** STM32H7 (Cortex-M7 with DP-FPU); Very good; Hardware double-precision FPU (IEEE-754), bare-metal / FreeRTOS, smaller attack surface, lower power consumption, USB device. Strong production alternative (smaller form factor); **Option C:** FPGA; Overkill; cost and time of implementing a reliable IEEE-754 + math (pow/sqrt) unjustified; only for extreme custom requirements (own pathological arithmetic, one-time and with destroyed documentation of the produced pair); Raspberry Pi (especially Zero 2 W or Compute Module in gadget mode) is fully sufficient and is the fastest path to a working prototype and production. STM32H7 is better if the priority is smaller size, lower power consumption and absence of an operating system. ### Communication architecture and security **Production communication interface:** USB (preferred: CDC-ACM serial or custom vendor class / HID). Alternatively UART (if the main device has a dedicated port). Strict binary protocol with a command whitelist: - GET_CURRENT_0 / GET_CURRENT_1 → returns the parameter packet - ROTATE_KEYRING(G) (G as an array of numbers) - GET_HISTORY / snapshot (if needed) - optionally PING / status No general commands, shell, memory read, upload outside provisioning. Optionally: simple session authentication or packet HMAC (if required). **Technical input (provisioning):** Separate port: UART, JTAG/SWD or second USB. Used exclusively in the factory / at first startup for: - flashing firmware, - loading keys (KeyRing), - setting parameters. In production: - physical removal of the connector / depopulation, - or blocking (e-fuse, software flag + read-out protection on STM32, or read-only filesystem + disable SSH/serial on Pi), - optionally: after provisioning the device enters “locked” mode. **Additional safeguards:** - Keys in protected memory (or encrypted with a device-unique key). - Minimal firmware / system (on Pi: locked-down, without unnecessary services; on STM32: bare-metal). - Constant response times where this is important (side-channel). - Physical enclosure hindering access (dongle-style). ### Implementation steps 1. **Logic extraction** Extract clean HSM functions from the prototype (current_0/1, rotate, Flist generation, etc.) into a portable C module (without dependencies on the rest of the application). 2. **Protocol definition** Design a binary format for commands and responses (header + payload + CRC). Implement a parser with a hard whitelist. 3. **Prototype on Raspberry Pi** USB gadget (serial or custom). Implementation in C + libm. Comparison of generated packets with the original emulator (consistency test). 4. **Hardening** Removal of unnecessary services, blocking of debug, read-only mode after provisioning. 5. **STM32 variant (optionally in parallel or later)** Port to STM32H7, verification of floating-point result consistency with the Pi/libm version (or acceptance that all devices with the same firmware produce identical results). 6. **Enclosure and PCB** Dongle with one communication port. Provisioning port available only in the production process. ### Critical remarks The most important thing is result consistency between all legitimate HSMs (same firmware → same packets for the same keys). Compatibility with the original host is not required as long as all parties use the external HSM. Communication must be simple enough not to provide an attack surface (no general interpreter). Optionally consider firmware certification or audit (especially if STM32 + RDP). ## ECC Application Analysis. 2. ECC is to correct residual errors after demodulation of a true block (to recover a clean 480-bit buffer). It should be weak enough that wrong keys/paths cannot be recovered (deniability + filter). It operates as a separate tool (pipeline: buffer → ECC encode → modulation → demodulation → ECC decode → clean buffer). The ERR field (triple NaN/in/out) serves to distinguish true/fake blocks before or in parallel with ECC. ECC acts mainly on accepted true blocks. ### BER matching calculations At BER = 2.5% and 8-bit symbols (classic RS over GF(256)): Symbol error probability ≈ 1 - (1-0.025)⁸ ≈ 18%. Fastest path (Python, for tests and demo), reedsolo library (pure Python + optional Cython). ```python from reedsolo import RSCodec rsc = RSCodec(32) # RS(255, 223) - 32 ECC symbols, t=16 # or stronger: RSCodec(48), RSCodec(64) etc. encoded = rsc.encode(data_bytes) decoded = rsc.decode(noisy_bytes)[0] ``` | Variant | Parameters | Correction (t) | Application | Notes | |---------|------------|----------------|-------------|-------| | Classic (from documentation) | RS(255, 223) | 16 bytes | Basic demo | Exactly the example from the paper | | Safer | RS(255, 191) or (255, 159) | 32 / 48 bytes | Higher margin | Better at SER ~15–20% | | Matched to block | Shortened RS on ~60–80 bytes of data | Matched t | 480-bit blocks | Less overhead, easier matching | | With interleaving | Any of the above + interleaver | - | Bursty errors | Disperses errors | // The toy version (for texts) in the loop contains an interleaver. It has weak correction but good dispersion. **Tool functions (separate program/library):** - Encode: raw buffer (480 bit / 60 B or larger) → buffer with ECC. - Error simulator: injection of BER 1–5% (or 50%+) for tests. // ECC performance test - Decode + report: success/failure, number of corrected errors, residual BER. - Batch mode: statistics (how many blocks recovered at a given BER). - Optionally: interleaving mode + support for shortened codes. - CLI + simple API (so it can later be plugged into the pipeline). **Position in the pipeline:** ``` raw buffer (480 b) → ECC encode → BUFF480_TO_VEC16 → CRYPT_MSG_V3 (modulation) → channel → DECRYPT_MSG_V3 → VEC16_TO_BUFF480 → ECC decode → clean buffer (for further processing / key rotation) ``` **Alternatives to RS (if stronger is needed):** - LDPC or polar codes (better at higher BER, but heavier). - Concatenation (e.g. outer RS + inner simple code). - For the demo, RS exactly as in the documentation is sufficient. **Execution:** Make a simple Python script with reedsolo on 480-bit blocks. Measure the real residual BER/SER after demodulation in the current prototype. Choose nsym so that at 2–2.5% BER recoverability is >99%, and at 40%+ close to zero. Package as a separate tool (CLI + library) with the possibility of parameter substitution. ### Non-8-bit alternatives Reed-Solomon (codes over finite fields) works over any field 𝔽_q, where q = pᵐ. Most commonly q = 2ᵐ is taken, where the symbol has m bits. 8 bits (GF(256)) is only practical and popular (and well developed). - <8 bits: worse efficiency, fewer libraries; smaller symbols, lower SER with random bit errors; GF(16)–GF(64); 4-bit: SER ≈ 1 − (1 − 0.025)⁴ ≈ 10% - 10 to 12 bits: longer codes, larger blocks and somewhat better burst correction; GF(1024)–GF(4096); - 16 bits GF(65536): impractically large symbols; computationally heavy; - custom 30-bit: lack of standard fields 2^15 / 2^30, implementation nightmare, theoretically one can try 15- or 30-bit symbols; rather 16-bit with padding, but that is again a problem with sqrt from GF(65536); Simplest is to treat 480 bits as 60 bytes and use classic RS over GF(256) (with possible code shortening). Add interleaving. ## Fake Generator. 3. Optional. Assuming that the Reed-Solomon tool (point 2) works correctly, generating fake 480-bit buffers within its framework is a trivial operation. In the current prototype (INFUSE_FALSE_RANDOM_BLOCKS) the fake is generated as follows: ``` buff ← RANDOM_BUFFER_480() // pure random v ← BUFF480_TO_VEC16(buff) H_f ← HMS_CALL("fake_0") // one-time key ĉ_f ← CRYPT_MSG_V3(v, H_f) // check E_f ≠ E₀, injection ``` The fake is random 480 bits, modulated with a key that dies with the block. The purpose of using an RS-based generator is to obtain statistical similarity attacking the combinatorial surface of statistical matching in a sequence of blocks. Of course this must be formulated in reverse - that the goal is to obtain statistical similarity without indicating that the destruction of the surface for combinatorial attacks was in mind after (in the unrealistic but assumed in the omnipotent adversary model, i.e. worst-case scenario) finding the correct one among the sensible block keys. Instead of RANDOM_BUFFER_480() we substitute a buffer that has passed through the RS pipeline: - Take a raw “slice” (anything - random data, fragment of a real message, constant pattern, data from a previous block, etc.). - Pass it through the RS tool (encode). - Use the obtained buffer (or its 480-bit fragment) as buff. - Then exactly the same: BUFF480_TO_VEC16 → H_f → CRYPT_MSG_V3 → ERR collision check → injection. Obtaining a statistically consistent bit image then arises as follows: Instead of RANDOM_BUFFER_480() we substitute a buffer that has passed through the RS pipeline: - We take a raw “slice” (anything - random data, fragment of a real message, constant pattern, data from a previous block, etc.). - We pass it through the RS tool (encode). - We use the obtained buffer (or its 480-bit fragment) as buff instead of random. - Then exactly the same: BUFF480_TO_VEC16 → H_f → CRYPT_MSG_V3 → ERR collision check → injection. That is, we replace the random generator with determined fragments. **Triviality:** - The RS tool already accepts and returns buffers (point 2). - No need to change the injection logic, nor the HSM, nor the E_f ≠ E₀ mechanism. - The fake remains indistinguishable in format ({scale, msg, ERR}) from a true block. - The difference is only in the statistics of the input bits - the fake looks like a correctly encoded RS, not pure white noise. It is harder to distinguish from real data at the entropy/statistics level, but it is not required for the system to function. Such a closing of the system for the worst-case scenario. Pseudo-pipeline then looks roughly like this: ``` function PRODUCE_FAKE_BUFFER_RS(): raw ← any_480bit_or_longer() // random, constant, fragment etc. protected ← RS.encode(raw) // tool from point 2 return TAKE_480_BITS(protected) // or the whole if the length matches Then in INFUSE_... instead of RANDOM_BUFFER_480() call PRODUCE_FAKE_BUFFER_RS(). ``` ## Proposed Technology Stack. 4. Main language is C++20 (or C11 with strong conventions) - gives memory control, deterministic libm, easy port to Raspberry and STM32, mature tools, possibility of manual memory management. A stronger alternative is Zig with better control over memory and allocation than C++, no hidden runtimes, very good cooperation with C/libm, safer defaults. // in practice I translate K&R in Zig to GNU because it is more convenient for me to read; Low level / critical fragments where constant-time, specific FPU instructions or masking are needed will be C and selectively assembly (ARM NEON / Cortex-M). No Python/Java for the production layer of the communication module - too much hidden allocation and harder to ensure deterministic libm and memory protection. Concrete elements to implement are fixed architecture + libm. One mathematical library (e.g. musl libm or controlled glibc) on all platforms. Explicit use of double, no dependence on compiler optimizations that could change the order of FP operations. Compilation flags: -fno-fast-math, -ffp-contract=off, fixed rounding mode. **Memory protection.** Own arena/pool allocator (or Zig allocator) - no malloc/free in the critical path. After use of keys / buffers: explicit zeroing (explicit_bzero / volatile + memset + barrier). On Linux (Raspberry): mprotect + mlock on regions with keys. On bare-metal / STM32: MPU (Memory Protection Unit) + read-out protection. Minimization of the lifetime of sensitive data in RAM. **Intentional scattering (side-channel defense).** Constant execution times for key-dependent operations (where realistic). Dummy operations / false paths when rejecting fakes (already partially present in the prototype). Scattering of data locations in memory (do not keep everything in one continuous block). Simple masking of FP or integer values in critical places is possible. **Communication interface:** - Simple binary protocol (header + payload + CRC). - Input: file or packet stream (USB gadget / serial / socket). - Output: demodulated buffer or status. - Ability to operate as a daemon / service on Raspberry or firmware on STM32. **Portability** Core in C/C++/Zig without system dependencies. HAL / platform abstraction layer only for I/O and memory protection. On Raspberry: normal Linux process + USB gadget. On STM32: bare-metal or FreeRTOS with the same computational core. **Possible structure:** ``` ripa-comm/ ├── core/ # pure C/C++/Zig - modulation, buffers, RS, HSM client ├── memory/ # allocator, zeroization, scattering ├── platform/ │ ├── linux/ # Raspberry: USB gadget, mprotect, mlock │ └── stm32/ # MPU, bare-metal I/O ├── protocol/ # packet serialization └── tools/ # fake generator, BER test, RS demo ``` The module should be thin, deterministic and easy to embed both on Raspberry and on a weaker MCU. Main language: C++20 (if the team and ecosystem matter) or Zig (stronger out-of-the-box memory control). Pointwise ASM (FPU, constant-time, zeroization). Own allocator + system mechanisms (mprotect/MPU) + explicit zeroing for memory protection if we consider this important at the stage of client requirements. ## Pipeline Integration (RIPA as a transport layer, without contact with plaintext). 5. The overarching principle is that our system never sees open text. The pipeline is entered with a ready ciphertext (or any binary buffer). The pipeline exits with the same ciphertext after passing through the RIPA channel + ECC correction. What the client does further (AES, another cipher, verification, storage) is outside the scope of the tool. ``` [Client A – sender] open text → conventional encryption (AES / other) → ciphertext (opaque bytes) │ ▼ [RS encode] ← on our side (or the client can do it themselves) ciphertext → buffer with ECC │ ▼ [Modulating device] fixed libm + FPU ← airgap ← [external HSM] (only parameter packets) splits into 480-bit blocks CRYPT_MSG_V3 + fake injection (fake = RS-protected buffer + fake_0) assembles PACK {scale, msg, ERR} │ │ airgap ▼ [Communication system – exposed] internet / radio / cable / whatever transmits PACK as an opaque stream │ ▼ [Receiving device – exposed] accepts stream / file optionally external CRC / framing │ │ airgap ▼ [Demodulating device] fixed libm + FPU ← airgap ← [external HSM] DECRYPT_MSG_V3 AO_CHECK → rejects fakes assembles true 480-bit blocks │ ▼ [RS decode] residual BER correction output: reconstructed ciphertext (opaque bytes) │ │ (optional airgap) ▼ [Client B – recipient] standard decryption ciphertext → open text ``` **Division of responsibility:** | Stage | On our side | On the client side | |-------|-------------|--------------------| | Conventional encryption | No | Yes | | RS encode | Yes (or client) | Optionally | | RIPA modulation + fakes + HSM | Yes | No | | Transport (internet/radio) | No (interface only) | Yes / infrastructure | | RIPA demodulation + fake filter + HSM | Yes | No | | RS decode | Yes (or client) | Optionally | | Conventional decryption | No | Yes | The client’s encryption and decryption pipeline remains untouched. Only the transport layer is armed against the adversary. **Key airgap places:** - HSM ↔ modulating / demodulating device (filtered protocol) - Modulating device ↔ communication medium - Medium ↔ demodulating device - (optionally) RS decode output ↔ end client Our system begins on the ciphertext and ends on the same ciphertext. Everything else (AES, open text, decisions what to do with the data) remains outside it. ### End-to-end pipeline in Mermaid: ```mermaid flowchart TD subgraph ClientA["Client A – sender"] OT1["Open text"] ENC["Conventional encryption
(AES / other)"] CT1["Ciphertext
(opaque bytes)"] OT1 --> ENC --> CT1 end subgraph OurLayerTx["Our layer – transmission"] RS_ENC["RS encode"] MOD["Modulating device
fixed libm + FPU"] HSM_TX["External HSM"] CT1 --> RS_ENC --> MOD HSM_TX -.->|"airgap
only parameter packets"| MOD MOD --> PACK["PACK
{scale, msg, ERR}
+ fakes"] end subgraph Transport["Communication system – exposed"] COMM["Internet / radio / cable
opaque stream"] PACK --> COMM end subgraph OurLayerRx["Our layer – reception"] RX["Receiving device
exposed"] DEMOD["Demodulating device
fixed libm + FPU"] HSM_RX["External HSM"] RS_DEC["RS decode"] CT2["Reconstructed ciphertext
(opaque bytes)"] COMM --> RX RX -->|"airgap"| DEMOD HSM_RX -.->|"airgap
only parameter packets"| DEMOD DEMOD --> RS_DEC --> CT2 end subgraph ClientB["Client B – recipient"] DEC["Conventional decryption"] OT2["Open text"] CT2 --> DEC --> OT2 end style ClientA fill:#f9f9f9 style ClientB fill:#f9f9f9 style OurLayerTx fill:#e6f3ff style OurLayerRx fill:#e6f3ff style Transport fill:#fff3e6 ``` **Sequential simplification:** ```mermaid sequenceDiagram participant KA as Client A participant MOD as Modulator + HSM participant COMM as Transport participant DEMOD as Demodulator + HSM participant KB as Client B KA->>KA: open text → ciphertext KA->>MOD: ciphertext MOD->>MOD: RS encode + CRYPT_MSG_V3 + fakes MOD->>COMM: PACK COMM->>DEMOD: PACK DEMOD->>DEMOD: DECRYPT + AO_CHECK + RS decode DEMOD->>KB: reconstructed ciphertext KB->>KB: ciphertext → open text ``` ## Potential Recipients. 6. **Organizations with a deniability / cover traffic requirement** Companies and institutions that already use AES/standard ciphers, but want the mere fact of transmission to be harder to analyze (continuous noise + fakes + lack of an explicit marker “here is a real message”). Typical environments are diplomacy, economic intelligence, companies with high risk of industrial espionage, some NGOs operating in hostile jurisdictions. **Providers of air-gapped / high-assurance solutions** Companies building systems in which data passes through a physical airgap (HSM on USB, Raspberry in gadget mode, separate demodulating devices). They want a ready modulation layer with controlled BER and external HSM, instead of building it from scratch. **Integrators of special systems / custom radio / mesh** Teams that already have their own transport (radio, satellite, own protocol) and need a layer that introduces controlled, reversible noise (2–2.5% BER corrected by RS), makes it harder to distinguish real traffic from noise and does not require replacing the existing cryptographic stack. **Research / academic / proof-of-concept** Groups dealing with unusual channels, FPU side-channels, deniable encryption, covert channels. Smaller volume, but good references and feedback. ### Positioning Transport-modulation layer / synthetic arithmetic channel / deniable cover channel. Working slogan: “A channel layer that turns any ciphertext into a signal with controlled noise, fakes and an external HSM. Conventional encryption remains unchanged.” | Form | What the client gets | For whom | Notes | |------|----------------------|----------|-------| | SDK / library | Core C/C++/Zig + RS + HSM client + examples | Integrators | Fastest to sell | | USB module / dongle | Raspberry Zero / STM32 in enclosure + firmware | Companies wanting airgap | HSM + modulator/demodulator in one | | Appliance | Small device (Pi Compute Module) with network/USB interface | Larger deployments | “Black box” | | License + support | Code + documentation + implementation consultations | Special projects | Higher margin | **Starter package (MVP for sale):** - Modulation/demodulation library (point 4). - External HSM (point 1) as firmware on Pi Zero / STM32. - RS tool + fake generator (points 2–3). - Example pipeline (point 5) + diagrams. - Documentation: “what it is / what it is not”, threat model, BER limitations, requirements for identical FPU/libm. Security is based on deniability + attack cost, not on classical cryptographic hardness. The requirement of an identical toolchain/FPU between parties can be a problem in heterogeneous environments. There is no standard certification (Common Criteria, FIPS 140, or equivalents) for an object of the type “synthetic arithmetic channel / modulation layer with controlled BER and deniability”. Classical certifications concern cryptography, not channels of this kind. | Area | Certifications | Examples | Fit to RIPA | |------|----------------|----------|-------------| | Cryptographic algorithms | Yes | AES, SHA-2/3, RSA, ECC in FIPS 140, Common Criteria | No – RIPA is not a cipher | | Cryptographic modules (HSM, tokens) | Yes | FIPS 140-2/3, CC EAL | Partially – the HSM itself yes, the whole RIPA layer no | | Cryptographic protocols | Sometimes | TLS, IPsec, SSH in CC profiles | No | | Transport layers / channels | Very rarely and differently | Some profiles for VPN, military radio, TEMPEST | No in the sense of “channel with FPU residues” | | Covert channels / deniable encryption / steganography | Practically not | Do not exist | Exactly this area | Certifications are built around computational hardness and correctness of algorithm implementations. Common Criteria and FIPS assess whether a module correctly implements an approved algorithm, whether keys are protected, whether there are no side-channels in the classical sense. RIPA by definition does not rely on a computationally hard problem - it relies on controlled information loss and deniability. A transport layer is certified only when it carries cryptography. CC profiles for IPsec VPN, some military radio systems (e.g. with approved waveforms). Then the entire stack is certified (encryption + integrity + authentication), not the modulation itself or “controlled noise”. Deniability, cover traffic, fakes, FPU residues are areas that deliberately go beyond the model “confidentiality = cannot be read without the key”. Certifications have no criteria for “whether an attacker cannot distinguish a true block from a fake”, “whether BER is stable and correctable only for the proper seed”, “whether the state genealogy is unrecoverable”. Historically, channels (physical, radio, optical) have been the subject of security measures (TEMPEST, red/black separation, approved waveforms), but always in tandem with classical cryptography or as protection against side-channel emission. Not as a standalone deniable modulation mechanism. **What can be certified (if the client requires it):** - The external HSM itself (FIPS 140-3 or CC) - as a classical key-storing module. - RS / ECC - as a standard error-correcting code (does not require certification, but compliance with theory can be shown, more of an audit). - The entire appliance as a “data processing system” to a limited extent (memory protection, separation), but not as a mechanism providing confidentiality. There is not, and in the current certification landscape there rather will not be, a standard path for an object of the RIPA type. Channels and transport layers have been the subject of security, but always in a different model (cryptography + emission protection), not as a standalone deniable modulation layer based on FPU residues. This is a consequence (not a gap) of what this product is. There is no established category, family or standard affiliation for something like RIPA/QCO. | Level | Occurrence | Examples | RIPA status | |-------|------------|----------|-------------| | Family of cryptographic algorithms | Yes | Block ciphers, stream ciphers, AEAD, hash, KEM, signature | Does not belong | | Family of protocols | Yes | TLS, IPsec, Signal, Noise | Does not belong | | Family of error-correcting codes | Yes | Reed-Solomon, LDPC, polar, BCH | Partially (RS is used, but does not define the object) | | Family of covert channels / deniable encryption | Weakly | Deniable encryption (theoretical), steganography, cover traffic | Closest, but informally | | Family of “synthetic channels” / FPU-residue channels | No | None | Does not exist | | Certification profile / PP (Protection Profile) | No | No PP in Common Criteria | Does not exist | | Nomenclature standard (NIST, ISO, ETSI) | No | None | Does not exist | The object is not a cryptosystem (no hard problem, no inversion, no model “key → invertible function”). It is not a classical communication channel in the Shannon information-theoretic sense (because it uses deterministic FPU residues and loss of genealogy, not probabilistic noise). It combines elements from several areas (modulation, ECC, HSM, deniability, side-channel as a resource), but none of them defines it. In the literature and standards there is no family of “representation-induced channels”, “FPU-residue alphabets” or “deniable arithmetic channels”. It is not possible to formulate the statement that “this is a kind of X” in a way that would be recognizable to an auditor, certifier or client from the regulated sector. The object must be defined descriptively each time (modulation layer based on FPU residues, with controlled BER, fakes and an external HSM). In documentation and sales materials, firmly avoid attempts to force it into existing families (“it is such a cipher”, “it is steganography”, “it is a covert channel”) - each of them is imprecise and incorrect. The mathematical source of the phenomenon on which RIPA is built, and at the same time the reason why there is no ready family or standard affiliation, is the projection, in the school version (sufficient for marketing so that it is not too difficult) as follows. Given the projection q: ℝ → 𝔽 (e.g. 𝔽 = binary64), which is not a field homomorphism. In particular: q(a + x) = q(a) for x ≠ 0, |x| < (1/2) ulp(a) At a = 1: q(1 + ε) = q(1) when |ε| ≲ 1.11 × 10⁻¹⁶ while in ℝ of course 1 + ε ≠ 1. That is, a structural loss of distinguishability where many different elements of ℝ fall into the same bucket of 𝔽. The fiber q⁻¹(b) = { x ∈ ℝ : q(x) = b } is non-trivial. Operations performed already on the images q(·) do not correspond to operations in ℝ, because they act on representatives, not on classes. It does not fit into the algebras. Tropical / max-plus algebras describe a different degeneration (replacement of + by max, × by +). They have their own, well-studied structure. Here the degeneration is different: it is a projection with information loss, not a change of operations to a new semiring. Interval arithmetic and affine arithmetic model uncertainty, but assume that we want to track intervals. Here we deliberately use the fact that after the projection the genealogy is destroyed. Floating-point error analysis (Higham and others) treats residues as a disturbance that should be limited. Here the residue is the alphabet. The theory of finite fields and finite-precision arithmetic study 𝔽 as an independent structure, but rarely as the result of a non-homomorphic projection from ℝ used as a channel. None of these areas defines the object “a channel whose alphabet is the abstraction classes of the projection q, and security results from the loss of genealogy and the irreversibility of trajectories”. Mathematically the phenomenon is known (projection, loss of homomorphism, ulp-buckets), but it has not been isolated as an independent channel / modulation object with its own nomenclature, threat model and criteria.