🔐End-to-end Encryption

When starting a new upload, we offer the option "Encrypt the transfer end-to-end" inside the options section of the uploader. We further introduce this functionality on this page.

Effects of enabled End-to-end Encryption

A transfer with enabled End-to-end (E2E) Encryption encrypts parts of the upload on the client side before uploading and registering the transfer with ysendit.com. These include:

• File content

• File names

• Transfer message

Decryption happens locally on the download page and is only possible with the password set during the upload.

Enabling E2E Encryption requires you to set a transfer password. You can choose your own or leave the password field empty. In latter case, the password will be auto generated and shown during the upload process. Upload speed is a bit slower compared to transfers without E2E Encryption.

Please note that for a mail transfer, email addresses of recipients are not E2E Encrypted due to privacy reasons. The email addresses are only encrypted server side.

Effects for Downloaders

Downloaders need to enter the password set during the upload of your files. You can skip this step for your recipients if you enable the option "Share password with recipient".

With enabled E2E Encryption, only pdf and multi media files up to a size of 250 MB can be previewed on the download page. We do not support the preview of other text document, spreadsheet or presentation file formats. The download speed is a bit slower compared to transfers without E2E Encryption.

Effects of disabled end-to-end encryption

A transfer with disabled E2E Encryption but with a set password still encrypts the file content & name, transfer message and email addresses of recipients on the server side

A transfer with disabled E2E Encryption and without a set password does only encrypt the file content on the server side, but does not encrypt the file names, transfer message and email addresses of recipients.

Sharing of your password

You can share the password of a transfer with your recipients by enabling the option "Share password with recipient". This appends the password to the download link displayed in the uploader and linked to in the mail to your recipients of mail transfers.

Please keep in mind that this option sends your password to our servers. The password gets only processed and not stored. However, it imposes a security risk.

With disabled option "Share password with recipient", your password gets never send to ysendit.com making it impossible for us or attackers to reveal your E2E encrypted transfers.

Comparison

This table compares various upload options. Namely:

• A: Activated E2E Encryption

• B: Disabled E2E Encryption, but password protected

• C: Disabled E2E Encryption, not password protected

Option	A	B	C
File content	E2E encrypted	Serverside encrypted¹	Serverside encrypted¹
File name	E2E encrypted	Serverside encrypted	Not encrypted
Transfer message	E2E encrypted	Serverside encrypted	Not encrypted
Email addresses of recipients in mail transfers	Serverside encrypted	Serverside encrypted	Not encrypted
Transmission of transfer password	Only if "Share password with recipient" is enabled	Only if "Share password with recipient" is enabled	No
List of file names and recipients in emails of mail transfers	Only if "Share password with recipient" is enabled	Always	Always
Preview of files on download page	Only pdf and multi media files up to 250 MB	All file types supported by file preview	All file types supported by file preview

Please not the following details of each encryption type. The colory indicate different security levels:

• E2E Encryption: content gets encrypted on the client side before being sent to ysendit. It is therefore transmitted and stored in encrypted form and can not be retrieved without the transfer password

• Serverside Encryption: content gets encrypted on the server side and gets stored in encrypted form. It is transmitted in encrypted form by using TLS encryption. Technically the content could be revealed before being stored in encrypted form. Thereafter, revealing the content is only possible with the transfer password ¹ One excpetion: the content of files that are serverside encrypted can be decrypted without the transfer password. Content could be revealed by ysendit and attackers that compromise our whole system

• Not encrypted: content gets only transmitted in encrypted form by using TLS encryption but does not get stored in encrypted form

Security considerations

Both, E2E and serverside Encryption (except ¹) have the following properties:

• Confidentiality of content

• Content cannot be truncated, removed, reordered, duplicated or modified without this being detected

• The same content encrypted twice will produce different ciphertexts

Can I choose the same password for multiple transfers?

If you do not need to pass the password to different downloaders, there is no security risk. Your password gets extended with a random nonce before being used as an encryption key making it impossible to derive information from content encrypted with the same password

Is using the option "Share password with recipient" a security risk?

It depends on the transfer type and where you share the download link. For a transfer by link, the option is secure as long as you share the link with your downloaders over an E2E encrypted communication channel like WhatsApp or Signal.

For transfers by mail, the option imposes a security risk as your password will be included in the mail to your recipients and the security depends on the mail servers processing the mails sent to your rercipients and yourself.

How is it possible to encrypt content on the server side without transmitting the transfer password? Isn't that a contradiction?

No. We extend your choosen password with a random nonce and derive a subkey from that. We use this subkey for serverside encryption. Knowledge of the subkey does not reveal the transfer password

Which algorithms do you use?

For E2E Encryption of file content we use ChaCha20-Poly1305 together with a 192-bit random nonce.

For E2E Encryption of file names, transfer message and serverside Encryption (except ¹) we use XSalsa20 stream cipher together with a 192-bit random nonce and Poly1305 MAC.