The floor first. Writers opt in at sign-up; the recording layer captures plain-text events inside the editor — keystrokes, paste actions, cursor moves. No microphone, no camera, no screenshots, no screen recording, no clipboard from other apps, no keystrokes outside the editor.
Every finalized recording is encrypted, signed, and anchored to a public transparency log. A verifier confirms the chain without trusting our infrastructure.
Every finalized writing session becomes an envelope assembled from four independent layers. Each layer adds one property. The stack is called Encrypted Authorship Verification — EAV — and it's specified in the open at /EAV_SPEC.md.
/.well-known/jwks.json.Layers upgrade independently. The cipher could move to ChaCha20-Poly1305 without re-signing. The signing scheme could move to a post-quantum algorithm without re-encrypting anything. The KEK derivation could move to a third-party escrow without touching the events ciphertext. The envelope's schema field coordinates the version.
The writer's KEK is derived deterministically from two inputs: their authenticated identity (a Clerk-issued user ID, verified per request) and a 32-byte server-held HKDF salt. The derivation runs in the request handler, the wrapped DEK is unwrapped in memory, and the KEK is discarded. A KEK is never written to a database or a log.
The Clerk identity alone is insufficient (lacks the salt). The salt alone is insufficient (lacks the identity). Both are required to derive a KEK, and the KEK only exists for the lifetime of one request.
Every finalized recording gets its own 256-bit DEK from a cryptographically secure random source. Once the events are encrypted and the DEK is wrapped, the raw DEK is discarded. There is no master DEK and no shared key across recordings.
The ES256 signing key is held server-side and rotated on cadence (planned: annually). Every envelope's signature.kid identifies the key version used to sign it. The JWKS endpoint serves all currently-valid public keys, so signatures issued under an older key still verify after rotation.
When a teacher needs access to a student's recording, the producer derives that teacher's KEK and adds a second wrapping of the same DEK to the envelope's grants[] list. Granting access does not re-sign the envelope and does not touch the events ciphertext — the canonical hash deliberately excludes the keyEnvelope field for exactly this reason. Revoking access removes the grant from future verifications; it cannot retroactively un-decrypt what a grantee has already decrypted (the standard limitation of any envelope-encryption system).
The signature in Layer 3 proves Red Stet attests to the envelope. It does not prove when. A producer that's compromised — or coerced — could backdate a recording. The anchor is what closes that gap.
Rekor is a public, append-only transparency log governed by the OpenSSF — the same Linux Foundation project Google, Red Hat, GitHub, and others contribute to. It's the de facto signing log for open-source software supply chains; the Cosign / Sigstore ecosystem has used it in production since 2021.
Red Stet submits the SHA-256 of each signed envelope as a hashedrekord entry. Rekor appends it to its Merkle tree and returns a log index, a UUID, an inclusion proof, a signed checkpoint, and an integrated timestamp. All of that is persisted on the recording row.
A verifier with the Rekor public key — pinned for offline use, or fetched fresh — can confirm the inclusion proof against the checkpoint root, confirm the checkpoint's signature, and read the integrated timestamp. The verifier never has to call Red Stet. A district auditor doing an offline review six years from now sees the same proof a live API call would return today.
The anchor runs asynchronously. The user's finalize call returns once the envelope is signed and persisted; the Rekor round trip (typically 1–3 seconds) happens out of band. An hourly retry catches transient Rekor outages. Anchor failure does not invalidate the envelope — the signature is still the producer's attestation — but anchor presence is surfaced to the verifier separately so a reviewer can tell which envelopes have third-party corroboration.
Which data Red Stet's operators can read:
The DEK never persists. The KEK never persists. The wrapped form is what's stored, and unwrapping requires a verified writer session. Storage on its own — a snapshot, a backup tape, a compromised database — yields ciphertext.
The limit: this protects past recordings against storage compromise. It does not protect a live, signed-in writing session from a server attacker present at the moment of recording. That's a different threat, addressed by the broader infrastructure hardening (CSP, audit logging, role separation, signing-key isolation) rather than by EAV itself.
Recordings created before EAV rolled out — April through June 2026 — were migrated to the EAV path during that window. From the migration forward, only the wrapped form exists.
A full read of the recording database and File Storage yields envelopes — ciphertext, wrapped DEKs, signatures, anchor proofs. No KEKs are stored. No raw DEKs are stored. Decryption requires the per-request KEK derivation, which requires a verified Clerk session for each affected writer plus the server salt. Past recordings remain unreadable to the attacker.
An attacker who obtains the current ES256 signing key can forge new envelopes. Mitigations: signing keys are versioned, rotatable, and isolated from the application database. Rotation deprecates the compromised key (envelopes already signed under it remain verifiable; new envelopes are signed under the new key). The transparency anchor remains independent: forged envelopes that were never submitted to Rekor have no inclusion proof, which a verifier surfaces as a missing anchor.
If RED_STET_KEK_SALT leaks, all KEKs become derivable by anyone who also obtains the corresponding Clerk identities. Mitigations: HSM-stored salt is the planned hardening path; threshold-cryptography upgrade is the v2 spec target. Both are tracked in the EAV spec's §14 (Open questions for v2).
Sigstore Rekor's transparency log is operated by a third party, witnessed by additional third parties, and append-only by construction. A Red Stet server compromise does not let an attacker rewrite Rekor history. An envelope's claimed timestamp is corroborated by Rekor's integrated time, which an attacker cannot backdate.
Security issues go to [email protected]. We commit to a response within five business days. No bug bounty yet; credible reports get acknowledged and fixed before they're published.
The point of cryptographic verification is that the reviewer doesn't have to trust us. The point of a transparency log is that the reviewer doesn't have to trust Sigstore either — the proof is independently checkable. — The posture
The protocol spec is the authoritative document for the wire format, canonicalization rules, verification flow, threat model, and upgrade semantics. It covers envelope schema (§4), signature scheme (§5), encryption scheme (§6), the anchor (§7), and the conformance requirements that make a tool EAV-compliant (§11).
The spec lives at /EAV_SPEC.md — the same document that's checked into the repo. No request form, no email gate. The verifier source — verify/index.html — runs entirely client-side; view source on any deployment to read the verification logic alongside the spec.
Pairs with privacy (what's stored, how long, who can delete what) and FERPA posture (which subset of data falls under school authority and which stays with the writer).
Security disclosure, procurement review, DPA, or a question this page didn't answer: [email protected]. Include your role and what you're reviewing for; the answer comes faster when the context is on the first line.