Crypto specification
This guide documents the product crypto boundary Shhhs exposes publicly: supported secret content is encrypted before upload, key material stays out of server-readable URLs, and operational systems work with ciphertext plus metadata.
01
Secret creation flows encrypt in the browser, CLI, or local MCP adapter before upload. The Worker stores ciphertext, IVs, lifecycle metadata, and access-state metadata, not plaintext secret content.
02
Private key material belongs in the URL fragment or local client state, not in query strings, paths, analytics, logs, social previews, or server-readable storage.
03
Encrypted handoffs use payload envelopes that include algorithm/version metadata, ciphertext, IV/nonce material, and safe lifecycle data needed to enforce TTL, views, burn, and owner-only reveal.
04
Request flows separate the owner link, recipient submission, gate validation, and owner-only reveal. The recipient submits encrypted content; the owner reveals from the console.
05
Private Rooms store encrypted messages and participant metadata. Invite rooms keep room key material in the browser fragment; direct token rooms wrap room access for known account tokens.
06
This page is not an external audit, formal proof, certification, or promise that every future integration has identical properties. Changes to cryptographic algorithms require governance, tests, migration notes, and review.
No. Public guides never include secret identifiers, room ids, full private URLs, fragments, filenames, or payload-derived text.
No. It is product documentation for deployed boundaries. External audits, DPAs, SLAs, and certifications require separate evidence and review.
No. Shhhs support can help with billing and metadata-only support, but cannot decrypt or recover secret content.