How it works
Two products run on the same crypto core. Seal embeds two independent signatures over the same digest inside a single PAdES CMS structure: ECDSA P-256 (recognized by every PDF reader today) and ML-DSA-65 (FIPS 204, the post-quantum scheme NIST standardized in August 2024). An RFC 3161 timestamp from a qualified TSA wraps both. Vault uses the same hybrid philosophy for confidentiality: AES-256-GCM encrypts the document, and the data key is wrapped per recipient with a hybrid X25519 + ML-KEM-768 KEM (FIPS 203). Both products share one audit trail and one public verifier surface.
How it works
Two products, one workspace. Seal for court-defensible signatures (anyone can verify). Vault for encrypted documents that only the people you name can read. We retain hashes and audit metadata, never the original bytes.
Programmatic API access (POST /v1/seal, /v1/vault) ships from the Pro plan upward. The portal is the default surface — no API key required to seal or verify.
Sign in
Drop your work email, click the link, and you land in your tenant's portal. First sign-in provisions a workspace on the Free plan. NextAuth + email-based one-time links — no shared credentials, no SMS, no SSO setup.
POST /api/auth/signin/nodemailer → magic link delivered GET /api/auth/callback/...?token=… ↳ creates user + tenant + role ↳ session JWT (HS256) ↳ redirect /app/dashboardSeal · in your portal
Drag a PDF onto the dashboard. We embed a hybrid PAdES signature — ECDSA P-256 + ML-DSA-65 — and chain an RFC 3161 timestamp from a qualified TSA. You download the sealed PDF plus a Certificate of Sealing. We retain only hashes and audit metadata.
SignedAttributes { contentType, messageDigest, signingTime, signingCertificateV2}Signatures { ecdsa-p256-sha256 // classical ml-dsa-65 // FIPS 204}TSA: RFC 3161 token (qualified)Vault · share confidentially
Use Vault when the document content is sensitive. We encrypt with AES-256-GCM and wrap the data key per recipient using a hybrid X25519 + ML-KEM-768 KEM. Recipients prove identity with an email OTP and decrypt in-browser. Every open is logged.
DEK = AES-256 randomciphertext = AES-256-GCM(DEK, pdf) For each recipient: shared = X25519_DH(eph_sk, rcpt_pk) (kem_ct, kem_ss) = MLKEM768.Encaps(rcpt_pk) KEK = HKDF(shared || kem_ss) wrappedDEK = AES-256-KW(KEK, DEK)Verify · public, free
Send the sealed PDF to opposing counsel, an auditor, or a future judge. They drop it into our public verifier — we re-derive the digest, validate ECDSA + ML-DSA, and confirm the RFC 3161 timestamp. Free, on every plan, forever.
{ "valid": true, "ecdsa": "ok", "mlDsa": "ok", "tsa": "FreeTSA · 2026-04-28T03:50Z", "sealId": "01HX9F…", "tenantHash": "bc8a…3f"}Storage model
Seal: when you upload a PDF, we hold it in memory just long enough to compute its digest, embed the hybrid signature, and stream the sealed file back. The original bytes are dropped — we do not write them to disk, we do not push them to S3, and we do not retain a cached copy. The audit record is a row containing the hash, the two signature values, the RFC 3161 token, and the certificate chain. Tenant-scoped (PK TENANT#{id}, SK SEAL#{ulid}); cross-tenant queries are blocked at the repository layer.
Vault: encrypted envelope blobs do live in S3 (we have to keep them so recipients can decrypt later), but they are AES-256-GCM ciphertext encrypted under a per-document data key that we ourselves cannot recover without the recipient's authentication. Per-recipient wrapped keys live in Postgres next to the audit row. Recipient private keys are KMS-wrapped; Enterprise tenants can BYOK to their own KMS or HSM so we never see the unwrapping key.
The Certificate of Sealing PDF — a human-readable summary linked from the public verifier — is the only PDF we retain for the Seal product. It contains no part of your original document and can be deleted on request.
Verification
1. PDF integrity
Re-compute SHA-256 over the byte ranges referenced by the signature dictionary. Confirm it matches the message digest in SignedAttributes.
2. ECDSA signature
Verify with the public key from the embedded certificate chain. Walk the chain to a trusted root.
3. ML-DSA signature
Verify with the matching ML-DSA public key. The chain is co-located with the ECDSA chain inside the same CMS.
4. RFC 3161 timestamp
Verify the TSA token signature, confirm the imprint matches the signature value, and check the TSA cert chain.
5. Audit-log lookup
Cross-reference the hash and seal ID in our DynamoDB audit table. Confirms the seal was actually issued, not merely well-formed.
6. LTV proofs
Validate the embedded CRLs / OCSP responses so the document remains verifiable after the certificates expire.