Security

Verify it. Don’t take our word.

Every security claim on this page names the mechanism behind it — no “military-grade” adjectives. Here is what protects your files, what the threat model covers, and, just as important, what it doesn’t.

TLS 1.3 + pinning

Fail-closed identity

Every connection is TLS 1.3, and the peer’s certificate fingerprint is pinned before a single byte of the file moves — compared in constant time. No match, no connection. There is no silent fallback.

6-digit SAS

A code you compare out of band

Both sides derive the same six digits from the TLS session itself and compare them over a channel our servers never touch — voice, chat, in person. Matching digits prove nobody sits in the middle, even if the signaling server is compromised.

BLAKE3

Every chunk, then the whole file

Each chunk is hash-verified as it lands, and the complete file is verified once more at the end. Corruption or tampering fails the check — what arrives is exactly what was sent.

MAC journal

Resume you can’t forge

Interrupted transfers restart from a MAC-protected journal. A tampered or replayed journal fails authentication, and the transfer starts clean instead of trusting forged state.

Threat model

The threat model, in plain words

What we defend against

A man in the middle — including our own signaling server. Matchmaking needs a server, so we designed for the day that server is malicious. The 6-digit SAS is derived from the TLS session and compared out of band: if anyone — including a compromised signaling server — sits between you, the digits diverge and you hang up. Certificate pinning is fail-closed on top of that.
Tampering in transit. BLAKE3 hashes verify every chunk and then the whole file. A flipped bit anywhere fails the transfer rather than passing silently.
Forged resume state. The resume journal is MAC-protected. An attacker who can touch the disk between sessions cannot splice their own bytes into a resumed transfer.
Path traversal on receive. Destination paths are sanitized — a malicious sender cannot name files so they escape your download folder and land in ..\..\Windows.
Guessed codes. Room codes carry at least 130 bits of CSPRNG entropy — twelve BIP39 words or a base32 string. Brute-forcing a live code is not a practical attack.

What we do not defend against

A compromised endpoint. If your machine or operating system is compromised, no transfer tool can protect a file before it leaves or after it arrives. Blixt secures the path between two machines, not the machines themselves.
A malicious receiver. The SAS authenticates the channel, not intentions. Once a file is delivered, the receiver can copy it or leak it — send to people you trust.
Matchmaking metadata. To connect two peers, the signaling server necessarily sees connection metadata: peer IP addresses and room lifetimes. It never sees your files. The relay, when used, sees only ciphertext.

Data

Where your data lives

Direct transfers

Nowhere in between. The file moves from your machine to theirs over an encrypted connection. There is no server copy — nothing to breach, nothing to remember to delete.

Relay fallback

When no direct path exists, an end-to-end encrypted stream passes through our relay. The relay forwards ciphertext and stores nothing — it cannot read your data and it does not keep it.

bCloud

The one place we do store files — because you asked us to. They live on our storage under your quota until you delete them. Share links are optional and can carry a password, an expiry, and a download limit.

What we don’t have yet: SOC 2 or ISO 27001. Our privacy is architectural — for direct transfers there is simply no server holding your files. Certifications are a roadmap item, not a promise, and we will list them here when they are real — not before.

Self-host

Run the whole thing inside your perimeter.

If policy says nothing leaves your network, nothing has to. One flag embeds the signaling hub into blixtd, so matchmaking and metadata stay on infrastructure you control. And on the same LAN, Blixt works with no server at all — fully offline.

$ blixtd --embed-signal --signal-addr :8080
signaling hub + web UI on your own box
peers point --signal at your hub — not ours

$blixt send --lan --code "$CODE" dataset.tar
offline · same network · no server involved

Responsible disclosure

Found a vulnerability? Tell us.

Report it to security@blixt.pro. A human reads every report, and we respond fast. Please give us a reasonable window to ship a fix before publishing details.

There is no bug bounty program yet — we won’t pretend otherwise. What we offer today is a quick, direct answer and a fix. The machine-readable contact lives at /.well-known/security.txt.