Security

What is encrypted

Every file, every file name, every folder listing and the share's name. All of it is encrypted on your device with a key that is created there and stays there. Our servers, the storage behind them and the network in between only ever handle ciphertext.

The primitives: AES-256-GCM for content and metadata, X25519 with HKDF-SHA256 to wrap keys for a device or an account, random 256-bit keys per share.

Source code

The core every app is built on, the encryption, the backend client and the cloud and direct transfers, is published at github.com/ShareNinjaHQ/share.ninja under the Apache 2.0 license, together with the sninja command line and the terminal file manager. The primitives named above can be read there as code, and the command line can be built from it.

How a link carries its key

A share link looks like share.ninja/#…. Everything after the # is a claim token that browsers never send to a server; it stays in the address bar. The server stores only a hash of that token, plus the share key wrapped under a key derived from it. Whoever opens the link derives the wrapping key locally, unwraps the share key and decrypts. Without the link, nobody can open the share, us included.

Stop sharing, and the server refuses the link everywhere at once. Expiry works the same way.

Direct-only links

On web and desktop a link can be direct-only. Then nothing is uploaded: the files stay on the sender's machine and stream to the recipient live, over WebRTC. The transfer is encrypted twice: by WebRTC's own transport encryption and by our own AES-256-GCM layer keyed from the share key. If no direct network path exists, a relay forwards the packets; the relay sees ciphertext and nothing else. Close the sender, and there is nothing left to download.

Nearby

Devices find each other three ways: on the same local network, over Bluetooth (apps only), and through our server, which groups devices that sit behind the same internet connection. What a device announces is its name, a public key and an eight-character fingerprint of that key, and only while it is set to be visible. The switch is in the Nearby tab.

Sending nearby wraps the share key to the receiving device's public key. The server passes that sealed offer along but cannot open it. The receiver sees the sender's name and fingerprint and accepts or declines; the fingerprint shown on both screens lets you check that nobody sits in between. Your own signed-in devices accept automatically. The files then travel directly, or through a relay that sees only ciphertext.

Your account and your devices

Signing in creates an identity key on your first device. It never leaves your devices in the clear: each device holds a copy wrapped under its own device key, and the server stores only those wrapped copies and the public halves.

A new device asks to join. A device you already trust shows the request with the newcomer's name and fingerprint, and if you approve, wraps the identity key for it. We cannot add a device to your account, and we cannot read your shares to do it for you.

If you lose every device, the 24-word recovery phrase from Settings unwraps the identity key on a new one. Recovering revokes every previous device. If you have no recovery phrase and no device, the shares are gone; we hold no copy that could bring them back.

What our servers can see

The full list, nothing left out.

• For every share: its identifier, when it was created and when it expires, the total size of its encrypted data, whether it lives in the cloud or direct-only, and who owns it if the owner is signed in.
• For every download: that it happened, when, and from which IP address. This is what rate limits and abuse handling run on.
• For every signed-in account: email address, display name, the names and public keys of its devices, storage used.
• For every device, signed in or not: a device identifier, its public key, the name it announces to nearby devices.
• Server logs with IP addresses and request paths.

Server logs are kept for 30 days. Download records and your account's audit log keep the IP address for 90 days, then only the event remains.

What our servers cannot see: any file, any file name, any folder listing, any share name, any key.

Signed in, you can see this record yourself: the audit log in your account settings lists every action on your account, with time, IP address and device.

Storage and infrastructure

Our servers run at Hetzner in the EU. Encrypted data lives on our own storage servers there and on Wasabi S3, in several regions. Storage receives and returns ciphertext through short-lived signed URLs; it never holds a key.

Abuse

Every link's page has a Report abuse action that needs no account. Because we cannot open a share ourselves, the reporter decides whether to include the link's key with the report; only then can we look at what was reported. A confirmed report disables the link everywhere, and we can block the device that created it. The reporter's contact email is deleted once the report is handled.

The website

No tracking scripts, no analytics cookies, nothing sent to third parties. Visits are counted from our own server logs. The apps carry no analytics at all.

Reporting a vulnerability

Write to support@share.ninja and put “security” in the subject. We answer every report.