I'm in the very conceptual phase of designing an open source password manager that provides distributed Vaults that can be simultaneously accessed and managed from multiple devices with the promise of never storing passwords in the cloud and never having a monthly subscription fee. I ultimately plan to support all of the following platforms:

  • Linux
  • macOS
  • Windows
  • iOS
  • Android

Because I plan on Vaults' being distributed, the Vault files can be platform-specific (not portable across platforms) if absolutely necessary; however, I would like the option for non-mobile devices (Linux, macOS, Windows) to be able to share Vaults on a networked file system instead of via the distributed system, so I'd like to keep that in mind during my designing.

My initial plan (which I am not married to and am open to changing; no code has been written yet) was to store Vaults as an in-memory "file system" (mock quotes because this is a pseudo-idea that might not need to be an actual file system) that gets flushed to a single encrypted file on disk. I believe the easiest way to achieve the distributed nature will be for a "directory" within the "file system" to contain a Git repository, because Git has already solved all the hardest problems I need to solve. (The reason the entire Vault won't be a Git repository is that the Vault also includes non-version-controlled metadata files specific to the local instance [clone] of the Vault.)

Perhaps this is as simple as a Zip file (without compression for performance reasons, or alternatively a Tar file), but with an encryption layer between the Zip and the disk (because standard Zip encryption is not very good). But some important requirements:

  • All of the above platforms (C++ for Linux and Windows, Swift or Obj-C for macOS and iOS, Java for Android) must be able to load and read this "file system" into memory after decryption, without ever writing the individual files in the file system to disk, otherwise encryption is defeated.
  • I need to be able to point libgit2 / objective-git / SwiftGit2 (in most cases) and jgit (on Android) to the "directory" in the "file system" that's actually only in memory because it was never extracted to disk, or do something very similar to this.

All of that said, I'm having a hard time figuring out exactly how to architect this. At one point I was considering taking advantage of libgit2's support for backends (for non-filesystem storage of objects and references) and jgit's InMemoryRepository, but the former is very poorly documented (and as such difficult to figure out how to apply to my use case, and it's not clear if objective-git and/or SwiftGit2 even support backends yet), and the latter provides no way to dump the underlying bytes somewhere (in my case "files" in the "Zip file" or equivalent). I could probably eventually figure out backends, and looking at the jgit source, I can probably extend InMemoryRepository to provide a way to "flush" the bytes, but if there's a better way, then there's no point in messing with this.

So that's where I am at this point—trying to figure out the best way to securely store these metadata files alongside a Git repository, all encrypted inside a single file on disk, which gets read into memory frequently (every time the password manager is unlocked) and flushed back to disk frequently (every time a change is committed or a remote commit is merged) and never, ever stored decrypted on disk in any extent. I would appreciate suggestions.

  • 1
    You could look into things like VeraCrypt (no affiliation) or similar on-the-fly encryption tools. Nov 28, 2023 at 13:49
  • 1
    That sounds like a fun project. Probably too many variables to answer in simple question - answer form here. @BartvanIngenSchenau makes a good point about using existing encrypted container software. I don't think there is any such software that covers all the platforms you mentioned.
    – joshp
    Nov 28, 2023 at 21:59
  • 1
    For simply making a container file without encryption, Java Zip Filesystem or other zip file API's will likely work on Windows, Linux, Mac OS. Don't think Zip Filesystem is available in android jdk. Java zip tools can be set to no compression, though in this case with data so small as credentials it may not matter. I'm not convinced this is a great idea but it's an easy way to prototype. Zip tools and encryption exist for Objective-C and Swift, of course.
    – joshp
    Nov 28, 2023 at 22:04
  • 1
    It's hard to miss the cost of building secure encrypted container software. The veracrypt source gives a window into that. I'd be looking for one or more solid proven containers with decent api or embedding use scenarios.
    – joshp
    Nov 28, 2023 at 22:12


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.