How Hush protects you — and where the limits are.

We’d rather tell you exactly what Hush does than make big claims. This page covers what’s encrypted, what we can still see, the threats we design against, and what isn’t done yet. The technical version is in SECURITY.md in our source repository.

Status, honestly

• No independent security audit has been done yet. One is planned before Hush leaves beta.
• Hush uses only standard, widely reviewed primitives: the platform’s built-in crypto (WebCrypto / Apple CryptoKit) and libsodium. We don’t invent cryptographic primitives. The way they’re combined for Messages follows the published X3DH and Double Ratchet specifications, but it’s our own implementation and hasn’t been reviewed by anyone outside the team.
• Rooms and Pages use client-side encryption, not the Signal Protocol. They don’t have forward secrecy: anyone who gets a room link, including from an old message or screenshot, can read that room until it expires.
• Messages use Double Ratchet–based end-to-end encryption using libsodium. This is not the Signal Protocol and doesn’t use libsignal.

What is encrypted

What we (and our host) can still see

• That a room or page exists, its random ID, creation time, expiry time, and size.
• When messages are posted to a room and how big they are (not who wrote them or what they say).
• IP addresses and user agents of requests, processed by our host and briefly in memory for rate limiting.
• How many recipient slots a page has (not who they are).
• For a Hush: its unlock time, how many people must agree and which anonymous slots have said yes, whether it uses a code, and its expiry. We have to know these to enforce them.
• For Convergence: how many devices are connected and when they check in.
• Handles you check for availability (sent to Hylaq’s registry).
• For Messages: which @handle sends to which, when, and how big each message and encrypted file is, and which signed-in account downloads a file; how many one-time prekeys you have left; your public keys. We don’t see message text, group names, or who else is in a group, but group messages are sent once per person, so the pattern can be inferred.

We keep this to a minimum and delete room and page data when it expires. Expiry is checked on every request, swept hourly, and backed by a storage-level time-to-live.

How Rooms work

• Your device generates a random 256-bit room key. The invite link is hylaqhush.com/r/<id>#k=<key>. Browsers never send the part after # to a server.
• Every message is sealed with AES-256-GCM and a fresh random nonce, bound to the room ID, before it leaves your device.
• Rooms expire after 1 hour, 1 day, or 1 week. After that the server refuses reads and writes and deletes every message. The creator can close a room early.
• Anyone holding the link can join. Treat it like a key.

How Pages work

• Page content is sealed with a random content key. Each person you share with gets a separate link secret, and the content key is wrapped separately for each one. The server returns only the wrapped key for the link being opened.
• Revoking someone rotates the key. Your device re-encrypts the page with a new content key and re-wraps it only for the people who still have access. The revoked person’s link stops working, and their old wrapped key opens nothing.
• You can set a page to expire. When it does, the ciphertext is deleted.
• Only the creator’s device holds the owner token needed to edit, revoke, or delete. The server stores just a hash of it.

How Hushes work

• Your phone encrypts everything before upload. Each person gets their own link with their own key, so a link only opens the Hush it was made for.
• Time and agreement are enforced by our server. Until the unlock time passes and enough people say yes, the server won’t release the encrypted contents or anyone’s key to them.
• A “no” is never sent. Declining stays on your device. Progress is only shown to people who already said yes, and only if the creator turned it on.
• Secret codes never leave a device. The contents are sealed again under a key derived from the code, so even with the server’s cooperation the code is needed.
• What you type into Create is turned into a draft on your phone. It isn’t sent to us or to any AI service.
• When a Hush expires or its creator erases it, the server deletes it. A “kept” copy stays only on the device of the person who kept it.

How Convergence works

• The join code is turned into a session ID and an encryption key on each phone. Each phone sends its own encrypted state; we can’t read roles, names, or moves.
• Codes are short so people can say them out loud. Treat one like a meeting code, not a password. Guessing is rate-limited and sessions end after 24 hours.
• Hiding parts of the game from some roles is part of the experience, not a security guarantee: every participant’s phone holds the session key.

How Messages work

• When you sign in with Hylaq, your phone generates an Ed25519 identity key, a signed prekey, and a batch of one-time prekeys. Only the public halves are uploaded, under your @handle. The server checks the prekey signature and that you own the handle.
• To start a chat, your phone fetches the other person’s public keys, verifies the signature, and runs an X3DH-style key agreement (X25519, HKDF-SHA-256). Each one-time prekey is used at most once; the recipient’s phone deletes it after use.
• Every message then goes through a Double Ratchet: a new key for every message, a fresh Diffie-Hellman step whenever the conversation turns around, sealed with XChaCha20-Poly1305. That gives forward secrecy and recovery after a compromise. Out-of-order messages work; replays and tampering are rejected.
• Our server stores each encrypted envelope until the recipient’s phone fetches it, then deletes it. Undelivered envelopes expire after 30 days, or sooner for disappearing messages.
• Safety numbers. Each chat has a 60-digit number and QR code built from both identity keys. If it matches on both phones, nobody is in the middle. If someone’s key changes, Hush warns you in the chat.
• Disappearing messages are deleted from each phone when the timer runs out. Anyone in the chat can still screenshot or copy them.
• Photos, videos, files, and voice notes are encrypted on your phone with a new random key for each file (libsodium secretstream: XChaCha20-Poly1305 in 64 KB chunks, so a cut-off or altered file is rejected). We store only the ciphertext. The key travels inside the end-to-end encrypted message. Files can be up to 25 MB. Encrypted files are deleted from our storage after 30 days, or sooner with a disappearing timer. Anyone signed in who learns a file’s random ID could download its ciphertext, but can’t decrypt it without the key.
• Photos are resized to 2048 px and re-encoded on your phone, which also removes metadata such as location. Videos and other files are sent unchanged, including any metadata inside them.
• View once: after the person opens it, the key is deleted from their phone and the sender keeps no viewable copy. It can still be screenshotted or recorded with another device.
• Reactions, replies, edits, and “delete for everyone” are themselves end-to-end encrypted messages. Only the author can edit or delete a message; a deletion can’t undo that someone already saw or saved it.
• Profile pictures you set in Hush stay on your phone and are sent end-to-end encrypted to people you message (you can turn this off). If you haven’t set one, Hush shows the public picture from your Hylaq profile, which anyone can already see on hylaq.com.
• Search runs only on your phone.
• Groups (up to 16) send each message separately to every member over their own encrypted session.
• Ghost Mode is on by default: no read receipts, and no message previews in your list. Hush has no online or typing status to hide.
• Not done yet: sealed sender (hiding who sent a message from us), header encryption, more than one device per account, post-quantum key agreement for messages (calls have it, see below), push notifications, typing indicators, and link previews.
• In the iPhone app your keys are encrypted with a key held in the iOS Keychain (this device only) and never leave the phone; the Secure Enclave isn’t used because it doesn’t support these key types. In a web browser they’re kept in the browser’s local storage, which is weaker: any code running on the page or anyone with access to that browser profile can read them.

Calls

• 1:1 voice and video calls between @handles, in the app and on the web. Media goes directly between the two devices with WebRTC, which always encrypts it (DTLS-SRTP).
• Signaling is end-to-end encrypted. The call offer and answer (including each side’s DTLS certificate fingerprint) are sent as messages inside your Double Ratchet chat, and each side signs them with its identity key. Our server only relays ciphertext, so it can’t swap in its own certificate and sit in the middle.
• Post-quantum keys for every call. Each call runs a fresh hybrid key exchange: X25519 and ML-KEM-768 (the NIST FIPS 203 standard, via the audited @noble/post-quantum library). The call key is derived from both with HKDF-SHA-256, so an attacker would have to break both. Messages still use X25519 only.
• An extra layer on every frame. Where the browser supports WebRTC encoded transforms (current Chrome, Edge, Safari 15.4+, Firefox 117+), each audio and video frame is also encrypted with AES-256-GCM using those call keys, separately per direction and media type. Keys ratchet forward about every 20–40 seconds and old keys are deleted. If either side can’t do this, the call still works with DTLS-SRTP alone, and the call screen says so (“DTLS-SRTP” instead of “Post-quantum · ML-KEM + AES-256”). DTLS-SRTP’s own key exchange is not post-quantum.
• Safety code. The call screen shows five emoji derived from the call key and the whole signed handshake. Read them to each other: if they match, nobody is in the middle.
• What we can see: that a call happened between two @handles, when, and roughly how long the setup took (from the encrypted envelopes). If a relay (TURN) server is used for a strict network, it sees the two IP addresses and encrypted packets. The two devices see each other’s IP addresses, as with any direct call.
• Not done yet: group calls, ringing when the app is closed (iPhone CallKit / VoIP push), and an independent audit. Calls only ring while Hush is open.

Spam Shield

• Hush downloads a public list built from FTC Do Not Call complaint reports. Numbers with repeated reports are blocked, and the rest are labeled. A report isn’t proof, so a legitimate number can occasionally appear.
• The iOS extensions don’t send numbers or message text to any server. iOS only gives the text filter messages from unknown senders.
• We never upload your contacts.

On your device

• App lock with Face ID / Touch ID.
• The app view is blurred in the app switcher.
• Keys and owner tokens are stored in the iOS Keychain (this device only) in the app.
• Ghost Mode: no read receipts and no message previews unless you turn them on. Hush has no online status signal at all.

The website

• No analytics, trackers, ad SDKs, or third-party scripts.
• Strict per-request nonce Content-Security-Policy, HSTS with preload, no-referrer, and framing blocked.
• Rate limits on every write endpoint. No secrets ship to the client.

Threat model (summary)

Designed to protect against

• A curious or compromised server, or a database leak: it only yields ciphertext and the metadata listed above.
• Network attackers: everything goes over TLS with HSTS, and content is sealed again on top of that.
• Revoked page recipients reading later updates.
• Spam lists learning who calls or texts you.

Not protected against (today)

• Someone who gets an invite or page link, or a member who screenshots or forwards content.
• A compromised or unlocked phone.
• Traffic analysis and metadata such as timing, sizes, and IP addresses.
• Past room messages after a key leak. Rooms have no forward secrecy; Messages do.
• A malicious or compromised server serving modified code. Today the iPhone and Android apps load their interface from hylaqhush.com too, so this applies to them as well. Bundling the app code, including all crypto, into the app is planned.
• Metadata on Messages: who talks to whom and when (no sealed sender yet).

Report a vulnerability

Email security@hylaqhush.com. We welcome good-faith research and won’t pursue legal action against it.