Addendum: Design Rationale & Verification Status | Cyber Immunity Whitepaper

Purpose

The Tide architecture composes peer-reviewed cryptographic primitives with operational governance and economic incentive structures, each chosen for specific, defensible engineering reasons. This document explains the rationale behind each major design decision and documents the verification status of every component, giving evaluators the information needed to assess deployment readiness.

1. Cryptographic Foundations & Verification Status

The Tide architecture composes multiple cryptographic constructions. Their verification maturity reflects the standard academic lifecycle, from peer-reviewed publication through independent audit. The majority rest on formally proven, peer-reviewed foundations.

Primitive	Role	Publication Status	Formal Security Reduction	Independent Audit
PRISM (Threshold OPRF)	Distributed password verification; offline attack elimination	Published. Wang, Hertzog et al., Springer CIMSS2023	Yes (in published paper). Reduction to One-More DH assumption	Covered by academic peer review
Nested Shamir DKG	Dealerless key generation across ORK swarm	Published. Hall, Hertzog et al., arXiv:2309.00915, AustMS2021	Yes (in published paper). Standard Shamir composition proof	Covered by academic peer review
Threshold Signing	VVK JWT signing, CVK session signing, KeyleSSH	Well-established. Similar to FROST (Komlo & Goldberg, SAC 2020)	Extensive formal treatment in FROST literature	Widely analyzed
Double-Blind Threshold Signature Scheme	CMK blind signing, vendor-unlinkable identity derivation	Pending joint publication with RMIT University	Algebraic correctness proof published in this series. Simulation-based security proof under joint review with RMIT University	Multi-year adversarial analysis with RMIT University; formal joint publication in progress
Specialized Twisted Edwards Curve (BEd255475)	Domain separation for blind-signature ceremony	Introduced as part of Double-Blind TSS; not independently published	Correctness verified. SafeCurves-equivalent analysis forthcoming	Formal analysis scoped; curve introduced to eliminate a proven attack vector. Joint publication in progress

What this means for an evaluator: The system's authentication hardening (PRISM), key lifecycle (Nested Shamir DKG), and organizational signing (threshold signature) rest on peer-reviewed, formally proven foundations. The vendor-unlinkable identity derivation (Double-Blind TSS) rests on a construction whose algebraic correctness is demonstrated in this series and whose adversarial analysis has undergone multi-year review at RMIT. The Double-Blind TSS is algebraically proven and adversarially reviewed, completing the standard academic publication lifecycle with RMIT University.

The specialized curve warrants independent analysis. It was introduced to prevent a specific, well-defined attack (malicious Enclave weaponizing the ORK swarm as a signing oracle, detailed in Protocol: Double-Blind TSS). Standard domain separation techniques (hash prefixes, DOM flags) were evaluated and found insufficient under adversarial Enclave conditions. Curve-level separation eliminates the attack class at the cost of introducing a non-standard curve requiring its own analysis. We consider this a favorable exchange: a provable attack eliminated, in return for an analysis obligation that is bounded and well-scoped.

Verification roadmap: The Double-Blind TSS is completing its verification lifecycle. The remaining verification milestone follows a clear path: (1) formal publication of the RMIT joint paper, including simulation-based security proofs and explicit hardness reductions; (2) independent cryptographic audit of the Double-Blind TSS construction and the specialized curve's properties (twist security, completeness, cofactor handling) by a recognized firm; (3) open-source publication of the reference implementation with an active bug bounty program covering the blind-signature and curve arithmetic code paths. The published primitives (PRISM, Nested Shamir DKG, threshold signatures) have already completed this path.

2. Trust Foundations: Cryptographic, Operational, Economic

Article 9 identifies five irreducible trust assumptions. This section classifies them by what enforces them, because the remediation for a failed assumption differs fundamentally depending on whether it is mathematical, operational, or economic.

A governing design principle shapes every tradeoff that follows: the architecture prioritizes confidentiality over availability. If the network is degraded, the system fails closed: operations halt, but no key material is exposed. If the network is healthy but an individual component is compromised, security properties hold while the compromised component is detected and replaced. This asymmetry is deliberate. A temporary denial of service is recoverable. A key compromise is not. Every design decision in this section should be read through that lens.

Cryptographic (enforced by mathematics)

These properties hold regardless of the behavior of any participant, provided the underlying mathematical hardness assumptions are intact:

No key ever exists in complete form. Nested Shamir DKG generates keys as distributed shares. The complete private key is never computed. This is a structural property of the construction, not a policy.
No credential artifact exists at rest. PRISM's TOPRF evaluation is an emergent function of the live network. There is no hash, no salt, no stored secret to exfiltrate.
Blind-signature token issuance. The Double-Blind TSS ensures ORKs cannot see the message or verification key, and the vendor cannot link identities across services. (Detailed in Section 1.)
Threshold forgery resistance. Producing an unauthorized signature requires simultaneous compromise of 14 independently operated nodes within a single transient ceremony window.

Hardness assumptions: Elliptic Curve Discrete Logarithm Problem (ECDLP) on Curve25519 and on the specialized twisted Edwards curve; SHA-256 collision and preimage resistance; random oracle model for hash functions used in Schnorr challenges. These are standard assumptions shared with the vast majority of deployed cryptographic systems.

Operational (enforced by governance and infrastructure)

These properties depend on real-world conditions that cannot be guaranteed by mathematics alone:

Node independence. The 14-of-20 threshold is meaningful only if the 20 nodes in a swarm are genuinely independent: different operators, different infrastructure, different jurisdictions. A single entity secretly controlling 14 nodes behind separate legal facades would render the threshold meaningless.

How this is enforced: Operators must meet staking criteria (economic bond forfeited on SLA breach), undergo accreditation, and operate on independently verifiable infrastructure. The TWELVE-MAP transparency framework provides continuous, public attestation of node operator identity, geographic location, and infrastructure independence. Covert measurement swarms benchmark node behavior and report to an immutable shared repository. Swarm assignment incorporates verifiably pseudo-random selection with optional jurisdictional constraints.

What this does not guarantee: Perfect Sybil resistance. A sufficiently resourced adversary willing to create 14 independently-appearing organizations, post 14 independent bonds, operate 14 geographically distributed data centers, and maintain 14 independent operational histories could theoretically subvert a single swarm. The economic cost of this attack scales with the staking requirement and the number of target swarms (each user has a different swarm). It is not cryptographically impossible; it is economically prohibitive and operationally detectable.
Browser SRI enforcement. The SWE's integrity depends on the browser correctly refusing to execute a script whose hash does not match the declared SRI value. This is a widely deployed, well-tested browser feature, but it is a software property, not a mathematical one.

Fallback: The Authenticator App provides an independent authentication path that does not rely on the browser as a credential surface. For deployments where browser integrity is an unacceptable risk, the Authenticator App removes the browser from the credential path entirely.

Economic (enforced by incentive structures)

Payer integrity. The Payer (economic clearinghouse) must honestly validate vouchers and settle payments. The Payer holds no cryptographic material and cannot influence ceremony outcomes. Its compromise affects only economic settlement.

Bounded damage: A compromised or offline Payer affects at most one billing cycle. ORK operators can validate cached licensing credentials for a 7-day grace period, providing time for remediation or migration to an alternative Payer. The Payer role is an open specification: any entity implementing the validation protocol can serve as a Payer, preventing single-vendor lock-in at the economic layer.

3. The Browser Execution Environment

The SWE (Secure Web Enclave) executes in the user's browser. This is a deliberate architectural choice: it places the cryptographic agent under the user's control, makes the code inspectable via SRI, and avoids dependence on proprietary hardware. Every browser-based identity system, including Okta's sign-in widget, Auth0's Universal Login, Google's Sign-In page, and Microsoft's MSAL.js, executes JavaScript in the same environment with the same exposure. None of these provide SRI verification of their authentication code. The SWE is the only browser-based authentication client whose code integrity can be independently verified by the relying party, and the only technology whose integrity can be independently verified by the end-user in real-time.

What a compromised SWE cannot do:

Extract any ORK's key share (threshold property; the SWE never receives complete shares).
Forge signatures for other users (no access to their PRISM products or CMK shares).
Produce valid standard Ed25519 signatures using the ORK swarm (curve-level domain separation).
Bypass Forseti policy enforcement (policies execute on ORK nodes, not in the SWE).
Replay a previous session (non-extractable session keys, timestamps, destroyed cache entries).

Residual browser-environment risks (shared with all browser-based authentication):

Capture the current user's password during entry (before blinding). This includes compromise via malicious browser extensions, DOM-based XSS, or OS-level malware with access to browser memory or input APIs.
Deny service (refuse to complete the ceremony).
Attempt to produce blind signatures on attacker-chosen messages (contained by curve-level domain separation; signatures are valid only on the specialized curve and produce identities bound to the attacker's own vendor key).

For deployments requiring hardware-grade guarantees: The Tide Authenticator App (Article 7) provides device-bound, biometric authentication where the user's credentials never enter the browser. The App performs the PRISM and blind-signature ceremonies on a mobile device using hardware-protected key storage, then relays the authenticated result to the SWE through a transient ORK-mediated channel. This eliminates password capture, keystroke logging, and browser extension attacks from the threat model entirely.

4. The Authentication Factor

The primary BYOiD ceremony accepts a password as its knowledge factor.

What PRISM does to the password: The password is hashed to a curve point, blinded with a random scalar, and submitted to the ORK swarm for TOPRF evaluation. No ORK sees the password or even the password-derived point. The verification function is an emergent property of the live network. It cannot be constructed offline. Each guess requires a network round-trip to 14+ independent nodes, rate-limited at the protocol level. There is no stored hash, no salt, no verification artifact that can be exfiltrated. The password, in the PRISM context, is an input to a distributed function, not a stored secret.

What PRISM does not do: It does not prevent phishing (a user can be tricked into entering their password on a fraudulent site), credential reuse across non-Tide services (a user who uses the same password elsewhere is vulnerable to breaches at those services), or weak password selection. These are properties of the knowledge factor itself, not the verification mechanism.

The passwordless path: The Tide Authenticator App replaces the password with device-bound biometric authentication. The App holds a Device Key (DVK) generated via the same Nested Shamir DKG, protected by the device's secure enclave (Face ID, Touch ID, Android biometrics). The user authenticates via biometric, the App executes the PRISM and blind-signature ceremonies using the DVK, and the result is relayed to the SWE. No password enters any surface. The cryptographic guarantees are identical to the password-based flow.

The architectural position: BYOiD is factor-agnostic. The PRISM construction accepts any knowledge factor that can be hashed to a curve point. The password flow is the universally deployable baseline. It requires no additional hardware or software. The Authenticator App is the recommended path for deployments where phishing resistance and credential-surface elimination are requirements. Both paths produce identical downstream artifacts (VUID, gCMKAuth, blind-signed token) and both traverse the same four architectural layers.

5. Performance Characteristics

The BYOiD ceremony completes in two sequential round-trips between the SWE and the ORK swarm, plus token delivery to TideCloak. Both round-trips carry PRISM and blind-signature data in the same messages. The sub-protocols are interleaved, not sequential.

Latency profile:

Phase	Network Calls	Dominant Cost
Voucher acquisition	1 round-trip (SWE → Vendor → SWE)	Network RTT to vendor
Convert (Round-Trip 1)	1 parallel fan-out to 20 ORKs	Slowest ORK response (P95 of 20 geographically distributed nodes)
Client-side processing	0 (local computation)	~20 scalar multiplications, Lagrange interpolation, AES operations
Authenticate (Round-Trip 2)	1 parallel fan-out to 14-20 ORKs	Slowest ORK response
Token delivery + VVK signing	1 round-trip to TideCloak + 1 fan-out to VVK ORKs	Network RTT + VVK ceremony

The total ceremony involves approximately 4-5 sequential network round-trips with parallel fan-out to ORK swarms. Client-side computation (elliptic curve operations, AES, interpolation) is negligible compared to network latency on modern hardware, including mobile devices.

What determines real-world latency: The dominant factor is network round-trip time to geographically distributed ORK nodes. The convergence wait (up to 1 second for all 20, up to 5 seconds for the threshold 14) provides a bounded upper limit. Under normal network conditions, the ceremony completes well within this envelope. Tail latency (P99) is determined by the slowest ORK in the swarm. Geographic distribution improves security but increases variance.

Remember-me optimization: Within the session window (1-3 hours), re-authentication uses stored self-sealed capsules and skips the PRISM password-verification step entirely. This reduces the ceremony to a single Convert/Authenticate round-trip pair for the blind-signature component only.

Benchmarking roadmap: As the network scales toward 10,000 platform customers, we intend to publish P50, P95, and P99 latency benchmarks across device classes and geographic regions. The protocol's round-trip count is fixed by design, the cryptographic operations are well-characterized, and have been tested in a lab environment.

6. Deployment Maturity and Metadata Exposure

Two components of the architecture warrant specific discussion, not because they are architecturally centralized, but because their current deployment state or metadata exposure may raise questions during evaluation.

The Payer ORK Network

The Payer is a specialized ORK that manages the real-time clearinghouse function of the voucher system. It validates voucher signatures, enforces credit balances, checks voucher uniqueness (replay prevention), and issues redemption proofs, providing each ORK on the Fabric with a cryptographic guarantee that a request is funded and the servicing ORK will be compensated.

Architecture: The Payer is designed as a federated role, not a singular one. Each Payer operator runs a load-balanced cluster (shared state, shared private key for scale) and holds a unique Payer private key. ORKs are configured with a list of approved Payer public keys, with no architectural limit. Any entity that implements the Payer validation protocol and is recognized by the Tide Foundation's governance process can operate as an independent Payer. Multiple Payers with different keys, each trusted by different subsets of ORKs, is the intended steady-state topology. The governance model for Payer accreditation is identical to the governance model for ORK operator accreditation.

What it sees: The vendor's ephemeral payment identity and an obfuscated derivative of the vendor's organizational key. It does not see user identities, ORK identities, key material, or ceremony content.

What it controls: Economic settlement only. A Payer that refuses to validate vouchers can halt operations for the vendors whose ORKs trust that specific Payer, but only that Payer's population. A Payer that colludes with ORKs could correlate vendor payment identities with ORK operational data, but cannot recover user identities, passwords, or key material from either source. No Payer holds cryptographic material relevant to authentication, signing, or encryption ceremonies.

Current deployment: The Payer role is architecturally federated, supporting multiple independent operators. The initial deployment operates a single Payer cluster, following the same graduated rollout path as the ORK network, which launched with a limited operator set before expanding to its current distributed topology. As additional Payer operators are accredited, the economic layer will achieve the same operator diversity as the ORK layer. ORKs cache licensing credentials with a 7-day grace period, ensuring that operations continue uninterrupted even if a Payer cluster is temporarily unavailable.

The Home ORK

The Home ORK serves swarm rosters. Given a user identifier, it returns the list of ORKs holding that user's key shards.

What it sees: The user identifiers it serves and the ORK composition of their swarms. It does not see passwords, key material, ceremony content, or vendor associations.

What it controls: Roster responses. A compromised Home ORK can return a stale or incorrect roster, causing the SWE to contact the wrong ORKs and fail the ceremony. It cannot redirect the SWE to malicious nodes that would be accepted, as the SWE verifies each ORK's identity via its public key, and a substituted node would fail the threshold signature verification.

Metadata exposure: The user-to-swarm mapping is operationally sensitive. An adversary with sustained access to a Home ORK learns which users share which ORK populations, though not what those ORKs are used for, which vendors are involved, or any credential material.

Mitigation: Home ORK assignment can rotate. The roster itself is public metadata (ORK public keys are not secret). The Home ORK role requires no elevated trust. It is a convenience optimization (directing the SWE to the correct swarm), not a security-critical component.

7. Confidentiality-First Design: Why There Is No God Mode

Traditional IAM platforms maintain emergency "break-glass" accounts with unilateral root privileges. These accounts are the god-mode vulnerability behind many of the most catastrophic real world breaches: a single compromised admin credential can override every security control in the system. Tide eliminates this entire attack class. No backdoor exists because no backdoor can exist; the cryptographic architecture makes it structurally impossible.

The 14-of-20 threshold delivers this guarantee: even if 13 of a user's 20 ORK nodes are actively malicious, the key cannot be reconstructed or misused. The same arithmetic means the system fails closed rather than failing open. If 7 nodes are unavailable, operations on that key halt rather than proceeding insecurely. Confidentiality failures are permanent and catastrophic (a compromised key cannot be un-compromised), while availability failures are temporary and recoverable (the swarm can be reconstituted).

Automatic recovery from availability degradation: When the Fabric detects a degraded share set (nodes offline or unresponsive), Key Healing (Article 3) automatically initiates. A threshold of healthy ORKs collaboratively computes a replacement share for a new node, using the homomorphic properties of the existing shares, without reconstructing the key. The swarm restores itself to full strength. The 7-day licensing grace period (Article 8) provides an operational buffer during reconstitution: ORKs continue operating on cached credentials while healing proceeds.

The no-god-mode guarantee. In TideCloak, no break-glass bypass exists. This is the central guarantee. A technical mechanism that circumvents the cryptographic quorum would recreate the god-mode vulnerability the entire architecture is designed to eliminate. If a bypass exists, an attacker will eventually find and exploit it. The absence of break-glass is the design.

Quorum design for operational continuity: Organizations that follow recommended quorum practices (e.g., 2-of-5 rather than 3-of-3) with independent recovery paths maintain uninterrupted operational continuity. The architecture guarantees that no external party, including Tide, can override an organization's cryptographic governance. This is the property that eliminates insider threats, vendor backdoors, and the entire class of god-mode compromises. Organizations should: (1) set quorum thresholds appropriate to their operational reality; (2) ensure quorum members have independent recovery paths (Tide's Decentralized Account Recovery allows individual administrators to regain access via threshold-validated secondary authentication); (3) treat quorum continuity as a business continuity planning item with the same rigor as disaster recovery for other critical infrastructure. The Ragnarök Protocol provides the ultimate exit, but it requires a functioning quorum to initiate. These are the properties of a system that has genuinely eliminated centralized authority.

8. Comparison Methodology

Articles 4 and 9 compare the Tide architecture against existing systems: FIDO2/WebAuthn, threshold MPC solutions (Fireblocks, Lit Protocol, Web3Auth), and traditional IAM (Okta, standard Keycloak). These comparisons warrant a note on methodology.

FIDO2 / WebAuthn / Passkeys. FIDO2 is a mature, widely deployed standard with strong formal foundations, extensive real-world validation, and broad ecosystem support including passkey synchronization across devices. Tide does not claim to replace FIDO2. The comparison identifies structural differences (device binding vs. network distribution, hardware attestation vs. code verifiability), not deficiencies. FIDO2's domain-origin binding provides phishing resistance that password-based flows, including Tide's primary BYOiD ceremony, do not inherently match. For deployments requiring phishing resistance, the Tide Authenticator App provides a comparable device-bound path.

The systems solve different problems at different layers. FIDO2 secures user authentication against server-side credential theft and phishing. Tide secures the entire authority infrastructure (authentication, token signing, governance, encryption) against centralized compromise. An organization may deploy both: FIDO2 or the Authenticator App as the authentication factor, with Tide's distributed architecture securing everything downstream.

Threshold MPC solutions. The comparison table in Article 4 evaluates Fireblocks, Lit Protocol, and Web3Auth against properties relevant to Tide's scope (credential hardening, vendor unlinkability, verifiability model). These properties are not goals those solutions were designed to achieve. They were built for key custody, wallet infrastructure, and signing-as-a-service, addressing different problems with different requirements. The comparison illustrates scope differences, not deficiencies. In the domains those solutions were designed for (institutional asset custody, blockchain transaction signing, wallet-as-a-service), they offer mature, production-validated capabilities that Tide does not replicate.

Traditional IAM. The comparison in Article 9 evaluates attack outcomes (server compromise, database breach, admin escalation) under traditional IAM vs. TideCloak. This comparison is structurally fair: both systems occupy the same role (identity and access management for enterprise applications), and the attack scenarios are drawn from real-world incidents. The comparison does not claim TideCloak is more mature, more widely deployed, or more feature-complete than established IAM platforms. It claims the attack surface topology is structurally different.

9. Protocol Continuity and Exit

An architecture that eliminates centralized authority must also ensure that its users are not subject to a different form of lock-in: dependence on the decentralized network itself.

The ORK network is permissionless. Any entity meeting staking criteria can operate an ORK node. The network's continued operation does not depend on Tide Foundation. It depends on the economic viability of node operation and the availability of the protocol specification. Both the protocol and the SWE are designed as open specifications.

The SWE is SRI-verifiable and rehomeable. The SWE code can be served by any node on the network, hosted on the vendor's own infrastructure, or forked entirely. Its correctness depends on the protocol, not on Tide's hosting.

Ragnarök is the contractual exit. The Ragnarök Protocol (Article 3) allows an organization to export its complete VVK and exit the Tide network under cryptographic quorum approval. Reconstruction occurs exclusively within the organization's sovereign environment. This is the architectural guarantee that "ineffable" is a security property protecting the organization, not a constraint on its sovereignty.

The timing constraint: Ragnarök requires an operational ORK network to execute. An organization concerned about network degradation should trigger Ragnarök before the network becomes non-functional. The 7-day licensing grace period provides a buffer: if the Payer goes offline, ORK operations continue on cached credentials for one week, during which Ragnarök can be initiated.

What Tide Foundation's absence would affect: Protocol governance (upgrade decisions, staking criteria changes), Payer operation (if no alternative Payer exists), and SWE maintenance (security patches, feature development). It would not affect: ORK node operation (independently operated), key material (distributed across ORKs, not held by Tide), or the cryptographic guarantees (mathematical, not organizational).

10. Other factors for consideration

Quantum readiness. While the current architecture relies on ECDLP hardness, a foundation threatened by future quantum computing, Tide is proactively developing post-quantum migration pathways. Supported by a Research Council grant together with Distinguished Professor Willy Susilo at UoW, and in collaboration with joint research partners like RMIT, Deakin, the Fabric is being adapted to support NIST-approved algorithms, lattice-based threshold signatures, and hash-based commitments.

Regulatory / Legal. While the protocols are designed to meet or exceed common standards and frameworks. Expert advice should be sought to determine legal and stanrds compliance in relevant jurisdictions.

Governance evolution. The cryptographic quorum mechanisms that govern key lifecycle and policy changes are well-specified. Meta-governance decisions, including accrediting ORK operators, and approving protocol upgrades, are actively guided by the Tide Foundation. The Foundation operates as a nonprofit organization established specifically to provide open, responsible governance for the Tide Cybersecurity Fabric, ensuring the network is managed for the benefit of its users.

Summary

This document has covered the engineering rationale and verification status across the Tide architecture. Three of five cryptographic primitives (PRISM, Nested Shamir DKG, threshold signatures) are peer-reviewed and formally proven. The remaining two (Double-Blind TSS and the specialized curve) are completing the standard academic publication lifecycle with RMIT University, algebraically proven and under multi-year adversarial review.

The architecture prioritizes confidentiality over availability, failing closed rather than failing open. The same threshold arithmetic that requires 14 simultaneous breaches to compromise a key also ensures that degraded nodes halt operations rather than proceed insecurely. Key Healing automatically restores the swarm to full strength, and the absence of break-glass access eliminates the god-mode vulnerability that enables the most damaging class of real-world breaches.

The architecture contains no centralized cryptographic components. The Payer and Home ORK roles are architecturally federated, with current deployments following a graduated rollout toward the intended multi-operator topology. The Home ORK's metadata exposure (user-to-swarm mappings) is bounded and carries no credential or vendor information. The browser execution environment is a shared industry constraint; Tide adds SRI-based code integrity verification and an alternative Authenticator App path that removes the browser from the credential surface entirely. The primary authentication factor is a password whose security properties under PRISM differ fundamentally from traditional password authentication, and a passwordless alternative exists - both fully decentralized.

The cryptographic properties described in this series hold under standard hardness assumptions shared with the vast majority of deployed systems. The operational properties depend on clearly identified governance mechanisms. Organizations evaluating deployment should design quorum structures appropriate to their operational reality and treat quorum continuity as a business continuity planning item.