01
You seal it
You pick a file and who can open it. SVX locks it for those people and signs it so they know it's from you.
How it works · Security
What SVX does, and where it stops.
First in plain language, then in detail for security teams. Then the limits, because they matter as much as the features.
In plain language
Sending a file with SVX.
02
The key is in two halves
One half is kept by the SVX service, the other by the recipient's side. The file only opens when both agree.
03
They prove who they are
When the recipient tries to open it, SVX checks it's really them.
04
You say yes
Approval is on by default: nothing opens until you approve in your app. If you decline, it stays sealed.
05
You can change your mind
Revoke access and the file won't open for that person again. Anything they already opened, they've already seen.
06
No browser involved
Everything happens in the desktop app. This website is only here to explain SVX and offer the download.
For security teams
The technical picture.
A summary of the design. If something here matters to your evaluation, read the threat model below too.
ENCRYPTION
Post-quantum hybrid
Each file is encrypted with ChaCha20-Poly1305 in a streaming construction under a fresh random key. That key is wrapped with HPKE using a hybrid KEM, ML-KEM-1024 combined with P-384, with HKDF-SHA512. An attacker has to break both the post-quantum and the classical half, including with a future quantum computer.
INTEGRITY
Three signatures on every file
The sender signs every file with Ed25519, ML-DSA-87 and SLH-DSA-SHA2-256s, and all three must verify. Headers and contents are bound with SHA-512. A tampered, forged or misaddressed file is refused before anyone signs in.
KEY CUSTODY
A split key, two parties
The file key is split in two. One share is sealed to the SVX service, the other to the recipient's side: the person's own device for personal accounts, or their company's key agent for company accounts. Both must release their share, so neither the service nor a stolen copy of the file is enough.
That release is where verification, sender approval, one-time limits, expiry and revocation are enforced.
SIGN-IN
Bound to this open
Every open uses a fresh one-time key, bound to the recipient's company sign-in or to their device's signature, so a stolen or cached login can't be replayed to decrypt a file. Device keys live in the system keychain, and on Mac and Windows SVX asks for Touch ID or Windows Hello before using them.
TRUST
No typed keys, pinned registry
Senders never handle keys. They pick a person or an organisation, and SVX fetches the keys from records signed by a registry key that is pinned when the app is set up. Connections to the service use TLS with a post-quantum key exchange.
ENVIRONMENT
Desktop only
Files and keys never touch a browser. Sealing, verifying and opening happen in the SVX desktop app on macOS and Windows (Linux is coming). Opened files are written only after full verification, readable only by you. This website is static: no accounts, no uploads, no file handling.
FORMAT
A specified format
The .svx container has a written specification and deterministic test vectors, so it can be reviewed and checked independently of the app.
UPDATES
Verified with our own keys
Every update is signed offline with our own release key and checked by the app before it installs. Older versions are never offered. During the beta, the installers themselves aren't yet signed by Apple or Microsoft.
Threat model & limits
What it protects against. What it can't.
Designed to protect against
- Someone intercepting the file in transit or finding it later. Eve gets a sealed file she can't open.
- A forwarded copy reaching someone you didn't choose.
- A file being altered or forged. The signature check fails.
- One side acting alone. Neither the service's half nor the recipient's half opens the file by itself.
- Access continuing after you revoke it, after the file expires, or after a one-time open.
- A stolen or cached login being reused to open a file.
Limits you should know
- View-only blocks saving, copying and screenshots in the app. It cannot stop someone photographing their screen.
- Screenshot blocking is tested on macOS and Windows. On Linux, SVX will refuse to show view-only files.
- Revocation stops future access. It cannot take back a file someone already opened.
- A recipient you approve can read what you sent. If their device is compromised while the file is open, so is what's on screen.
- You have to trust the SVX service to enforce approval, one-time limits and revocation. It can't read your files on its own, but it decides when its half of the key is released.
- Malware on a recipient's computer, or a modified copy of the app, can ignore view-only rules.
- Beta builds aren't signed by Apple or Microsoft yet. Verify the checksum before you install.
Report a vulnerability
If you find a security problem in SVX, write to security@getsvx.me. Please tell us what you found and how to reproduce it, and give us a reasonable time to fix it before you publish. Don't test against other people's accounts or files, and don't send us anyone's private data. We'll acknowledge your report, keep you informed, and credit you if you want. This is a free beta run by one person, so there is no bug bounty. The same details are in our security.txt.