Everything added to a space is end-to-end encrypted. We cannot see the content you share. Only devices with the sharable URL will be able to become an endpoint able to decrypt the content added to a space.

What does end-to-end encrypted mean?

End-to-end encryption is a process for transmitting data that cannot be read by anyone except the original sender and the destination device. The original sending device and the destination devices are “the ends” in the “end-to-end” chain. Any intermediate server or device will only see the encrypted bytes (or cipher), which will look like random noise. No first-party or third-party service will be able to reconstruct or rebuild the original data. Only “the two ends”—the original sender and the destination device—will be able to read the data.

IBM has a good page about end-to-end encryption, if you want to dig deeper into the concept and technology.

Why is end-to-end encryption important?

End-to-end encryption makes it impossible for services to read or process the data on their servers in a centralized way. This removes the risk of a large data breach containing customer content and reduces the value to would-be attackers.

Many services only encrypt data "in transit" or "at rest", which means the service itself can read and process the data at any time. This means it's possible for anyone with access to the service's internal systems to access the data. We’ve all read about data breaches at some of the largest companies over the past decade. Anytime data is pooled or stored together in one central place, it is risky and a high-value target for attackers.

What is the difference between end-to-end encryption and encryption "in transit" or encryption "at rest"?

When data is end-to-end encrypted and transmitted to a service, the service is not able read and process the data. Only the original device and the final destination device can decrypt, read, and process the data being sent. This is much more private and secure than "in transit" or "at rest" encryption.

Services that encrypt data "in transit" or "at rest" only prevent unauthorized third-parties from reading or processing the data. The first-party service or anyone with access to the service's internal systems can read and process the unencrypted data at any time.

Can you explain end-to-end encryption with an example?

A simplified example of sending a photo from one smart phone (A) to another (B) using new.space:

1. Phone A visits new.space, which creates a new empty space and sharable space link. The secret keys for the sharable link are only known to Phone A and are not sent to the remote servers.
2. Phone A adds a photo. It is fully encrypted on the phone itself, and then the encrypted bytes (the cipher) are transmitted to the remote servers for persistence. The remote server cannot see or rebuild the original photo from the cipher. It looks just like random bytes to the server.
3. Phone A shares the sharable space link with Phone B, which looks similar to new.space/s/abcd#1234
   • The part of the link after the # (the fragment or hash) is a “secret key” that is only known to Phones A and B. Browsers are required not to send the part after the # to the server. So, new.space‘s servers will never see or know the secret key. The key really is a secret only known to Phones A and B.
4. Phone B opens the link, connects to new.space/s/abcd, and downloads the encrypted version of the photo.
5. Now, Phone B can use the sharable space link’s secret key #1234 to decrypt the photo and display it in the browser.

At no point did new.space or Shareup’s servers know or need to know the secret key or the original photo’s unencrypted information. Sharing securely in a privacy-preserving way doesn’t need to be difficult.

What type of encryption is used for new.space?

• new.space uses SSL/TLS for all data in transit.
• Data stored in our RDBMS are encrypted at rest and in transit.
• All end-to-end encryption operations use the libsodium library.
• Every item’s name and related content are encrypted with a secret key using XSalsa20-Poly1305.
• Every file is encrypted in ≈4MB chunks by libsodium’s secretstream algorithm, ChaCha20Poly1305-IETF.
• Different entities inside new.space have a public-private key pair used for encryption and/or signing.
  • Encryption key pairs use X25519 and XSalsa20-Poly1305.
  • Signing key pairs use Ed25519.
  • Every device generates two public-private key pairs, one for encryption and one for signing, and the private keys never leave the device.
  • Every space has a public-private key pair used to encrypt and seal every item’s secret key
    • When a device is added to a space, the space’s private key is encrypted for the device’s public key and sent to that device.
    • When an item is added to a space, the item’s secret key is encrypted for the space’s public key, and then the cipher is shared with all members of the space.
  • Every sharable space link:
    • Has a public-private key pair, used to encrypt and seal the space’s private key.
    • Has a secret key used to encrypt the link’s private key.
    • The symmetric key is included in the URL’s fragment (or hash) which is never sent to our servers from the browser.

What is encrypted in a space? What can the Shareup team see in a space?

• Every item’s name and related content is encrypted before it leaves the device.
• Every file is fully encrypted before it leaves the device.
• Every space, item, and other entities have random, unique identifiers, all of which are used to provide the service – to know which items are in which space, for example – and are known to Shareup.
• The dates and times when things happen – like when a space is created or an item is added to space – are known to Shareup.
• Some metadata – like the dimensions of a photo or the extension of a file – are used to provide the service and are known to Shareup.
• The plain text name of a shared space is used to provide a URL preview and is known to Shareup. The space’s name is public so that people given a link know what it contains before opening it.