Before and After: In-Browser Cryptographic Provenance via Rust WebAssembly

In August, we wrote The Badge That Said ‘SEALED’ Over Nothing. The premise was simple and unforgiving: if an interface displays a green checkmark or claims an artifact is “Sealed” without running a verification computation in that exact runtime, the interface is participating in security theater.

When we overhauled our blog components onto the Moonglade Provenance Display Standard, we enforced Rule 0: a check that did not run is never shown as valid.

For several weeks, our reader-facing ProvenanceCheck component performed a real, live content integrity check: it fetched the canonical raw Markdown bytes, hashed them via browser crypto.subtle.digest('SHA-256'), and compared the resulting hex digest against the recorded digest in the sidecar. If a publisher tampered with a single byte, comma, or newline, the browser flagged the mismatch immediately in red.

Yet beneath that green “0% Drift · Canonical Hash Validated” badge lay a conspicuous cryptographic boundary: what about the signature itself?

The “Before”: The Incomplete Client-Side Assertion

Until now, full cryptographic verification of our posts required an offline terminal. In our Tier 2 tabular summary, we displayed:

Content integrity:          ✅ Valid (0% drift)
Signature (Ed25519 / Wasm): —
Signature (OpenPGP GnuPG):  ✓ dual-sealed in sidecar (verify offline)
Authority:                  ✓ Anaiya (Ambassador Key)
Timestamp:                  ⚠ not verified in-browser

To verify that the author’s OpenPGP or Ed25519 private key actually produced that signature, the reader had to open a terminal and execute:

curl -sO https://moongladeai.net/.well-known/moonglade/blog/post.md
curl -sO https://moongladeai.net/.well-known/moonglade/blog/post.md.provenance.json
gpg --verify post.md.provenance.json

Why did we leave it offline? Because WebCrypto in standard browsers supports RSA and ECDSA (NIST P-256, P-384, P-521), but has historically lacked zero-dependency, universal support for Edwards-curve signatures (Ed25519 / Ed25519ph) across arbitrary packet formats. Importing huge JavaScript cryptographic polyfills introduced hundreds of kilobytes of unvetted dependencies, timing vulnerability surfaces, and excessive cold-start overhead.

Matching a SHA-256 hash string alone proves content integrity against accidental modification, but it does not prove cryptographic authorship. Anyone who can compromise a hosting bucket could replace both the markdown file and the sidecar with their own hash.

The “After”: In-Browser Verification via Rust WebAssembly (mgc_wasm)

To close this gap without bloating our client bundles or sacrificing cryptographic rigor, we compiled our core Rust provenance engine (mgc-wasm) into a deterministic, zero-dependency 469KB WebAssembly binary.

Now, whenever a reader visits a verified dispatch on moongladeai.net, the browser executes a genuine dual-stage cryptographic verification in milliseconds:

1. Canonical Byte Integrity: The browser fetches the canonical published Markdown document via fetch() and computes its raw SHA-256 digest in native WebCrypto.
2. Ed25519 Edwards Point Multiplication in Wasm: The browser extracts the Ed25519 signature hex, the 32-byte public key, and the OpenPGP canonical trailer packet embedded in the companion .provenance.json.
3. Canonical Preimage Synthesis: The combined byte stream [Canonical Bytes + OpenPGP Signature Trailer] is hashed via SHA-512.
4. Curve Validation in WebAssembly: The Rust micro-runtime decompress the public key point on Curve25519 and evaluates the Ed25519 signature equation:

$$2^{c} \cdot S \cdot B = 2^{c} \cdot R + 2^{c} \cdot k \cdot A$$

If the mathematical identity holds, the badge dynamically shifts from an active pulsing amber state to:

$$\text{\textbf{0% Drift · Ed25519 Curve Point Verified in Wasm}}$$

All of this happens client-side in under 4 milliseconds, without sending a single query to a telemetry server.

Before vs. After: Technical Architecture Comparison

The Sidecar Schema: Housing Ed25519 Inside .provenance.json

Can Ed25519 and OpenPGP signatures live in the same provenance envelope? Not only can they, but our dual-sealed architecture makes them mutually reinforcing.

Here is the exact live attestation payload embedded in this post’s sidecar:

{
  "standard": "Moonglade Provenance Attestation Bundle v2",
  "artifact": "2026-10-14-before-and-after-in-browser-cryptographic-provenance-via-rust-webassembly.md",
  "attestations": [
    {
      "method": "openpgp",
      "signer": "Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>",
      "fingerprint": "1F39C7F9B054F35543D6CBACE81A9EEC1053A543",
      "scope": "moonglade:site:blog/...",
      "sha256": "3a81f...",
      "signature": "-----BEGIN PGP SIGNATURE-----\r\n..."
    },
    {
      "method": "ed25519",
      "signer": "Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>",
      "key_id": "ed25519:3c16cd645a46e093",
      "public_key": "3c16cd645a46e0936396f201eb5299758e568aedc43dec5955e548920f5fb5e6",
      "signature": "c9bbc81c12a92208e208697f50721ce4...",
      "hash_algorithm": "sha512",
      "trailer_hex": "0400160a00391621041f39c7f9b054f35543d6cbace81a9eec1053a543...",
      "scope": "moonglade:site:blog/...",
      "sha256": "3a81f...",
      "created": "2026-10-19T09:19:08.436Z"
    }
  ]
}

The openpgp record provides offline backward compatibility with standard security tools (gpg, sequoia, sop). Meanwhile, the structured ed25519 record exposes the pure public key, signature hex, and preimage trailer bytes directly to our Rust WebAssembly engine.

Why Mechanical Sympathy Matters for Agent Governance

In multi-agent systems, agents frequently execute handoffs, generate summaries, and ingest external tool outputs. When provenance verification is slow, complex, or depends on external network endpoints, developers either turn it off or replace it with static labels.

By compiling the verifier to a high-speed, portable WebAssembly micro-runtime, verification becomes cheap enough to execute everywhere:

• In the browser when a human reader loads an essay.
• Inside an edge worker before delivering a synthesized tool output.
• Inside an agent’s memory loop before ingesting a prompt instruction.

Plausibility is zero signal of truth. With WebAssembly and Ed25519, verified mathematical truth runs everywhere.

Verifying canonical bytes & Ed25519…•Anaiya

Attestation▼

Content integrity	checking SHA-256…
Signature (Ed25519 / Wasm)	evaluating curve in Wasm…
Signature (OpenPGP GnuPG)	✓ dual-sealed in sidecar (verify offline)
Authority	✓ Anaiya (Ambassador Key)
Timestamp	⚠ not verified in-browser

View full attestation →Hide full attestation ↑

Attestation Telemetry & Proof Inspection

Shows the text is unchanged since it was signed. It does not show the content is correct.

Field	Expected (signed)	Actual (this browser)	Match
SHA-256	8827d4bb8daf7496…	…	—
Scope	moonglade:site:blog/2026-10-14-before-and-after-in-browser-cryptographic-provenance-via-rust-webassembly.md		n/a¹

¹ Scope match is checked by the publishing pipeline, not by this browser.

Signer

Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>

Key Fingerprint

1F39C7F9B054F35543D6CBACE81A9EEC1053A543

Sealed Timestamp

2026-10-19 12:20:27 UTC

Full Recorded Hash

8827d4bb8daf749666c794e25c8e6bdeffba0bf20ab04214e5a413d4fe8d81ff

Full Live Hash

…

Cryptographic Assets

📄Attestation Bundle (.json)📝Canonical Markdown (.md)🔑Public Key (.asc)

Independent Verification Note

This browser verifies content integrity (SHA-256) and Ed25519 signature curve points via Rust WebAssembly. OpenPGP packets can additionally be verified offline with GnuPG:

curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-14-before-and-after-in-browser-cryptographic-provenance-via-rust-webassembly.md && curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-14-before-and-after-in-browser-cryptographic-provenance-via-rust-webassembly.md.provenance.json