Every design decision in Wormhole begins with the safety and privacy of your data in mind. We can't read your files, and no one else can either. Privacy isn’t an optional mode — it’s just the way that Wormhole works.
Your Wormhole files are end-to-end encrypted, and only you hold the keys to decrypt them. We can’t see your Wormhole files, so we can’t use them, share them, or sell them.
There are no ads and no creepy tracking in Wormhole. So focus on sharing the files that matter with the people who matter to you.
Your Wormhole files are end-to-end encrypted to keep them safe at rest and in transit. Our security starts with AES 128-bit encryption, and we use multiple techniques to make sure only you have access to your information. We're continuously working to make sure our code is rock solid.
Wormhole uses state-of-the-art security and end-to-end encryption to protect your files. Your files are always end-to-end encrypted, so they can never be shared or viewed by anyone but you and the intended recipients.
Wormhole encrypts all files with 128-bit AES-GCM encryption before they leave the browser.
The secret key used for end-to-end encryption is never shared with our servers. It is sent directly to your intended recipient when you send them the "share link". The secret key is added to the URI fragment which is never sent to the server.
When an agent (such as a web browser) requests a web resource from a web server, the agent sends the URI to the server, but does not send the fragment.
The link format looks like this:
Here's an example link:
For streaming encryption and decryption, we use Encrypted Content-Encoding for HTTP.
This standard provides authenticated encryption to ensure that your files can't be seen or modified by an attacker once they leave your browser.
We use the browser's built in cryptography primitives via the Web Crypto API to encrypt files in the browser before they are sent to the recipient.
End-to-end encrypted files may be:
A fully peer-to-peer transfer is preferred, since it improves speed and privacy. The server copy helps to ensure files continue to be available even after the sender closes their browser. All files are end-to-end encrypted before they are uploaded or sent peer-to-peer.
In addition to Wormhole's end-to-end encryption, your files are protected by an additional layer of encryption on our servers.
TLS (formerly known as SSL) is the industry-standard encryption protocol used to encrypt communications between your browser and our servers. It ensures that the Wormhole webpage code is not modified by attackers, and provides an additional layer of protection on top of the client-side end-to-end encryption to ensure data uploads and downloads are private.
We support TLS 1.3 for modern devices and TLS 1.2 for all remaining devices. Deprecated versions of TLS and SSL are not used.
Qualys SSL Labs rates our TLS implementation an A+. See report.
We monitor the Certificate Transparency logs for certificate misissuance.
A Certification Authority Authorization (CAA) policy allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain.
By publishing a CAA record, we reduce the risk of unintended or malicious certificate misissuance.
DNSSEC is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity.
We deploy DNSSEC to protect DNS records for
DTLS is the standard encrypton protocol used to encrypt WebRTC peer-to-peer communications between browsers. It provides an additional layer of protection on top of our own encryption to keep peer-to-peer transfers on Wormhole private.
Wormhole is configured with state-of-the-art security options to lock down the site as much as possible.
Mozilla Observatory rates our site configuration an A+.
Here are a few of the security features we deploy.
Wormhole uses this header to ensure that your browser always communicates with our servers using the TLS protocol.
We additionally include
wormhole.app in all major browser's HTTP Strict Transport Security (HSTS) preload lists. In the case of
.app domains, the entire TLD is automatically included in the HSTS preload list.
Wormhole uses this header to prevent other origins from accessing data on
wormhole.app. This is a mitigation for side-channel hardware vulnerabilities such as Meltdown and Spectre.
Wormhole uses this header to enable cross-origin isolation. Cross-origin isolation ensures that supported browsers always load Wormhole in a separate renderer process, which protects against side-channel hardware vulnerabilities such as Meltdown and Spectre.
Wormhole uses this header to disable some web browser features that we don't need, like camera and microphone access.
Wormhole uses Content Security Policy to prevent the site from being tricked into accessing resources (such as scripts, webpages, etc.) that could be used in Cross Site Sripting attacks.
eval() function, browser plug-ins, active and passive HTTP content, clickjacking attacks,
<base> tag attacks,
<form> submissions to exfiltrate data, and more.
Here's a high-level design document for Wormhole.
The client generates a main secret key and a salt using the Web Crypto API
The client uses the main secret key and salt to derive more keys via HKDF SHA-256
The client asks the server to create a "room"
roomIdand a "writer authorization token" (which will authenticate all modifications to this room)
roomIdand the "writer authorization token"
The client displays the "Share URL" as:
mainSecretKey is base64url encoded.
The client encrypts each file separately using the derived file key and the per-file salt.
The client creates a .torrent file using the encrypted files as the contents
The client encrypts the .torrent file using the derived metadata key and a random IV
The client uploads the salt, the encrypted files, the encrypted .torrent file, the reader authorization token, and the torrent info hash to the server
The client asks the server for a Backblaze upload URL
The client uploads the encrypted files to Backblaze where they are stored at rest with an additional layer of at-rest encryption
The client reads the
roomId and the main secret key from the URL, which follows the pattern
The client asks server for the salt that corresponds to
The client uses the main secret key and salt to derive the following keys (the same ones that the uploader derived):
The client asks the server for the encrypted .torrent file
The client decrypts the .torrent file using the derived metadata key and the IV (which is embedded in the ciphertext)
The client asks the server for a Backblaze download URL for
The client asks server for WebRTC offers (to connect to WebTorrent peers) for the given torrent info hash
The client downloads files from Backblaze and WebRTC peers simultaneously, coordinated by WebTorrent library
WebTorrent hashes all received torrent pieces and compares them to the expected hashes, which are present in the .torrent file
Data which has been validated by WebTorrent is decrypted using the derived file key and per-file salts (which are embedded in the ciphertext)
wormhole-crypto- Streaming encryption implementation, based on Encrypted Content-Encoding for HTTP (RFC 8188)
If you've found a security vulnerability in Wormhole, please report it using our Responsible Disclosure Process.