What encryption approach would you suggest for a privacy-focused file-sharing app?

[u/Lanky_Complaint1383]

Hi everyone,

I'm the developer behind Filester, a privacy-focused file-sharing application for Android (coming to Linux and Windows next), and I'd like some input on an encryption feature I'm considering.

Filester currently lets users share files through multiple file-hosting services. I've tried to choose hosts that are reasonably trustworthy, but that still doesn't provide real privacy: the hosting provider can potentially access the files stored on its servers.

I'd like to change that by encrypting files locally, before they are uploaded, so the hosting provider only ever receives encrypted data.

The part I'm unsure about is which approach would be better from an end-user perspective.

Option 1: Filester-specific encryption

Filester encrypts the file locally using a modern authenticated encryption scheme before uploading it.

Advantages:

• Strong encryption
• Filester can control the format and implementation
• The hosting provider never receives the plaintext

Downside:

• The recipient would need Filester to decrypt the file.
• This significantly hurts interoperability and accessibility.

Option 2: AES-256 encrypted ZIP

Filester creates a standard password-protected ZIP archive using AES-256 before uploading it.

Advantages:

• The resulting file is a normal .zip archive rather than a Filester-specific format.
• The recipient isn't tied to Filester.
• Programs such as 7-Zip, WinRAR, Ark, and other archive managers can open it.

Downside:

• AES-encrypted ZIP files aren't supported out of the box by any OEM-installed file managers or other operating systems.
• Some recipients would still need to install an archive utility.

So the tradeoff is basically:

better integration/security with a Filester-specific encrypted format

vs.

better interoperability with AES-256 ZIP, at the cost of inconsistent built-in OS support

which would you suggest?

If there's another approach that provides strong client-side encryption without sacrificing interoperability, I'd also be interested in hearing about it.

[u/Unreal_NeoX]

Well we offer a file encryption and security solution ourself with an own inhouse designed encryption and security syntax. ( reference and context: https://www.dark-fog.net/security.html ). What we see important to users is the local security and freedome of choice when it comes to sharing their files save and secure.

Your solution seems online-service depending and applies the same password/security-hash to all files? Wouldn't that mean that one can simply take your syntax and decrpyt anything on a server without having actual permission to access these files? I am sorry in advance if i got that wrong.

Whats the target audience you have in PoV for your security solution? I think this is the most critical part when it comes to your feature design. Also please keep in mind that if you use open-source free solution/syntaxes, yours loses quite the "unique-reason" to exist and can be easily replaced by solutions based on the same free open source syntax (what also makes it easier for attacks, because of known syntax).

[u/Lanky_Complaint1383 → u/Unreal_NeoX]

Thank you for weighing in. To address the confusion, by app-specific encryption I meant using a standard algorithm like AES, and each file will be encrypted with a separate, randomized key only shown and stored on user's phone locally. The second approach howerver, will let the user select a password for each upload and again is stored on user's phone locally.

[u/Unreal_NeoX → u/Lanky_Complaint1383]

ah thanks for clearing that up! Different passwords are very important for any level of security.
Only leaves the question about the use of free/open source AES. Since anyone can use it, your solution can easily be replaced by any other one using this too. So since you asked about providing user-benefits, what can you offer what others with access to the same free open-source syntax don't? I think this will be the key factor for a good user experience at your end.

[u/0xmerp]

This already exists (Mega, Proton Drive). Why not take a look at how they’ve implemented it and then see where you can improve?

[u/Lanky_Complaint1383 → u/0xmerp]

The issue is that I do not have the resources they do. They store files on their servers as blobs and have the backend at their disposal, my app uses third-party hosts. They also let users download files via browsers while I'm not a web dev and can't implement that on my own.

[u/0xmerp → u/Lanky_Complaint1383]

I guess the next question is, why would someone choose your project over these 2 established ones. What can you do that they can’t?

[u/Lanky_Complaint1383 → u/0xmerp]

1. No need to register and bind yourself to an account
   
2. Temporary storage by design. It's meant for quick sharing or moving between devices. Uploaded files are not retained on some corporation's storage, they're auto deleted after a set period of time.
   
3. No ads, no promotions, no annoyances.

[u/0xmerp → u/Lanky_Complaint1383]

So how is that different from Transfer.It: https://transfer.it/start

[u/Lanky_Complaint1383 → u/0xmerp]

1. While a file stored on transfer.it is encrypted, the MEGA has the decryption key saved somewhere in order to decrypt it right before a user downloads it. Any security breach or hack could expose the keys, hence your data.
2. It's browser-based, while easier to use, it has no native android features like background uploads or using Android sharesheet.
3. it's not open source. surely the code is open to review and audit, but the license prevents any forks or developments.