Architecture

This page presents Tide’s modern architecture for developers and security engineers, detailing core components, data flows, and cryptographic foundations.

1. Design Principles

Tide’s design rests on nine key principles:

Principle	Implementation	Developer Benefit
Assume insider threat	All controls assume the attackeris a privileged insider - root administrator, compromised core vendor, or supply chain maintainer.	Security holds even when trusted roles are compromised; no single insider can exfiltrate keys or subvert policy.
Self-sovereign authority	BYOiD authenticates users viaPRISM, proving password/2FA ownership in zero knowledge and issuing a short lived access-tokens encrypted under an in browser, one time session key.	Users keep full control of their identity, authority and agency; credentials and sensitive data never leave the client.
Quorum enforced governance	Authorization policies and token signatures require a majority of administrators' decentralized signatures before taking effect.	No rogue super admin, insider, or IAM vendor can unilaterally escalate privileges.
Honest minority tolerance	Absolute confidentiality holds if≥ 30 % of nodes in any multi-party operation behave correctly.	Remains safe even when most infrastructure providers are compromised.
Universal verifiability	Client SDK, Server SDK, TideCloak, Fabric, all operates in a provably secure chain, verifiable all the way to the end user.	Trust is anchored in transparent mathematics, not in Tide's brand or specific hardware.
Friction free adoption	TideCloak exposes standard OIDC/OAuth endpoints, preserving the familiar ubiquitous UX.	Drop in replacement for existing authentication and authorization flows, without sacrificing security.
Commodity hardware only	All cryptography happens in software; no TEEs or HSMs are required.	Lower cost, easier portability, wildly scalable, no supply chain risk.
No key ever exists	Utilizing Ineffable Cryptography where every key born split to shard across 20 different nodes and handled exclusively by secure multiparty computation (sMPC) without ever coming together.	No single compromised machine can leak usable secrets - User, MITM, Vendor or even Tide.
Enterprise performance	Five nines performance expectation.	Enterprise grade SLA on performance and continuity.

2. System Landscape

                                                         JWT / OIDC
                                                ┌───────────────────────────┐
                                                │   Platform / Service      │
                                                │  (backend, CI/CD, etc.)   │
                                                └─────────▲──────────┬──────┘
                                                          │          │
                                                          │          │ HTTPS
┌─────────────────────────────────────────────────┐       │          │
│                      End User                   │       │          │
│                (browser / mobile)               │       │          │
└─────────▲─────────┬──────────────▲─────────┬────┘       │          │
          │  HTTPS  │              │         │            │          │
┌─────────┴─────────▼─────────┐    │         │            │          │
│   Secure Web Enclave (SWE)  │    │         │            │          │
│ • Dealer for user flows     │    │         │            │          │
└─────────▲─────────┬─────────┘    │         │            │          │
          │         │              │         │            │          │
          │         │    ┌─────────┴─────────▼────────────┴──────────▼──────────┐
          │         │    │                    TideCloak IIAM                    │
          │         │    │       • Management API, OIDC/OAuth endpoints         │
          │         │    │       • Untrusted dealer for service flows           │
          │         │    └─────────▲──────────────────┬─────────────────────────┘
          │         │              │                  │
          │ ZKP     │ TWELVE MAP   │                  │
          │ sMPC op │ queries      │                  │
┌─────────┴─────────▼──────────────┴──────────────────▼─────────────────────────┐
│                        Tide Cybersecurity Fabric                              │
│                       (Unlimited commodity nodes)                             │
│                         • Shard Store                                         │
│                         • sMPC Ineffable Engine                               │
│                         • ZK Prover                                           │
└───────────────────────────▲───────────┬───────────────────────────────────────┘
                            │  Proofs   │ Merkle root anchoring
                  ┌─────────┴───────────▼───────────┐
                  │  Decentralized Repository       │
                   
                  └─────────────────────────────────┘

2.1 Component Roles

Secure Web Enclave (SWE) - Browser-native delivered application that plays the transparent dealer role in every user initiated sMPC session and is the sole user interface to Tide.
TideCloak - Identity, Immunity & Access Management service exposing BYOiD and Quorum Enforced Authorization over standard OIDC/OAuth endpoints. Acts as a trustless agent for backend operations.
<a id="twelve-map"></a>Platform / Service - Customer back end or CLI that consumes TideCloak JWTs and, when needed, invokes Fabric operations directly through the embedded dealer library. Replaces traditional IAM dependencies without sacrificing existing OIDC/OAuth integration patterns.
Cybersecurity Fabric - Global decentralized swarm of independent nodes that store key shards, run the secure-Multi-Party-Computation engine behind Tide's Ineffable Cryptography (i.e. key generation, encrypt, sign, authenticate), and emit ZK proofs for each operation.
TWELVE MAP - A self verifying, directory mapping each key ID to its current multi node shard set (Tide Wide Enumerated Ledger of Verifiable Entries – Mapping Authoritative Pointers).
Decentralized Repository - Quorum-controlled decentralized database sync that anchors proofs and TWELVE MAP roots for verifiable public source-of-truth and auditability.

3. Core Subsystems

3.1 Secure Web Enclave (SWE)

Aspect	Detail
Delivery	Signed HTML/JS/WASM bundle served via Tide as CDN; code integrity guarantees against compromise.
Dealer duties	Chooses nodes (via TWELVE MAP), distributes entropy, interpolates artefacts, facilitates verifiability.
Local verification	Runs ZK verifier and rejects any inconsistency before handing results to the user.
User journeys	PRISM login, new key ceremonies, decrypt & download, threshold signatures.

3.2 TideCloak

Capability	Description
BYOiD (Bring Your Own Identity)	A privacy maximizing, self sovereign authority provider built entirely on PRISM. Credentials (password, 2FA factor, biometrics) are verified in zero knowledge - no node ever witnesses the secret, nor can any offline attack recover it. Authentication yields a short lived access-token encrypted for the user alone and bound to aone time, in browser session key , guaranteeing confidentiality and unlinkability while preserving the familiar username and password UX (no Passkey migration needed).
Quorum Enforced Authorization	Policy changes require a cryptographic majority of administrator approvals where each admin key is itself sharded on the Cybersecurity Fabric. Final access-token is validated and signed by only by a verifiable Fabric key. No rogue super admin, insider, or compromised IAM vendor can forge or escalate privileges.
Dealer Library	Re uses the same crypto engine shipped with the Secure Web Enclave, enabling micro services and CLI tools to run MPC operations (Generate, Encrypt, Decrypt, Sign, Authenticate) directly.
Standards Interfaces	Exposes OIDC & OAuth 2.0 endpoints plus standard JSON Web Key Sets (JWKS), so existing platform code can drop in TideCloak with minimal changes.
Adapters	Kubernetes admission controller, AWS IAM proxy, generic OIDC bridge, Postgres row level security extension, and more.

3.3 Cybersecurity Fabric Nodes

Module	Function
Shard Store	Holds one encrypted shard for each key it is assigned.
MPC Engine	Tide Ineffable Cryptographic implementation of all key operations (DKG, Encrypt, Decrypt, Sign, PRISM, etc).
ZK Prover	Produces non interactive proof; includes honest minority checks and dealer commitments.

3.4 TWELVE MAP Directory

(key ID, [node₁ … node₂₀], version)  +  ZK proof

Replicated to every Fabric node.
Root hash anchored in State Ledger every ledger cycle.
Clients use mapping only after verifying its proof.

3.5 Decentralized Repository

Compact Merkle tree of all proof hashes and directory roots.
Periodical decentralized database syncronization.
Enables external auditors to replay any operation independently of Tide.

4. Cryptographic Foundations

Parameter	Value
Shard count(`n`)	20
Threshold(`t`)	⌈0.7 · n⌉ = 14
Key Presentation	Edward25519, AES GCM, PRISM
sMPC system	Shamir-Secret-based Ineffable Cryptography (post quantum resilient)
Proof system	Ed25519, BEd25531

4.1 PRISM Protocol (high level)

SWE blinds user credentials as challenge c.
Each node evaluates its threshold-share of the obfuscated pseudorandom function on c and returns (share, proof).
SWE aggregates ≥ t honest shares, unblinds the result and derives τ (authentication token), and receives a final proof π.
τ‖π is used with TideCloak or directly in API calls; any verifier can validate π.

Other key operations (DKG, Encrypt, Decrypt, Sign, Authenticate, etc.) follow a similar single round or two round pattern with proofs.

5. Operational Flows

5.1 Authentication Flow

User → SWE → Fabric → SWE → TideCloak → App backend

Typical p95 latency: 3s end to end.

5.2 Key Generation Flow

SWE/TideCloak (dealer) ↔ Fabric (2 non-interactive Nested Shamir Secret Sharing rounds) ↔ TWELVE MAP update ↔ Ledger anchor

5.3 Encryption / Decryption / Signing

Double round exchange: dealer broadcast → Fabric replies → interpolation → proof.

6. Security Model

Threat	Outcome
Up to 13 of 20 nodes malicious	Confidentiality and integrity remain intact; proofs still verify.
Malicious dealer	Can only refuse service; any deviation is caught by honest nodes. Can be mitigated by end user / plugin.
Directory poisoning	Fails without forging both ZK proof and ledger root (publicly auditable). Network will self-heal.
Hardware compromise	Single node yields at most one useless shard; attacker still needs ≥ 14 specific nodes and must forge proof π.

7. Developer & User Touchpoints

Interface	Purpose	SDK / Tool
Secure Web Enclave	Human log in, key management, document decrypt, verifiability	Delivered as signed web app
TideCloak API	Policy enforcement, service to service auth, admin API	C#, TypeScript, Java SDKs
Verifier CLI	Proof replay, ledger inspection	Open source binary

8. Performance & Scaling

Node scaling - Read/operate paths scale linearly with node count.
Global latency - Dealer picks geographically close nodes; p95 < 3s worldwide.
Directory churn - Transaction sync every 5 seconds. Complete dLog sync every 24 h; TWELVE MAP versioning makes sync rotations seamless.

9. Summary

Tide’s architecture eliminates single points of failure and external trust anchors by combining:

Honest minority sMPC with a high (14 of 20) threshold.
Provable Security via User side verification at the Secure Web Enclave.
A self verifying directory (TWELVE MAP) and decentralized repository.

Together these elements guarantee that even if most infrastructure is compromised, no attacker can decrypt, sign, or impersonate without detection - and honest parties can prove it to anyone, at any time, including runtime.

1. Design Principles​

2. System Landscape​

2.1 Component Roles​

3. Core Subsystems​

3.1 Secure Web Enclave (SWE)​

3.2 TideCloak​

3.3 Cybersecurity Fabric Nodes​

3.4 TWELVE MAP Directory​

3.5 Decentralized Repository​

4. Cryptographic Foundations​

4.1 PRISM Protocol (high level)​

5. Operational Flows​

5.1 Authentication Flow​

5.2 Key Generation Flow​

5.3 Encryption / Decryption / Signing​

6. Security Model​

7. Developer & User Touchpoints​

8. Performance & Scaling​

9. Summary​