#Aims and reasoning
#Protect a conversation and a durable artifact on their own terms
A message stream can advance and erase session keys. A post, attachment, or shared record may remain readable for years by several devices. Treating both as the same encrypted object either weakens session guarantees or makes retention and sharing difficult to reason about. Each surface needs an explicit audience, lifetime, recovery policy, and authentication claim.
A recipient should be able to authenticate private material without the system needlessly producing transferable proof of personal authorship. At the same time, a malicious group member must not be able to impersonate another writer to an honest recipient. Deniability, insider-resistant attribution, late-reader history, and intentional public attestation are different requirements; no mechanism name settles their composition. The September authentication analysis and cryptography lane own that threat model.
#Make revocation and recovery truthful
Removing a reader can stop future key delivery and protect future revisions. It cannot revoke plaintext or a key already copied. Keeping an archive, backup, or recovery derivation also keeps a path to old content. Retention claims must account for all those paths rather than equating deletion of one session key with erasure of every copy.
Conditional release is justified by a named need such as divided key custody or release under an external condition. Ordinary private reading and collective governance do not automatically require PRE, a threshold network, a blockchain, or zero-knowledge proofs.
#Protocol and architecture
#Mechanism decision tree
A single operation may need several jobs. A capability can authorize fetching bytes without revealing their plaintext. A valid decryption key does not authorize editing. The expected authentication profile comes from accepted context state; an incoming object cannot select weaker checks by changing or omitting a field.
#Method comparison
| Mechanism | Candidate job | Boundary |
|---|---|---|
| Signal-style ratchet / PQXDH | Asynchronous relationship security and descriptor delivery | Archives and retained object keys have separate lifecycles; deniability has specified model limits |
| MLS / OpenMLS | Evolving multi-party sessions | Requires application credentials, accepted membership/commit rules, history, and evidence policy |
| Per-object AEAD | Durable payload or revision confidentiality | Does not identify its author or define authorized recipients |
| Streaming AEAD | Large authenticated attachments and range reads | Segment order, identity, truncation, and finalization require a reviewed format |
| HPKE Base | Confidential recipient-key delivery | Does not authenticate a sender by itself |
| HPKE Auth with a selected DHKEM | Recipient-specific authenticated descriptor experiment | Recipient-key compromise enables sender impersonation to that recipient; static use lacks recipient forward secrecy |
| Designated-verifier construction | Non-transferable recipient verification | Simulation, collusion, and key lifecycle need analysis; reference code is not approval |
| Contextual signatures with deniable personal binding | Shared-history experiment | Context signatures remain transferable; adjacent identity certificates can restore a personal binding |
| Symmetric group key or MAC | Confidentiality or membership-level authentication | A shared MAC cannot distinguish writers against insiders |
| PRE / threshold release | Named author-offline, external-condition, or divided-custody requirement | Release liveness, collusion, revocation, metadata, and recovery remain additional work |
| Broadcast / attribute encryption | Exceptional large or policy-shaped audience | Revocation, policy leakage, implementation maturity, and key management need justification |
| ZK proof | Narrow eligibility or rate/accounting predicate | Does not encrypt content or decide social legitimacy |
Primary mechanism references are HPKE RFC 9180, MLS RFC 9420, MLS architecture RFC 9750, and the Signal specifications. Standards describe mechanisms; they do not approve a TalkCo integration or its target platforms.
#Authentication and proof transferability
One encrypted payload may serve several intended readers; their protected descriptors bind the exact representation and the sharing act. A storage hash supplies byte integrity, not freshness, authorship, or permission. An ERIS read capability is not automatically an author credential.
Contact-specific signing keys reduce correlation only while their personal binding stays private. Encrypting an ordinary sender signature does not make it non-transferable: a recipient can reveal the decrypted signature without revealing their own private key. The analysis must distinguish offline transcript disclosure, an online cooperating observer, colluding recipients, endpoint compromise, testimony, and traffic analysis. The PQXDH deniability discussion is a model reference, not a blanket claim for TalkCo.
#Variation — Established ratcheted relationships carry descriptors
This is the leading private-object delivery experiment. It reuses relationship authentication without adding a personal signature over the payload hash. It still needs multi-device delivery, offline prekeys, retained-descriptor policy, and evidence-export tests. Generic setup authentication is not prohibited indiscriminately; specify exactly which identity and which content each certificate binds.
#Variation — Recipient-authenticated descriptors without a retained session
RFC 9180 §9.1.1 connects recipient-key-compromise impersonation to repudiability. That observation motivates a bounded DHKEM Auth experiment; it does not prove the entire multi-recipient construction or every future hybrid suite. Replay, downgrade, key/version binding, and static-key compromise remain application concerns. deevee is retained as experimental designated-verifier reference code, not an accepted security dependency.
#Variation — Group authentication with explicit history evidence
For shared groups, compare per-recipient authenticated batches with contextual signatures whose personal bindings are separately analyzed. MLS supports strong within-group sender authentication, but does not claim general deniability; RFC 9750 discusses possible deniable key-binding arrangements and their limits (§8.2.1, §8.2.3). Encrypted MLS signatures are not automatically non-transferable.
Late-reader evidence must be labeled according to what it establishes. A newly endorsed checkpoint is not proof that every historical author personally signed its contents. Current membership is checked separately. The collaboration lane also owns the cost and safety of changing authentication or merge semantics across retained history.
#Envelope contract
| Protected binding | Purpose / rejection condition |
|---|---|
| Version, algorithm suite, authentication profile | Reject unsupported suites and downgrade from accepted context policy |
| Scoped object, revision, and exact encrypted representation | Reject substitution between objects, versions, or storage locators |
| Context and applicable policy/causal evidence | Reject unauthorized disclosure or unresolved required state |
| Intended recipient key and version | Reject stale, substituted, or revoked recipient/device bindings under the accepted policy |
| Content-key material and retention policy | Separate future release from keys already delivered; expiry is a policy input |
| Domain separation, nonce/segment structure, replay identity | Prevent cross-protocol confusion, reuse, and application replay |
The object-format lane owns serialization. Authenticated associated data is not necessarily confidential: keep private context and recipient identifiers inside protected fields rather than convenient cleartext storage headers. Do not treat a CEK commitment or audience commitment as automatically private; its construction and exposure need review.
#Key lifecycle and audience transitions
Stopping future envelopes does not make old ciphertext inaccessible to someone who retained its key. Audience expansion is an irreversible disclosure when the new reader receives the key; later convergence cannot undo it. Promotion into another context normally gets fresh ciphertext and keys, while rewrap-only is a reviewed exception with accepted linkability and old-reader access.
The proposed private-storage profile applies application encryption before ERIS. An ERIS capability then reconstructs application ciphertext, not application plaintext. Its convergence secret is not the application's erasure key. Repair access may reveal structure even without a content key. Range delivery must verify the inner streaming-AEAD format; an outer block hash alone does not establish the complete application plaintext's authenticity.
#Likely packages and integration gates
| Candidate from the technology inventory | Narrow integration | Required gate |
|---|---|---|
| libsignal | Pairwise session and descriptor adapter | External-use/API policy, bindings, license, key-state persistence, recovery, and exported evidence |
| OpenMLS | Group APIs with TalkCo credential and accepted-commit policy | Mobile/WASM support, concurrent epochs, late joins, atomic persistence, and evidence profile |
| p2panda-encryption / p2panda-auth | Alternative offline group/security engine | Adopt exact semantics only after authority, partition, retention, and deniability comparison |
| AEAD / streaming-AEAD and HPKE implementation | Application payloads and recipient envelopes | Concrete provider/version still to select; known-answer, misuse, substitution, and migration tests |
| ERIS implementation | Encode already encrypted bytes for independent custody | Interoperability vectors, capability scope, range authentication, and retention boundaries |
| TACo / PRE or threshold adapter | Exceptional conditional key release | Named requirement plus current service, trust, platform, liveness, and recovery review |
OpenMLS documents pluggable crypto and key storage, while its current build matrix does not give mobile/WASM the same tested support as its main targets (OpenMLS Book). libsignal's maintainers explicitly do not support outside use and may change APIs (libsignal README). p2panda exposes modular encryption and authorization components, but their availability is not evidence that TalkCo's composition is audited (p2panda). These primary checks were refreshed on 2026-10-24; no dependency or construction was security-approved.
#Forward secrecy, post-compromise security, and durable objects
Session evolution and an intentionally retained archive have different compromise properties. Old session-key deletion does not erase archive keys, descriptors, device vaults, old checkpoints, backups, notification previews, or search indexes. A recovery root that regenerates every old content key defeats a claim of selective key erasure. Recovery must retire obsolete session state and distinguish historical data from current authority (identity #4, custody #7).
#Post-quantum migration
Algorithm identifiers and a version field are only preparation. A candidate needs mixed-version behavior, downgrade rejection, long-lived object migration, and evidence that replacing a KEM preserves the intended authentication properties. FIPS 203, the MLS PQ ciphersuite work, and Signal's specifications are inputs whose implementation status must be refreshed at selection. Measure key/ciphertext expansion, prekey availability, CPU, memory, battery, churn, and retained-key exposure.
#Where conditional release fits
PRE, TACo, or threshold release stays behind a key-release interface. It requires a property ordinary recipient-held keys cannot supply. A committee's ability to release a key does not establish community legitimacy, and its later refusal cannot retract a released key. Keep ordinary messages, private recipients, sensitive policies, and relationship graphs out of any public control plane. §10 owns the explicit reconciliation of older conditional-release commitments with this gated research position.
#Falsification tests
- Descriptor substitution, replay, stale authority, cross-context use, and downgrade fail according to the accepted context policy.
- Recipient verification/simulation does not permit impersonation to a different honest recipient under the chosen model.
- Exported roots, consent records, introductions, uploads, quota proofs, custody receipts, and recovery records do not recreate forbidden personal-authorship evidence.
- Late readers distinguish reauthenticated material, current checkpoint endorsement, and reported history.
- Revocation, restore, and repair cannot silently reinstate an old device or intentionally erased key path.
- Streaming/range reads detect segment substitution, truncation, reordering, and incorrect object binding.
- Conditional-release and PQ additions pass named requirements and migration/failure tests before admission.
#Open questions and research links
#3 owns deniability, collusion, and group evidence; #4 owns key lifecycle and recovery; #5 owns shared history and key release; #6 owns ERIS/streaming composition; #1 owns retaining or superseding legacy commitments.
Continue to lifecycle, trust, access, tools, or profile tests. Historical evidence remains in Wave 3 and the September authentication analysis.