Click after enough chunks are received. Bernard's σ_session credential is retrieved from his Secure Enclave.
Demonstrates silent-failure denial of oracle access — wrong-order opening returns the same error as insufficient-chunks.
Click after enough chunks are received. Bernard's σ_session credential is retrieved from his Secure Enclave.
Demonstrates silent-failure denial of oracle access — wrong-order opening returns the same error as insufficient-chunks.
Wire layer — what an adversary observes. Carries only ARIA-MSG cover messages plus opaque chunk-bearing packets. None are distinguishable from each other on the wire.
Authentication layer — the cover is signed by the sender's per-counterparty key. Bilateral endpoint authentication; both parties enrolled.
ARIA-MSG layer — the cover message itself, plausible business correspondence between Anna and Bernard.
ARIA-INK layer — the steganographic embedding within the cover. Real message recoverable only with K_recover.
ARIA-KEY layer — K_recover, split into N=5 chunks, threshold k=3, sequence-locked by σ_session. Reconstruction requires k chunks AND correct σ.
Real-message layer — the actual content. Never on the wire. Reconstructed at Bernard's endpoint only.
K_recover is split via Shamir-style polynomial interpolation over GF(2^8) into 5 chunks; any 3 are mathematically sufficient. Each chunk is ALSO wrapped using a key derived from the contents of all chunks scheduled to precede it in σ_session.
σ_session is a permutation of the 5 chunk indices, set freshly at session establishment, stored only at Bernard's Secure Enclave and at the registry. It never travels on the wire.
Wrong-order opening fails an authenticated-decryption integrity check. The error returned is indistinguishable from "insufficient chunks collected" — the attacker gets no oracle access by which to brute-force σ. With 5 chunks, an attacker without σ faces 5! = 120 permutations, each test requiring Bernard's enrollment credential AND producing no signal about which positions are correct.
Both Anna and Bernard are enrolled in the protocol registry. The protocol does not operate for unenrolled endpoints. This structurally prevents anonymous use; properly served legal process can compel the registry to disclose communicating-pair identities and timestamps even when content remains undecryptable. This addresses the dual-use concern at the protocol-design level.
The cover message itself is signed by Anna's per-counterparty key under Bernard's identifier — verifiable by Bernard's recipient client at recovery time. An adversary who substitutes a different cover in transit would break this signature.
One of the chunk-bearing transport packets carries its chunk steganographically embedded within another cover message rather than as opaque ciphertext. To a wire observer, all five transport packets look like ordinary correspondence on different topics. Distinguishing chunk-bearing covers from message-bearing covers requires the recipient's per-counterparty key.
In production deployments the recursive depth is configurable. Routine business correspondence: depth 1 (one cover layer, chunks in opaque packets). Coercion-resistant: depth 2-3. Sovereign-grade: bounded only by operational tolerance.
Suppose an adversary captures all five transport packets — the cover message and all four chunk-bearing packets. Suppose further the adversary has somehow obtained Bernard's enrollment credential (the strongest case for the adversary).
The adversary still cannot recover Anna's real message. To do so, they need σ_session — the per-session opening sequence stored only at Bernard's Secure Enclave. Without σ, the adversary faces 5! = 120 permutations to test by brute force.
Each test of a candidate permutation requires:
(1) Picking 3 chunks from the 5 captured.
(2) Ordering them according to the candidate σ.
(3) Attempting authenticated decryption in that order.
(4) The decryption fails for any wrong σ. The error is indistinguishable from "insufficient chunks." No oracle signal.
The adversary cannot tell which of the 120 permutations succeeded. They cannot tell which of the 10 (= 5 choose 3) chunk subsets is the correct one. They cannot tell whether their failure means "wrong σ," "wrong chunk subset," or "all my chunks are valid but Bernard's σ has been rotated."
Suppose Bernard is compelled by legal authority to disclose received-message content. He can truthfully comply with a partial disclosure:
(1) Hand over the cover message — which is what arrived on the wire, decrypts truthfully to itself, and is internally consistent.
(2) Optionally claim that σ_session was rotated and is no longer in his Secure Enclave (true after session end; verification of the claim requires registry-record access).
(3) Optionally claim that not all chunks were received from all five transport paths (plausible for cooperative key distribution; one path may have failed to deliver).
The compliance is partially-honest in a way that's harder to disprove than with simple threshold sharing. The real message remains hidden.
Endpoint compromise. If Bernard's primary device is compromised AND σ_session is exfiltrated before session end, the recovered message is exposed.
Forward secrecy across credential compromise. Compromise of registry-stored long-term enrollment credentials may permit retroactive decryption depending on protocol parameters.
Anonymous operation. Both endpoints are identified to the registry. Registry metadata (which endpoints, when, what duration) is available to legal process. This is by design — the architectural answer to dual-use concerns.