I recently publicly released Excalibur, a trustless secure file management solution using military-grade encryption. In this blog post, I’ll explain the design behind Excalibur and how it keeps your files safe.

The desire to create Excalibur stems from wanting to store files so that only the owner(s) have access to them. For most files, there are no concerns with storing them on cloud services such as Google Drive or Dropbox. However, sensitive files (e.g., passwords, bank transactions, employment contracts) need to be treated with more care. We should assume that cloud service providers are able to view, read, snoop, edit, modify, change, and alter the contents of any files that are stored on their system. After all, it is their servers that we are storing our files on. In fact, US cloud providers are legally required to provide requested data stored on their servers when requested by the authorities.

This is the impetus for creating an encrypted file server, so that not even the cloud providers can see what is being stored on their system. To that end, the security model for Excalibur is as follows.

• Assume that an attacker is able to sniff and modify any transmission between client and server¹.
• Assume that the server is able to read and modify any files on its system, and assume that all actions performed on the server are logged.
• Assume that the client is free from malware (as otherwise the files can already be ready and modified by an attacker).

The entire design of Excalibur revolves around these three assumptions. Our goal is to design a system that is able to store files that only the user can read and modify². It turns out that these assumptions are almost identical to those of password managers, just that instead of storing passwords we are storing files. To that end, I arbitrarily chose to follow 1Password’s design because it has a publicly accessible white paper detailing how it keeps data secure.

One of the key security features of Excalibur is that the client and server will perform mutual authentication. That means that not only will the client authenticate itself with the server, the server will also prove its identity to the client. The reason for this is simple: we don’t want the client to mistakenly upload their files to an attacker that is pretending to be the trusted server. As such, the server also needs to prove its identity to the client.

But there is an additional wrinkle to this. Since we are assuming that the server is able to read and modify any files on the system, if the client just uses a password to authenticate itself and the server uses a salted hash to handle the password authentication, any malicious process on the server could start cracking the password based on this hash. And providing this hash to the client definitely does not mean that the server actually knows the password. We need a method for the server to prove to the client that it indeed knows the client’s password (via some indirect manner).

Both of these needs, having mutual authentication while preventing the server from having the password, can be solved by using the Secure Remote Password protocol. I have already made a blog post detailing the mathematics behind SRP, but here’s the gist: using the password hash $x$, a verifier value $v$ is generated using $g^x \mod N$ where $N$ is some prime. This prevents the server from directly knowing the password hash $x$; afterwords SRP engages in a key-exchange process that involves $x$ (or $v$). Since the key-exchange involves the password hash $x$, anyone who does not know the hash $x$ (or has the verifier $v$) cannot derive the shared password. Both client and server will then check if the other got the correct shared key before proceeding with encrypted communications.

Critically, no fragment of the password is ever sent over the insecure network³. What any eavesdropper ever sees will be two ‘ephemeral values’ (i.e., $A$ and $B$ in the SRP process) as well as the two ‘check values’ (i.e. $M_1$ and $M_2$), never the password hash $x$ nor the verifier $v$. And yet the client and server are able to authenticate each other via this mechanism. This thus can be considered as a “zero-knowledge” authentication⁴.

My goal with Excalibur is to make a system that can be used anywhere. And since I am more familiar with web technologies than with native code, I searched for methods to create an app that works for both web and mobile. I eventually settled on CapacitorJS by Ionic, a JavaScript (and TypeScript) library that leverages web technologies to generate Progressive Web Applications (PWA) as well as native apps. This is perfect for my needs. TailwindCSS was chosen as the primary method for styling the application as I was quite familiar with it (in fact, it was what I used to style this website!). Since the app was designed as a PWA first and foremost, the look of the app does not change between platforms.

Apart from the Excalibur application, I also needed to code a server that handles all the requests from the app. After all, what use is the application if there is no server for it to talk to? I opted to use FastAPI to create the web API as it is fast, easy to use, and helps automatically generate nice looking documentation. The file management endpoints were not the big part of the server, that would have to go to the code for the authentication and encryption endpoints. After all, the selling point for Excalibur is that it is encrypted — it has to properly handle the security aspects befitting of a zero-trust secure file server. Hence, the code base is heavily skewed towards handling these security operations. There is even an entire specification on handling the authentication process that is handled by the server.

After many months of work, I am proud to be able to finally release Excalibur to the public. You might notice that its first public release is version 0.2.0, since the 0.1.x series can be considered as minimum viable products (MVPs) for my own use. But the public release of Excalibur does not mean that the work stops here. In fact, there are still a few features that I want to implement:

• Moving files/folders
• Multi-file upload and download
• Automatic token refreshing (so that we no longer have a countdown system)
• File searching

As of now, please try out Excalibur and let me know what you think 😊.