FOKS

End-to-End Post-Quantum Encrypted Git Hosting

FOKS provides a secure, end-to-end encrypted Git hosting service. Your data is encrypted on your machine before it is sent to the server, and the server never sees data or filenames in unencrypted form. This means that even if the server is compromised, your data is safe. FOKS is federated, so the git server can be one that you host, or one that is hosted for you.

Additionally, FOKS uses modern PQ-secure public-key cryptography, so all end-to-end encrypted data is safe from quantum attacks.

End-to-End Post-Quantum Encrypted Key-Value Store

Internally, FOKS implements git atop an encrypted key-value store. Clients encrypt keys and values before sending them up to the server, and decrypt them upon retrieval. You can access this key-value store directly, which can store either short strings, or large data files.

Federated and Generalized Team Management

FOKS provides a federated and generalized team management system. You can create teams, add members, and assign roles. You can also delegate team management to other team members. Teams can be members of other teams, allowing for complex team topologies that can mirror real-world organizations. Morever, teams can cross federated boundaries, allowing users on different FOKS servers to share data with end-to-end encryption.

Device Management with Full YubiKey Support

FOKS provides a device management system with full YubiKey support. You can register your devices with FOKS and manage their access. You can also revoke access to a device if it is lost or stolen. Revoking triggers a cascading key-rotation across all teams you are members of, whether local or federated. This keeps data secure going forward.

A Simple Key Hierarchy

To power applications like the Git and KV-Store shown above, FOKS needs a shared symmetric key for all readers and writers of the data, available only to the authorized devices, teams users and keys that the authors specify. FOKS achieves this natural application requirement with a simple key hierarchy.

Everything starts with base-level keys, like user device keys, backup keys, or YubiKeys. Device keys are generated on user devices and never leave the machine they are generated on. They are protected locally with system-specific encrypted stores where possible, and passwords where not. Other base-level keys include backup keys (for which a human-readable code is the seed), or YubiKeys.

Every user of the system has a sequence of per-user-keys (PUKs) at the next level up the hierarchy. The secrets seeds for these keys are encrypted for all available base-level keys. A PUK rotates whenever a base-level key is removed.

At the next level up there are teams, which work much like users. All members of the teams share per-team-keys (PTKs), which are encrypted for the team's members, be they users (via PUKs) or teams (via recursive PTKs).

Signature Chains

In FOKS, there are two types of parties: users and teams. In both cases, there is a rotating list of constituents (be they devices or team members), and as these constituents change, so to does the corresponding active PUK or PTK. As such users and teams share much protocol design and implementation mechanism.

In both cases, the set of keys that can sign on behalf of the party changes over time, and it's crucial for security that there is a careful accounting of these keys that resists tampering by the FOKS server.

To prevent tampering, FOKS uses "signatures chains", a linear chain of signatures that can be played back to verify the ordering of signatures, and that each signature was performed with a key that was valid at the time of signing.

Merkle Trees

When different parties or computers access keys for a party, they do so via signature chains; they grab these chains from the server and play them back to discover the current set of keys that represent a party.

A compromised server can still cheat here by forking chains, or by withholding updates. A Merkle Tree is deployed on each federated host to hold it accountable to one consistent view of the world. Each signature link is immutably stored in the tree, preventing various forms of "vacilation."

FOKS further introduces a novel technique to hide updates from outside observers with only simple cryptography (and without VRFs).

Boring Hardened PQ Crypto

FOKS makes an effort to use the simplest, most boring, most hardened possible crypto. It makes extensive use of Go's standard implementation of the NaCl library. Whenever Diffie-Helman over Curve25519 is used, it's combined with the NIST-standardized ML-KEM algorithm to give post-quantum security.

We've made an effort to avoid fancier crypto like VRFs, SNARKs, STARKs, etc., in favor of simple primitives wherever possible. For instance, it might seem Neanderthal to use simple hashes instead of VRFs to hide positions of items on our Merkle Tree. But do you know of any good PQ-secure VRFs?

Security & Integrity

The world has become accustomed to strong end-to-end encryption and integrity for ephemeral messaging. Other applications have not enjoyed the same level of security. FOKS aims currently to provide the best possible security for long-lived data, like persistent file storage (Git) and persistent key-value storage.

FOKS is designed from a security-first perspective, and not as a bolt-on to an inherently insecure product. The team has used decades of experience in similar products to achieve a level of security that we are proud of.

Privacy

Despite its ethos of forcing servers to immutably and publicly commit to cryptographic data, FOKS hides personal information behind one-way commitments as much as possible. Details like user names, team names, device names, team memberships and leaf locations remain obscured unless users are granted explicit permission to access these data. Thus, users on the same server can feel confident that their personal metadata are safe, even as the server commits to the global state of all its data.

Open Source

Claims of end-to-end encryption are dubious at best if the source code at the ends remains closed off from inspection, and if users cannot build the software themselves. FOKS is fully open-source. All components, client and server, are available under an MIT license. You can run it, fork it, and modify it to suit your needs. We accept contributions and feature requests, but we are a very small team, so please be patient.

Bootstrapped

We know that a lot of projects start as open-source, but later rug-pull their users due to the economics of their funding models. The creators behind FOKS have not taken on any outside funding, and are pursuing its creation as a passion project. We think there might be a good business in being a default hosting provider for FOKS, which might provide the funding for the team to continue development of the project indefinitely.

Federation

Users are right to fear "vendor lock-in" if storing their important data in the cloud. FOKS is fundamentally designed to give users peace of mind here, as it is an inherently federated protocol. Like email or the web, anyone can permissionlessly run a FOKS server. There are many reasons users might choose to do so, such as data-residency, avoiding production dependencies on thrid-party systems, added privacy, or better control over data.

But also like email and the web, independent federated systems can still cleanly interact. In FOKS, teams can span federated severs, so users can share data as if they were on the same server.

Generality

FOKS is a general protocol, like email or HTML/HTTP. We have built two starter applications to show the power of the basic primitive. But hope to build more applications soon, and we want others to build their end-to-end encrypted applications too. The basic building block is a set of shared symmetric keys that rotate when necessary. From here, the options are limitless.