Untilum
← Back to Untilum Protocol

RFC-0002: Threat Model

Status: Last Call · Date: 2026-07-17 · Editors: Untilum project — hello@untilum.com

Part of the TSP RFC series; see the series index for the Last Call window and how to comment. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals.

Abstract

This document defines the threat model of the Untilum Protocol: the assets under protection, nine adversary classes (T1–T9) — from compromised storage, platforms, and beacon networks to quantum attack and supply-chain compromise — and the designed outcome for each, enforced by construction and covered by tests rather than by policy. It closes with a residual-risk summary and serves as the security-considerations baseline for the entire RFC series.

1. Assets

2. Adversaries and outcomes

Each threat lists the adversary’s capability and the protocol’s designed outcome. “Designed outcome” means: enforced by construction and covered by tests, not by policy.

T1 — Compromised storage

Adversary fully controls where capsule bytes live (Arweave gateways, mirrors, any replica) — can read, alter, substitute, or delete them.

Outcome: no plaintext disclosure. Storage only ever holds ciphertext and public parameters (RFC-0004). Alteration is detected: ciphertext is authenticated (AES-GCM) and additionally pinned by payload.hash; the immutable core is pinned by capsuleHash and the creator signature. The residual risk is availability (A4) — deletion — mitigated by permanent storage and appendable replicas, not by trust.

T2 — Compromised platform

Adversary fully controls this project: servers, domains, releases, the operators themselves (insider, coercion, or seizure).

Outcome: cannot decrypt. The platform never possesses plaintext, passwords, or keys — there is nothing to seize (G2). A compromised platform can ship malicious new software, which threatens capsules created after the compromise (T8); capsules already sealed remain openable by any conforming implementation from the public documents.

T3 — Compromised beacon network

Adversary controls (or colludes with a threshold of) one beacon network’s operators, or the network simply dies.

Outcome: only this beacon is affected; blast radius is set by the unlock policy.

  • anyOf: early-opening resistance equals the weakest listed network (a compromised one can produce its round early → early opening of the time factor for capsules locked to it, though the password factor still holds). Liveness survives any single death.
  • allOf: a compromised beacon alone learns one XOR share — information-theoretically nothing. Early opening requires compromising every listed network. The dual cost: one dead network strands the capsule (A4), so allOf SHOULD be paired with custodial fallbacks.

A beacon that merely lies (serves forged signatures) achieves nothing: every signature is verified against the pinned group key before use (RFC-0005 §4), from any source.

T4 — Stolen capsule document

Adversary obtains the full capsule bytes (they are public by design).

Outcome: nothing before the instant, password-guessing after. Before: the time factor is missing for everyone (G1). After: the adversary still needs the password; offline guessing is slowed by Argon2id at enforced parameter floors. Password strength is the user’s lever — the protocol’s job is to make each guess expensive and to never weaken to one factor.

T5 — Password compromise (before unlock)

Adversary knows the password (shoulder-surfing, reuse, coercion of the creator).

Outcome: still cannot open early. The time factor is independent (G3): the beacon signature for the unlock round does not exist yet, and no party can produce it. Knowing the password buys the adversary exactly what the legitimate opener has — a wait.

T6 — Network adversary at open time

Adversary MITMs or operates every beacon endpoint the opener queries.

Outcome: denial of service at worst. Beacon responses are verified against pinned public keys (RFC-0005 §4); a forged round fails verification (critical test 4, tsp-v1.md §8.5). The adversary can only refuse to serve — mitigated by multiple sources: API, relays, mirrors, manual paste.

T7 — Quantum attack

Adversary has a cryptographically relevant quantum computer.

Outcome: early opening becomes possible — stated honestly. The timelock’s pairing-based IBE (BLS12-381) falls to a quantum adversary: they can derive the round key early, collapsing the time factor. The password factor (Argon2id + AES-256-GCM) remains quantum-resistant at these parameters, so confidentiality degrades to single-factor, not to zero. The mitigation for the time factor is organizational, not cryptographic — threshold custodians (Shamir) for long horizons; a PQ KEM wrap protects only the password factor and MUST NOT be marketed as quantum-safe timelock. User documentation MUST state this plainly.

T8 — Malicious implementation / supply chain

Adversary corrupts the SDK, an application build, or a dependency used at seal time.

Outcome: out of protocol scope, bounded by verifiability. A malicious sealer can exfiltrate at creation — no format can prevent that. The protocol’s containment: capsules are verifiable by independent implementations (RFC-0007), the decryptor inlines its dependencies, and conformance is testable from documents alone, so a diverse-implementation ecosystem limits the value of corrupting any single one.

T9 — Malformed capsule as attack input

Adversary feeds a crafted document to an opener or verifier.

Outcome: rejected before cryptography. Structural validation — exact algorithm identifiers, KDF parameter floors (anti-downgrade), pinned chain hashes, unknown-field rejection — runs at parse time (capsule-v1.md §3 for v1; tsp-v1.md §10.1.0 for v2). Openers additionally verify payload.hash before decrypting by-reference ciphertext.

3. Explicitly out of scope

Endpoint compromise at open time (a keylogger reads the password — nothing document-shaped survives that); rubber-hose cryptanalysis; correctness of the plaintext itself; anonymity (RFC-0001 §3).

4. Residual-risk summary

# Threat Worst credible outcome
T1 Compromised storage Availability loss; never plaintext
T2 Compromised platform No effect on sealed capsules
T3 Compromised beacon Scoped by policy; weakest-link (anyOf) or none-alone (allOf)
T4 Stolen capsule Post-unlock password guessing, Argon2id-priced
T5 Known password Wait until the instant, same as everyone
T6 Hostile network Denial of service only
T7 Quantum adversary Early opening of the time factor; password factor holds
T8 Supply chain Bounded by independent verifiability
T9 Crafted input Rejected pre-crypto

5. Security Considerations

This document is, in its entirety, a statement of security considerations for the Untilum Protocol; the other documents in the series reference it as their baseline. Any change to a designed outcome stated here is a normative change under RFC-0008 §4, and the residual-risk summary in §4 MUST be kept truthful in user-facing documentation — in particular the honest statement of T7 (quantum risk).

6. References

6.1. Normative

6.2. Informative

Editors’ Addresses

Untilum project — Editors of the TSP RFC series Email: hello@untilum.com · Issues: https://github.com/untilum/protocol/issues

Revision History

Date Status Change
2026-07-07 Draft Initial version.
2026-07-17 Last Call Publication pass: BCP 14 boilerplate, Abstract, Security Considerations, References, Revision History added; no normative changes. Entered Last Call per RFC-0008 §4.