Disclaimer. ITB is an experimental construction without peer review or formal certification. The information-theoretic barrier is a software-level property, reinforced by two independent barrier mechanisms: noise absorption from CSPRNG, and encoding ambiguity (56^P without CCA, 7^P under CCA) from triple-seed isolation. Architectural layers deny the point of application: independent startSeed and 8-noisePos ambiguity from independent noiseSeed under Full KPA, plus gcd(7,8)=1 byte-splitting under Partial KPA. Full KPA defense is 3-factor under PRF assumption (4-factor under Partial KPA) — see Proof 4a. It provides no guarantees against hardware-level attacks (DPA/SPA, Spectre, Meltdown, Rowhammer, cache timing, undiscovered side-channels). PRF-grade hash functions are required. No warranty is provided.

Comprehensive security comparison tables for ITB (Information-Theoretic Barrier) across three composition modes: Core (no MAC), MAC + Silent Drop, MAC + Reveal. For detailed proofs and analysis, see SCIENCE.md.

Supported versions. Active development tracks main. Tagged releases starting from v0.1.0. Security fixes land on main first; older tags receive backports only when the maintainer judges the fix worth backporting (rare given the pre-release status).

Reporting a vulnerability. Private reports preferred via GitHub Security Advisories. Discord channel for coordination: discord.gg/wRYF8shHpd. Email contact is intentionally not published — Discord and Security Advisories cover both informal triage and formal disclosure.

Triage and response. Best-effort triage within 14 days. Pre-release status means no SLA or commercial support is implied. Responses are individually authored, not template-driven.

Coordinated disclosure. Findings against the construction — cryptanalytic attacks, theoretical weaknesses, implementational flaws — are most welcome and prepared for academic publication. A 90-day coordinated disclosure window is the default; faster public disclosure may be appropriate when a fix lands quickly or the finding is already public via parallel discovery. The ITB construction was published to invite scrutiny, not to claim closed-form security — cryptanalytic findings under the author's own attribution are explicitly encouraged.

Out of scope. Hardware-level attacks (DPA/SPA, Spectre, Meltdown, Rowhammer, cache timing, fault injection), supply-chain attacks against dependencies, attacks against the host OS / language runtime / hardware platform itself. See the Disclaimer above.

Cryptographic context. The deeper construction-level properties — composition modes, attack resistance, barrier metrics, byte-splitting, information-theoretic bounds, Bit Soup, Lock Soup — are catalogued in the numbered sections below. Refer there for the substantive cryptographic content; this section governs disclosure process only.

† Software-level property under the random-container model; no guarantees against hardware-level attacks (see Disclaimer).

¶ CCA eliminates noise bits (12.5%), but CSPRNG fill bytes remain encrypted in data bit positions by dataSeed — indistinguishable from plaintext (Proof 10).

Triple-seed architecture: noiseSeed (noise positions), dataSeed (rotation + XOR, zero side-channel), startSeed (pixel offset).

PRF-grade hash functions are required. PRF property guarantees all necessary sub-properties (input sensitivity, chain survival, non-affine mixing, avalanche, non-invertibility) by definition.

PRF weakness decomposes into three cases. Total inversion defeats the construction via algorithmic seed recovery (see Proof 4a Asymmetry note). Occasional/sporadic partial inversion is absorbed by the architecture: recovered candidates are indistinguishable from the false-positive distribution produced by startPixel isolation, per-pixel 1:1 ambiguity, and byte-splitting under Partial KPA. Systematic partial inversion is a real non-absorbed threat — the architecture raises the cost but does not eliminate the attack. No such systematic weakness is currently known to reduce the Full KPA work factor below the Theorem 4a bound.

Note. 256-bit keys are widely considered sufficient for all foreseeable classical and quantum threats. Larger key sizes provide defense-in-depth margin.

† Software-level property under the random-container model; no guarantees against hardware-level attacks (see Disclaimer).

‡ Deprecated construction (TLS 1.0/1.1, RFC 8996). Included for historical context only.

† IT barrier is a software-level property under the random-container model; no guarantees against hardware-level attacks (see Disclaimer).

* Per-bit XOR hides XOR masks under passive observation; with invertible hash, seed recoverable via inversion.

** MAC + Reveal: CCA reveals noisePos but not startPixel (startPixel determined by independent startSeed + nonce, not transmitted). startPixel enumerated as [0, P). Total: P × 2^keyBits classical, √P × 2^(keyBits/2) Grover. At 1024-bit keys (P=400): classical ~2^1033, Grover ~2^516. With invertible hash under KPA: seed recoverable in ~56 × P hash inversions (P startPixel candidates × 56 configs per reference pixel, no CCA required). Under PRF, Full KPA requires simultaneously three independent obstacles: (1) inverting ChainHash, AND (2) guessing startPixel from independent startSeed (no leak from noiseSeed/dataSeed), AND (3) resolving 7-rotation and 8-noisePos ambiguity per pixel at signal/noise 1:1 (all 56 candidates equally consistent with observation). Under Partial KPA, a 4th obstacle is effective: gcd(7,8)=1 byte-splitting blocks per-channel candidate formulation when adjacent bytes are unknown. PRF non-invertibility and the architectural layers combine conjunctively, not redundantly: an attacker with partial PRF inversion still faces P startPixel candidates to enumerate and 56-fold per-pixel ambiguity to disambiguate without a verification oracle.

††† Core ITB and MAC + Silent Drop (no oracle): attacker must jointly search noiseSeed and dataSeed — without dataSeed, noiseSeed output is indistinguishable from random, so independent attack on noiseSeed is impossible. Joint search space: 2^(2×keyBits). startSeed contributes only P (startPixel candidates, enumerated as [0, P)), not 2^keyBits. Total: P × 2^(2×keyBits). Grover: √P × 2^keyBits. At 1024-bit keys (P=196): classical ~2^2056, Grover ~2^1028.

§§ CCA removes noise bits (12.5% of container), but CSPRNG fill bytes encrypted by dataSeed persist in data bit positions, indistinguishable from plaintext. The information-theoretic barrier is reduced, not fully eliminated (Proof 10).

Nonce reuse is local. Two-time pad applies only to the colliding 2–3 messages (confidentiality of those messages compromised). Seeds remain secret (PRF non-invertibility blocks ChainHash inversion), so future messages with fresh nonces are unaffected — no key rotation required. A single nonce collision provides too few observations for Simon, BHT, or quantum structural algebraic attacks. Unlike AES-GCM where nonce reuse leaks the GHASH key H and enables forgery until key rotation (global catastrophe affecting all subsequent messages), ITB nonce collision is strictly local — ITB is nonce-misuse-resistant under the PRF assumption. For the five conditions that ALL must hold before nonce reuse extracts any signal at all, see ITB.md § 8 Nonce Reuse; for the empirical 96-cell Partial KPA matrix + NIST STS PRF-separation, see REDTEAM.md § Phase 2d — Nonce-Reuse.

‡‡ MAC + Silent Drop assumes the attacker is unaware of MAC presence. If the attacker knows MAC is inside (e.g., insider knowledge), the encrypted MAC tag serves as a local verification oracle during brute-force — the attacker decrypts with candidate keys, computes MAC(payload), and checks against the embedded tag without requiring recipient response. Search cost remains P × 2^(2×keyBits) (same as Core ITB — no CCA, noiseSeed not leaked, both seeds must be searched jointly), but the attacker can now verify candidates. Without insider knowledge: no verification → plausible deniability. Grover: √P × 2^keyBits.

Since gcd(DataBitsPerChannel, BitsPerByte) = gcd(7, 8) = 1, plaintext bytes never align with channel boundaries. Every plaintext byte is split across exactly 2 channels with independent per-channel XOR masks.

This property is a structural consequence of the 8/1 noise format, not a deliberately engineered feature. See SCIENCE.md Section 2.9.1 for detailed analysis.

§ CCA reveals noise bit positions, but does not eliminate all ambiguity: CSPRNG fill bytes in data positions remain encrypted by dataSeed, indistinguishable from plaintext (Proof 10).

‖ Noise barrier applies to Core ITB / MAC + Silent Drop. Under CCA (MAC + Reveal), noise positions are revealed but CSPRNG fill in data positions persists as residual ambiguity (Proof 10).

8/1 is Pareto-optimal among the analyzed noise-density configurations. All barriers exceed the Landauer limit.

Implemented: Inside (full capacity) — EncryptAuthenticated128 / EncryptAuthenticated256 / EncryptAuthenticated512. Other placements are theoretical alternatives, not implemented.

For detailed per-CVE analysis of 20+ hardware attacks (Spectre variants, Downfall, Hertzbleed, MDS, Zenbleed, Rowhammer), see HWTHREATS.md.

The optional C pixel processing backend (CGO_ENABLED=1, GCC -O3 -mavx2) was verified for side-channel equivalence with the Pure Go backend:

The analysis applies equally to ARM64 NEON auto-vectorization: veor, vand, vorr, vshl, vshr are constant-time on ARM. ARM sdiv (for % totalPixels) is variable-time but operates on public data only. ARM has no frequency throttling from NEON (unlike Intel AVX-512).

Both backends produce identical ciphertext. Switching between CGO_ENABLED=0 (Pure Go pixel kernel; Go-assembly hash ASM stays engaged) and CGO_ENABLED=1 (C + SIMD pixel kernel) does not change the security model on any platform. See SCIENCE.md §4 "Known Theoretical Threats" point 6 for detailed analysis.

PRF-grade hash functions (Areion-SoEM-256, Areion-SoEM-512, SipHash-2-4, AES-CMAC, BLAKE2b-256, BLAKE2s, BLAKE3, BLAKE2b-512) satisfy all requirements. Tests and benchmarks cover all listed hash functions across 128/256/512-bit widths.

* Software-level property under the random-container model. No guarantees against hardware-level attacks (see Disclaimer).

Each brute-force candidate (classical or Grover oracle query) requires full container decryption — processing all P pixels with ChainHash. This applies to all composition modes (Core ITB, MAC + Silent Drop, MAC + Reveal). The per-query cost grows linearly with data size, making larger messages more expensive to attack.

Approximate empirical example: 1024-bit key, ~10 ns/hash (average across PRF functions on a typical modern CPU), 8 ChainHash rounds, 2 hash calls per pixel (noiseSeed + dataSeed). Actual times vary by hash function, key size, and hardware.

Grover oracle queries have the same O(P) per-candidate cost — ChainHash rounds are sequential and not parallelizable by quantum algorithms. See SCIENCE.md §2.12 for detailed analysis.

The information-theoretic barrier is computation-model-independent: provided the container is generated from a source indistinguishable from true uniform randomness, every observed byte value is compatible with every possible hash output (∀v, ∀h : ∃c : embed(c,h,d)=v), regardless of classical, quantum, or any future computational model. A quantum computer cannot extract information that does not exist in the observation. However, whether this property translates into practical quantum resistance across all attack scenarios has not been formally proven or independently verified.

Q1 vs Q2 models. In the Q2 model (quantum superposition queries to oracle), constructions such as Luby-Rackoff, Even-Mansour, and Keyed Sum of Permutations become vulnerable. ITB's MAC oracle is inherently classical — it accepts a concrete container over a network and returns accept/reject. Superposition queries are physically impossible. Core ITB and MAC + Silent Drop have no external oracle (if the attacker has insider knowledge of MAC presence, local verification is possible — see ‡‡). This means the Q2 model is inapplicable by design, not by cryptographic countermeasure.

The fundamental difference between ITB and traditional ciphers under quantum attack: AES and ChaCha20 rely on computational hardness — their security degrades with more computational power (Grover: √ speedup). ITB's barrier relies on information absence — no computation (classical or quantum) helps when the information is not in the observation. This is an information-theoretic property, not a computational assumption.

AES-256 and ChaCha20 are widely considered quantum-resistant for practical purposes (2^128 Grover bound). ITB's random-container architecture may provide an additional architectural layer of resistance to quantum structural algorithms, but this is a conjectured property that has not been independently verified. See SCIENCE.md §2.11 for detailed analysis. See also SCIENCE.md §2.9.2 for why KPA candidates do not break the barrier.

At 1024-bit key: Core/Silent Drop (P=196) ~2^2056 classical, ~2^1028 Grover. MAC + Reveal (P=400): ~2^1033 classical, ~2^516 Grover. At 2048-bit key: Core/Silent Drop (P=361) ~2^4104/~2^2052, MAC + Reveal (P=784): ~2^2058/~2^1029.

ITB is a new construction without prior peer review or independent cryptanalysis. The contribution is theoretical: demonstrating that Full KPA resistance is 3-factor under PRF assumption (PRF non-invertibility + independent startSeed + per-pixel 1:1 ambiguity), with gcd(7,8)=1 byte-splitting as a 4th factor effective only under Partial KPA. PRF non-invertibility closes the candidate-verification step; architectural layers deny the attacker a usable reference pixel (see Proof 4a). Performance is not a design goal.

Potential vulnerability classes: (1) fundamental — barrier invalidation under unconsidered attack model (unlikely, barrier is probability-theoretic); (2) implementational — edge cases, timing, off-by-one (correctable). See SCIENCE.md §4 "Scope and Maturity Disclaimer" for detailed discussion.

SetBitSoup(1) enables bit-granularity plaintext split. On Triple Ouroboros, applies to every variant (Encrypt3x*, EncryptAuthenticated3x*, EncryptStream3x*); no single snake holds a real plaintext byte — each snake's payload is a fixed public bit-permutation across three consecutive plaintext bytes. Bit Soup reduces SAT cryptanalysis to an under-determined instance under Partial KPA + realistic protocol traffic at the public-encoding layer; the barrier shifts the attack surface from solver speed to crib coverage available at the public bit-permutation. Default SetBitSoup(0) leaves byte-level shipped behaviour unchanged.

On Single Ouroboros, SetBitSoup(1) engages the Lock Soup overlay path directly — the public fixed bit-permutation alone offers no architectural barrier on a single snake (the snake carries the whole plaintext, so a public fixed permutation of bits within the snake provides nothing beyond a public fixed permutation of bytes), so the Single bit-level path is keyed by construction. See §19.

Ciphertext wire format is identical across all modes; no public header bit distinguishes them. See ITB.md / ITB3.md for the accessible explanation and REDTEAM.md Phase 2g for the defensive framing in the SAT attack context.

SetLockSoup(1) is the keyed-bit-permutation overlay on top of bit soup; setting it automatically engages SetBitSoup(1) (the overlay layers on top of bit soup, so the two flags are coupled in the on-direction). An additional defense against KPA.

On Triple Ouroboros, the overlay replaces the fixed public 24-bit chunk permutation of plain Bit Soup with a per-chunk PRF-keyed balanced 8-of-24 mask triple drawn from a 2^33 mask space, derived deterministically per chunk from the noiseSeed and nonce via a single PRF call. The mode strengthens the SAT-cryptanalysis barrier from the public-encoding layer (Bit Soup) to the keyed-encoding layer: each crib chunk multiplies attacker enumeration by ~2^33 with no shared algebraic structure across chunks, so the joint SAT instance is information-theoretically under-determined regardless of crib coverage. SAT cryptanalysis becomes an instance-formulation impossibility rather than a computational-hardness problem; solver throughput, including any hypothetical PRF-inversion shortcut, does not convert an under-determined instance into a determined one.

On Single Ouroboros, SetBitSoup(1) and SetLockSoup(1) are coupled symmetrically — either flag activates the Lock Soup overlay (the two flags engage the same code path on Single, vice versa). The Single overlay replaces the 24-bit chunk identity with a per-chunk full S₂₄ permutation drawn from a 2^64 space (Lehmer-code unrank of 24! ≈ 6.2 × 10²³ permutations, addressed by the low 64 bits of a per-chunk PRF output). Each crib chunk multiplies attacker enumeration by ~2^64 — substantially stronger per-chunk than the Triple variant's 2^33, because the single snake carries the whole plaintext and needs a higher floor to compensate for the absence of 3-way snake split.

Performance cost is approximately 2×–7× slower than plain Bit Soup depending on platform; the BMI2 PEXT/PDEP path on x86 (Haswell+, Excavator+/Zen 1+) on Triple, AVX-512 VBMI VPERMB + VPMOVM2B + VPTESTMB path on x86 (Rocket Lake / Tiger Lake / Sapphire Rapids+, Zen 4 / Zen 5) on Single, sit near the lower bound; Pure Go fallbacks near the upper. The trade-off is acceptable only where the architectural barrier is the deployment priority. Default SetLockSoup(0) leaves Bit Soup behaviour unchanged. Both flags must agree across the encrypt and decrypt sides of the channel; mismatched modes produce wrong-seed-style garbage with no error oracle (plausible-decryption invariant preserved). Ciphertext wire format is identical across all three modes (Byte Level / Bit Soup / Lock Soup).

AttachLockSeed on the native path (or Encryptor.SetLockSeed(1) on the Easy Mode path) routes the per-chunk permutation derivation through a dedicated lockSeed slot allocated alongside the standard noise / data / start trio. Both the keying material and the underlying PRF primitive are independent of the noise-injection channel within the same native hash width — algorithm-diversity defence-in-depth on top of the per-chunk 2³³ (Triple) / 2⁶⁴ (Single) Lock Soup floor. A structural shortcut against the noiseSeed primitive cannot leak into the lock-channel derivation, and vice versa. Default no attach leaves the overlay routing through the noiseSeed unchanged.