How Files and Messages are Encrypted

All files and messages you send through our platform are protected using end-to-end encryption. End-to-end encryption means that nobody other than you and the individuals you authorize can read them. There is no way for SendSafely, or any third party, to decrypt this information. Even if the data is intercepted, stolen or seized, it cannot be read without the proper decryption keys, which are never stored or accessible by our systems.

Every set of files or messages that you send through SendSafely are encrypted on your machine before being submitted to our servers. We use the OpenPGP message format, with a key that is derived using OpenPGP's Iterated and Salted (Type 3) String-to-key (S2K) specifier. The Type 3 S2K converts a variable length pass-phrase into a 256-bit symmetric AES encryption key. The pass phrase that is used consists of 512 random bits of data and is a combination of the following two values:

• A 256-bit random secret value that gets generated by our servers (referred to from here on as the Server Secret)
• A 256-bit random secret value that gets generated by your machine (referred to from here on as the Client Secret)

The Server Secret is stored by us, and provided to your recipients along with the file once we verify their identity. The Client Secret, however, is never disclosed to our servers and remains on your machine at all times. The Client Secret is sent directly by you to them within the Secure Link needed to access the items. When you want to share access with someone else, you (the sender) provide them each with a Secure Link that includes the Client Secret embedded within URL Fragment Identifier.




Because this value is embedded within the URL Fragment Identifier, it is never visible to our server (even when the link is clicked by the user). Instead, the value is used by our client-side API and combined with the Server Secret to recomputed the AES Key needed to decrypt the items.

Trusted Device Keys

Trusted device keys are a secondary encryption method we use to make it easy for you to access items. Any time you log in from a new browser, SendSafely will ask you if you want to trust the browser. If you choose YES, your browser generates a 2048-bit RSA Public/Private key pair. The private key is never submitted to SendSafely, it gets stored in your browser’s local storage. The public key gets uploaded and stored by SendSafely.


Once you have a trusted browser, the server will provide a copy your trusted browser public key to users that send you items. The public key is then used to encrypt a copy of the Client Secret for that item, and the encrypted Client Secret gets uploaded to SendSafely. This lets us provide you with access to all of your received items using a trusted browser, eliminating the need for the sender to share a secure link with you.

Local Storage Encryption

SendSafely’s security model relies on storing private key material within your browser’s HTML5 Local Storage. Your browser automatically protects this information by making sure that other websites are not allowed to access the information we store there. As an additional safeguard, SendSafely encrypts this information using a 128-bit AES key that is unique to your user account. The key is generated by us when you create your account, and stored on our servers. We only reveal this key to your browser while you are logged into our site. That way if someone else gains access to your local storage, the SendSafely information we store there cannot be viewed.

Two Step Login

Users have the option of enabling Two Step Login on all SendSafely accounts. When Two Step Login is enabled, we generate random 6 digit PIN ever time you log in from an unrecognized device and send it to your mobile phone. The PIN is required, in addition to your user-id and password, in order to log in from the new device. Enabling Two Step Login helps to prevent account takeover/hijacking if your user-id and password are compromised.

Web Application Security

In addition to the encryption mechanisms described above, all communications between the SendSafely servers and your web browser or mobile application are encrypted using HTTPS/TLS (Transport Layer Security). The use of HTTPS/TLS provides an additional layer of encryption on top of the end-to-end encryption already used for file and messages, and is used to safeguard client-server communications and mitigate man-in-the-middle attacks. The HTTP Strict Transport Security header is used across our site to prevent anyone from attempting to fool your browser into making requests to our site that to not use HTTPS/TLS. We also maintain an A+ rating from SSL Labs.

To protect users from cross-site scripting attacks (XSS), SendSafely’s web application uses the Content Security Policy standard to declare approved sources of content that are allowed to run within the web application. Only approved sources of client-side code are permitted, so unauthorized attempts to inject JavaScript script into our application will be blocked.

Privacy, Anonymity and Metadata

SendSafely protects the contents of the files and messages you exchange, however SendSafely is not designed to be an anonymous system. Our goal is to keep your data private while providing all of the core features you expect. Our servers have no knowledge of your message contents, but we do store things like your email address, phone number, contacts, and file names. SendSafely also stores additional data such as the time you logged-in, who you send items to, and the IP address you use to access the site. SendSafely will never disclose any of this information or share it with third parties, except when needed in order to fulfill our operations.

Vulnerability Testing

Our engineering team has strong security-related background and experience, however we know that no system is perfect. In order to identify potential security issues, we perform internal security audits on a regular basis and operate a public Bug Bounty Program. Additionally, we have partnered with edgescan for continuous external vulnerability scanning of our systems.

If you think you've identified a security issue please submit the details to us using our Security Bug Reporting Form. Our team will work with you to verify the issue and make sure it gets corrected quickly.

System and Organization Controls (SOC) Report

SendSafely’s internal controls, policies and procedures related to the AICPA Trust Service Criteria (Security) are audited annually by an independent third party examiner. SendSafely enterprise customers that are on a paid Business/Enterprise plan may request a copy of the latest SOC report by contacting privacy@sendsafely.com.