Security

Security in Phaze is declarative and field-driven: you don’t hand-wire signing, verification, or key handling — you add a field to a Phaze Transport action (sign:, encrypt:) and the compiler emits the right code on both ends. The design has one organizing principle and one honest exception.

The principle: the field decides what ships

Phaze’s whole runtime story is zero shipped bytes for what you don’t use — the FlatBuffer accessor inlines to native DataView, the DSL helpers strip to nothing. Crypto follows the same discipline: no crypto field → nothing ships; a field → exactly the verifier/decryptor that field needs, only where it’s used.

For the algorithms a browser already has, that cost is zero:

• Ed25519, ES256 (P-256), AES-GCM are Web Crypto native → the client verify/decrypt is an inline subtle.verify / subtle.decrypt, no shipped library.
• The compiler knows the algorithm at build time (from the field), so it emits the native-inline path for these and never ships a generic crypto runtime.

The exception: crypto is not free, and PQC is least free

This is the one place the zero-ship rule bends, and it’s worth holding plainly:

Post-quantum verify/decrypt ships WASM

ML-KEM / ML-DSA are not in the browser’s SubtleCrypto. A lattice verify can’t be compile-inlined the way a vtable read can — if the browser must do a post-quantum verify or decrypt, it ships a WASM crypto module. The field still gates it (only those actions, only when the browser is the operating party), but the number isn’t zero.

The architecture is built so the browser rarely needs that:

• Browser edge = native algorithms (Ed25519 / ES256 / AES-GCM) → 0 WASM.
• Heavy + post-quantum crypto runs server-side — on the Rust runtime (native, fast) and at rest, where the threat actually lives (harvest-now-decrypt-later on long-lived data in storage or over an untrusted relay).
• Even a hybrid signature (ed25519+ml-dsa) lets the browser check the classical half (native) for its live integrity check while the post-quantum half is the long-lived/at-rest assurance verified server-side — so the browser ships 0 WASM even for a hybrid-signed response.

Where each piece runs

Concern	Browser	Worker / Rust runtime
Response signing (sign:)	verify (native, inline)	sign (the PHAZE_SIGN_KEY secret)
Response encryption (encrypt:)	decrypt (native AES-GCM; WASM only for PQC)	encrypt
Passkeys / WebAuthn	navigator.credentials ceremony (no crypto module)	ECDSA-P256 + CBOR/COSE verify (Rust, native)
At-rest / relay PQC	—	encrypt + sign (Rust; dcrypt — ML-KEM-768 built via phaze::crypto::ml_kem; rage at-rest blob format under eval)

In this section

• Hardened Transport — Phaze Transport contrasted against Next.js Server Actions / RSC: why a typed, schema-validated, signed wire behind a non-bypassable per-route gate closes whole risk classes (CVE-2025-55182 deserialization RCE, CVE-2025-29927 middleware bypass) by construction.
• Phaze is secure by design — the catalogue of React’s structural attack surface (RSC deserialization RCE/DoS, source-code exposure, middleware-auth bypass) and how Phaze’s isomorphism removes the server/client boundary those attacks live on.
• Signing & verification — the sign: / verify: fields, Ed25519/ES256, the detached X-Phaze-Sig header, key management, and the compile-time per-algo dispatch.
• Passkeys (WebAuthn) — the ECDSA-P256 floor (phaze::crypto::p256), the four endpoints, and the assertion-verify checks.
• Post-quantum & at-rest — the PQC roadmap, hybrid, and the harvest-now-decrypt-later threat model.

Cross-runtime by design

The same field model describes a TS Phaze action and a Rust handler, and the client verifies both identically. Signatures use phaze-crypto’s Ed25519/P-256 on the Rust side and Web Crypto on the browser side — one wire format (X-Phaze-Sig, raw hex keys), two runtimes.