Max here, author of FOKS. I find it interesting how much glue is required to perform basic cryptographic operations, even in 2025. Imagine a very simple idea like encrypting a secret with a YubiKey. If it's an important secret, that you really don't want to lose, then now you need a second YubiKey as a backup, in case the primary is lost or breaks. But now how do you encrypt and how do you rotate the primary out if needed? To the best of my understanding, there aren't great solutions short of a system like FOKS. If not FOKS, I really believe a system like it ought to exist, and it ought to be entirely open, so that arbitrary applications can be built on top of it without paying rent.
Max! I'm so happy that you're doing this! I was a huge fan of Keybase, and have spent the last few years praying (and sometimes brainstorming funding) a decentralized, open source version of it. Looking forward to digging into the details of FOKS, but just wanted to say thank you and the Keybase team for all you've done -- including keeping Keybase going after the Zoom purchase.
FOKS is a cool project; what kind of projects do you foresee getting spun off from this?
I'm actually working on a crytpography based project inspired by Keybase's use of Merkle Trees and identity proofing but with an added dash of privacy through pseudonyms and chain hashing. Thanks for putting time into this.
If you haven't seen KERI they're worth a read, I found out about them at an Internet Identity Workshop. It has all those quality of life features for public keys - revocation, rotation, recovery. "Key Event Receipt Infrastructure". Relies on "witnesses" which I don't know if I love it but their presentation impressed me.
This is actually so needed. I've heard the phrase "minting your own tokens?!" used as an argument for (N)oAuth. The current state of affairs is honestly just sad.
For all of GnuPG's faults, the usage you've described is exactly why I still use it. I have my master PGP key copied to several offline Yubikeys (one of which is stored offsite), and two day-to-day Yubikeys (one of which is always with me on my physical keychain) containing my current signing and encryption subkeys. The signing subkey is also used for SSH authentication. The second slot on the day-to-day Yubikeys is used for WebAuthn/Passkeys. The master key is brought out of storage only if I need to rotate or revoke a day-to-day subkey, or attest someone else's key for web-of-trust purposes.
I sign all of my Git commits, as well as Debian packages. I occasionally sign and encrypt email. My most important encryption use case is file backups, which are encrypted to my public key and copied offsite.
I'm excited about FOKS if it can serve as a modern alternative to the above, with fewer footguns that GnuPG.
Good to know someone's thinking of decentralizing the whole thing :) Always been wondering where to lay these keys out, if people want to start recovering their data / keys. Something like this + IPFS would be radical, and allow folks to encrypt and circulate easily. Thank you for building this. So ... I wonder how you got here after building Keybase, what's the motivation this time, how do you envision this gets hosted?
How does the "federation" work? I assume the actual team data is stored on a single foks server, the one the term is on, so I guess from there you basically have some lightweight SSO for team members using their server?
To better wrap my head around how FOKS facilitates team collaboration, I'd like to see two comparisons:
1) compare to a team-shared Linux machine with SSH daemon. Each team member has a user account, and they can manage their SSH authorized keys, including keys stored on Yubikey. The team can share files and git repositories on the Linux machine's own storage. Some differences I see with this approach are the federated aspect and "append-only data structures that allow clients to catch dishonest server behavior".
2) compare to Radicle, a decentralized git service. Identities are keypairs.
With FOKS, how coupled is storage of git and secrets to the FOKS server?
I am working on an open source project where users provide signatures of their projects artifacts (this is oversimplified for the sake of the discussion).
Started using Minisign as the signature scheme. But we're struggling to find a clean solution for users keys renewal, revocation and updated public key distribution. I thought foks might help for that but the examples don't seem to confirm this. Basically the question I need to answer is :how can users trusting an existing signing key also trust the new key replacing it? I hoped we might outsource this to foks, but I think I misunderstood foks in the first place.
It looks cool, and I agree with the creators that something like this ought to exist and optimally free from monetization incentives.
From a user standpoint it does seem like quite the undertaking to introduce it though. Most of the needs I'm looking for from such a system are currently already filled quite well by SOPS[0], where I would say I get 80% of the features (I care about) for 10% of the complexity.
Max, can users be limited to delete/push/force push certain branches? Is a server repo incremental backup-friendly? Is is as efficient in storage space and data transfer as regular git? Can we incrementally sync dbs like Sqlite?
Seems this is the best E2EE storage. No choosing creator's cloud vs finicky self hosting, nor worry about flaky sync solutions for my password manager, note app, photo storage etc. A 2$ vps would be overkill.
This looks interesting, but I'm having a lot of trouble understanding the section "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.
These base-level keys are private keys, no? The previous paragraph introduces symmetric keys, and doesn't discuss private/public keypairs.
> 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.
Is the idea that, if user Joe is a member of group Sales (I know, I know, how boring this example is), and Sales is a member of group Employees, if Joe wants to write something that all Employees can read, he first decrypts a symmetric key for Sales using one of his personal base-level private keys, uses that to decrypt a symmetric key for Employees, and then stores his data encrypted data with that Employees symmetric key?
> 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.
Does "rotating" here mean simply "potentially changing [over time]"?
Also, do I understand correctly that "rotate keys" means "choose a new key, decrypt everything that was encrypted with the original key, and then reencrypt it all with the new key"? If so, then since servers do not have access to keys (needed for decryption), I think this means that, whenever someone leaves a group or a device is lost, some client must download all data available to that group, decrypt, reencrypt and reupload it -- is that right? This suggests it would be expensive to have frequently-changing groups with access to a lot of data. (I'm certainly not suggesting I know a better way -- just checking my understanding.)
I will not be entering the workplace and suggesting that we use a product whose name is very easily mistaken for "the F word". It is an immediate non-starter.
(I'm sure it's a great project, and you probably meant for people to pronounce the name as "folks" rather than... y'know, the other way. I'm telling you this in a spirit of kindness so your project can be more successful and see increased adoption)
Max, the first thing I thought of for use cases here is a better backend for pass[0]. Being able to manage people, families (aka teams), and getting the ability to more easily manage my yubikeys are all wins.
can you replace systems like infisical with something like foks ? where are the similarities/differences ? would it make sense to use foks for a secrets store in kubernetes for example ?
30 comments
[ 3.3 ms ] story [ 61.3 ms ] threadI'm actually working on a crytpography based project inspired by Keybase's use of Merkle Trees and identity proofing but with an added dash of privacy through pseudonyms and chain hashing. Thanks for putting time into this.
https://keri.one/
I sign all of my Git commits, as well as Debian packages. I occasionally sign and encrypt email. My most important encryption use case is file backups, which are encrypted to my public key and copied offsite.
I'm excited about FOKS if it can serve as a modern alternative to the above, with fewer footguns that GnuPG.
P.S. I built this for Group Encryption a few years ago, to help circulate key hives offline https://github.com/guilt/groupenc
https://blog.foks.pub/posts/introducing/
1) compare to a team-shared Linux machine with SSH daemon. Each team member has a user account, and they can manage their SSH authorized keys, including keys stored on Yubikey. The team can share files and git repositories on the Linux machine's own storage. Some differences I see with this approach are the federated aspect and "append-only data structures that allow clients to catch dishonest server behavior".
2) compare to Radicle, a decentralized git service. Identities are keypairs.
With FOKS, how coupled is storage of git and secrets to the FOKS server?
> all the admins and owners — those who have the ability to change the team — must be on the same home server
Maybe with easy multi-accounting it could be made less annoying, but this seems like a big limitation for a federated system.
Started using Minisign as the signature scheme. But we're struggling to find a clean solution for users keys renewal, revocation and updated public key distribution. I thought foks might help for that but the examples don't seem to confirm this. Basically the question I need to answer is :how can users trusting an existing signing key also trust the new key replacing it? I hoped we might outsource this to foks, but I think I misunderstood foks in the first place.
From a user standpoint it does seem like quite the undertaking to introduce it though. Most of the needs I'm looking for from such a system are currently already filled quite well by SOPS[0], where I would say I get 80% of the features (I care about) for 10% of the complexity.
[0]: https://getsops.io
Seems this is the best E2EE storage. No choosing creator's cloud vs finicky self hosting, nor worry about flaky sync solutions for my password manager, note app, photo storage etc. A 2$ vps would be overkill.
> 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.
These base-level keys are private keys, no? The previous paragraph introduces symmetric keys, and doesn't discuss private/public keypairs.
> 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.
Is the idea that, if user Joe is a member of group Sales (I know, I know, how boring this example is), and Sales is a member of group Employees, if Joe wants to write something that all Employees can read, he first decrypts a symmetric key for Sales using one of his personal base-level private keys, uses that to decrypt a symmetric key for Employees, and then stores his data encrypted data with that Employees symmetric key?
> 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.
Does "rotating" here mean simply "potentially changing [over time]"?
Also, do I understand correctly that "rotate keys" means "choose a new key, decrypt everything that was encrypted with the original key, and then reencrypt it all with the new key"? If so, then since servers do not have access to keys (needed for decryption), I think this means that, whenever someone leaves a group or a device is lost, some client must download all data available to that group, decrypt, reencrypt and reupload it -- is that right? This suggests it would be expensive to have frequently-changing groups with access to a lot of data. (I'm certainly not suggesting I know a better way -- just checking my understanding.)
You cannot call it that.
I will not be entering the workplace and suggesting that we use a product whose name is very easily mistaken for "the F word". It is an immediate non-starter.
(I'm sure it's a great project, and you probably meant for people to pronounce the name as "folks" rather than... y'know, the other way. I'm telling you this in a spirit of kindness so your project can be more successful and see increased adoption)
0: https://www.passwordstore.org/
Of course there is terrible AI-generated slop stock images on the homepage.