The motivation for this tool is that sometimes one might need to share files with other people in environments that one cannot control, and there are very few options that allow one to do securely in these cases. For example, one could share a password-protected ZIP file, but until recently Windows didn’t support AES-encrypted ZIP files. I also considered more esoteric options, like embedding a file in a PDF, but this will look ‘weird’ and, again, it’s not a given that there will be a capable enough PDF viewer installed that supports PDF forms.
Since a relatively-modern web browser is installed and available in most end-user devices these days, I set out to build a browser-based tool that can be used for file encryption and decryption.
Despite running in a browser, the tool works as a self-contained HTML file and does not need nor use network access (in fact, content security policy is used to block network access) and is standards-based, meaning that the resulting (encrypted) file can be decrypted either using a web browser, or with other tools that support CMS (Cryptographic Message Syntax), such as OpenSSL.
The demo page did not work. I had to download the html file offline and then try it. And then it worked.
The “DOWNLOAD FOR OFFLINE USE” button top right after you decrypt is sometimes confusing or you naturally end up forgetting that it’s not the download for the decrypted file. Perhaps this button/option should not appear on the decrypt page so only one download option shows. This is more or less a nitpick but I say this as a first time user.
The GUI is simple and easy to use. Well done there!
Will this work on mobile? I have yet to try it but only one way to find out I guess.
You did not mention Brave in the list of browsers supported. So, for anyone reading - it does work on Brave.
I will stress test this with larger files and get back with more feedback. Thank you for making this FOSS tool that’s easy to use. I may get back with some more functionality and feature request ideas I have once I test it more.
Weird, it works for me. Are you share some details of what went wrong? Oh, and did you use the first or the second link? They’re the same, but the first has some additional Cloudlfare rules. Glad to hear at least that the offline version worked.
Thanks for the suggestion, I’ll keep that in mind. It’s there to allow users that receive a file to use the tool themselves, but perhaps it could be made less prominent to avoid confusion. Actually, it was originally gonna be just for encryption, because people would go to the demo page, try to download it by using ‘save’ and that sometimes breaks the app. Then, I added it also to downloads because it seemed useful.
Thank you!
It should work on mobile. It’s a bit harder for me to test, but it should, and there are some caveats. On iOS, I believe you can’t open a local HTML file for viewing (unless you use Edge), so encryption will work (assuming you’re using the demo page or some hosted location) and decryption will work if you use an HTTP server or if you use Edge.
Yes, it should work on Brave, but I didn’t specifically test it. I’ll try to test releases on it too.
If you happen to test it some more and have more comments, I’ll be happy to hear.
The second demo link opens but the tool doesn’t or did not work for me. I don’t know why.
–
I’ll be testing on Windows and Linux (PopOS and Fedora too). Do come back later and you’ll have my suggestions and more feedback. Thanks for responding. I don’t know how much (effort) it takes to maintain this seemingly simple enough tool but I hope you continue maintaining it and making it more stable.
Thanks, I’ll take a look using Brave and fix it. It’s pretty low-maintenance except for new features (I’ve recently made changes to make localisation easier, for example) and I’m planning on continuing to maintain it, as I use it myself. But, it’s simple enough that it should continue working without maintenance.
Quick follow up questions since I’m thinking about it right now so might as well ask:
Another web based encryption tool was posted less than a day ago here called Filekey. And I can’t help but compare the two tools as they do the same things, just differently. You can see my comments there too as feedback.
My question is, how does this tool (btw, what should I call it?) compare to Filekey, Cryptomator, and Proton Drive primarily with respect to the quality of the encryption and stability of the tools. Cryptomator is highly stable and so is Proton Drive on the web for almost all file sizes (except sometimes for more than 5-10 GB sizes on PD). An easy to understand breakdown would be nice to have. I am tech savvy not but by no means a technical or a cryptographic expert to evaluate it myself. I know this is a loaded question and you’ll need to look at their code to see what’s what so take your time. (What I know for sure is Filekey is indeed not stable)
Unlike Filekey, could it be possible to use software passkey functionality/feature from password managers like Proton Pass be used instead or as a backup for your tool as the password? This would set your tool apart from Filekey as software passkeys don’t currently work until PRF is supported by said password manager.
Great question! It currently doesn’t have a name. I originally built it for personal use and to showcase some work in related areas. It’s on the roadmap to come up with a nice name.
Nice, this is the first time I hear about Filekey. I wasn’t able to properly test it because I couldn’t get past the key generation process. In terms of how this tool compares to Filekey, from taking a cursory look:
‘Quality’ of the encryption: Both use AES-256-GCM and the browser crypto APIs. I didn’t conduct a proper audit, but without glaring mistakes the encryption should be about as strong. Since they use generated keys and this uses passwords, there’s a potential for this tool to be less secure, if the password isn’t strong enough (basically, to match the cypher strength of 256 bits, you’d need a password of about 40 random characters).
File size: I wasn’t able to actually use Filekey, but it presumably has the same limitation as this tool does, which is available memory. Browser crypto APIs unfortunately require all input data to be in memory. It’s possible to ‘chunk’ things, but then that breaks / complicates other things, like the integrity protection that GCM mode provides by default. Oh, and my tool (for technical simplicity purposes, I’ll likely fix it soon) has a decryption size limit of about 2 GiB. However, it’s probably not a good fit for such large files anyhow.
Stability: I cannot comment much on Filekey. My tool seems to be fairly stable and also strives to use CMS, a self-imposed requirement, to ensure compatibility with other tools. This at least helps verify the correctness.
Use case: Filekey seems to concerned with local file encryption, with the ability to share files, while my tool is not primarily concerned with local file encryption (although it can be used for that). Instead, its purpose is easily sharing files with other people / device, making as few assumptions as possible about what will be available. This is, for example, why it uses passwords instead of fancier tech like WebAuthn.
Other. There are a few other differences that don’t necessarily affect the quality of the tool, but relate to the trust model:
Both tools seem to work offline (seem here referring to Filekey, as I couldn’t test it myself), but Filekey isn’t a self-contained HTML file (it loads fonts, etc. from its server). It also doesn’t use CSP to block unnecessary network requests, and this can lead to data exfiltration.
They also seem to encourage you to install it as a PWA. I like PWAs, but they can be updated at any time by whomever is hosting it, which introduces opportunities for exfiltration in the future.
These risks can be mitigated by self hosting, and maybe adding a <meta> tag with a restrictive CSP.
I can’t seem to find a repository where development happens. This is because they have a minified version and a readable source version, but without looking at their processes it’s difficult to verify the two versions match, so it’d be nice to have this transparency. My tool uses signed and (almost) reproducible builds, which allow you to see that: it’s an official build and that the build corresponds exactly to the source code (I said ‘almost reproducible’ because different OSes seem to give different build artifacts for some reason, so if you want the same build as what I get / the official build, you need to use a Linux box).
I’ll look into more detail and probably edit this response or post a new one comparing it to Cryptomator and Proton Drive. However, off the top of my head, it seems like those are ‘cloud first’ solutions while mine is ‘just a file’ and can work with any provider, or no provider at all. I believe that both tools solve the issue of ‘sharing a file without too many assumptions on the receiver’ though.
Wow. Thank you for the detailed response. I am still stress testing both tools and will have some feedback in a couple of days.
As to your comment:
Oh boy. We can use this forum to come up with a great name for your tool if you’d like?
@jonah - what do you think? Can we get a post running from you to see what we can name it? I’m sure the community will be happy to become a part of it if @corrideat is amenable?
Yeah, I know. Very few people have been able to. I was barely lucky myself. It’s really an MVP. Albeit, I will be speaking with their dev directly to see how we can improve it in ways that works for all no matter how they want to use it.
–
Thank you so much for the preliminary feedback and context on what you could gather about the tools thus far. Great to read and understand it contextually.
–
@rockwellshah (of Filekey) - hey, sorry to bring you in with/against another developer’s tool but since both options do very similar thing, I and I’m sure others would want to know what you think of it too? Any comments or feedback or things to say about it? You may take your time and I know we are speaking soon so you can comment in full in a week or so if you’d like after our chat. I only ask because of the sheer coincidence of both tools that do same things being shared one day apart. And hey, you never know. There could be a potential of collaboration from both you to provide the world with the best of both of your tools offer (if at all this is or would be something you both would be open to… a tech savvy privacy enthusiast like me can dream, can’t he? I’m just spitballing here)
