🚀 Feature: encryption of shared files (the only important missing feature)

[YannuX06]

🔖 Feature description

I would be great if the shared files are stored encrypted on the server. Many of our users are unable to do it before uploading it to the server.

🎤 Pitch

So that if the server (or an admin account) is compromised , no one could read the stored files

[stonith404]

This would only be possible if the share has a password because we need a secret to encrypt and decrypt the files which the server must not know, right?

[Mntz]

The link ID itself could be the secret. This would make management a bit more limited as you won't be able to retrieve shared links since the link IDs are also stored uniquely encrypted.

[stonith404]

@Mntz The share id must be stored in the database and because of that it isn't possible to use it as a secret. The secret must be something that is either not stored in the database or hashed like the password.

Do you think it would be sufficient if only shares are encrypted with password protection or do you have another idea?

[Mntz]

I think that would work fine if you can also enforce password protection in the configuration settings. Then all transfers are encrypted and Pingvin would be a valid solution in a corporate setting requiring this.

[fugidev]

Firefox Send puts the secret in the url hash, which is never sent to the server

[stonith404]

@fugidev, OK, that would be a good solution. The only trade-off is that the URL will get very long.

[PhunkyBob]

User uploading the file could set it's own password. This password would be used to encrypt the binary data on the disk. In the "share" window, he can choose to copy the URL without the password or the URL with the password (with basic encryption). If the receiving user use the URL without password, it will be asked a password to download (and decrypt on the fly) the data.

[Manut38]

I'm really impressed with this project! If you manage to add an e2e encryption similar to the one used by Firefox Send, this will be the best application of its kind by far. Thank you for your work!

[aarondoet]

PrivateBin ensures that all stored data is encrypted. The shareable link format is [domain]/?shareId#password, which allows the server to remain unaware of the actual data. Decryption happens entirely on the client side.

Due to this design, tools like wget cannot be used to download the files because they only retrieve the encrypted data without executing the JavaScript needed for decryption. For this reason, I would not recommend encrypting all shares by default. Instead, only password-protected files could be stored encrypted on the server, as they wouldn't be accessible with tools like wget anyway.

Here are some potential changes that could be made:

1. Store password-protected files encrypted with the password.
2. Use a link format like [domain]/s/[shareId]#[password] to allow automatic authentication and decryption without requiring manual password input. (#301)
3. Add a configuration option to enforce password protection for all shares.
4. Add a configuration option to enable automatically generated passwords. This would create links that include both the share and the password in the URL, rather than just linking to the share alone.

I believe this approach addresses nearly all use cases, including scenarios where company policies mandate encryption, even for tech-unsavvy users who prefer to avoid dealing with passwords. However, it’s crucial to emphasize that losing the link means permanently losing access to the data, it cannot be recovered or re-accessed by simply revisiting the share overview to retrieve the link.

[aarondoet]

Implementation of encrypted storage on the server would mean that if #251 were to be implemented, the password could not be changed. So maybe also make that a config variable?

[OfficiallyCrazy]

Any expectation of implementing this?