8 ms·

FOKS: Federated Open Key Service

301 points by ubj 1y ago

maxtaco 1y ago
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.
- eterps 1y ago
  > TL;DR: FOKS is like Keybase, but fully open-source and federated What features from a user perspective does it currently have in common with Keybase? F.e. I remember Keybase mostly for secure messaging using public identities (HN, Reddit etc.), and sharing data/files.
  - maxtaco 1y ago
    E2E-encrypted git. Keybase has KBFS, and FOKS has a poor man's equivalent, which is E2E-encrypted Key-value store.
    - eterps 1y ago
      Thanks! Sorry for being lazy, but I was wondering how you share something using the E2E-encrypted KV store (it wasn't obvious in the website)? In kbfs, I remember it was as easy as putting it in a comma separated usernames path.
      - maxtaco 1y ago
        It's not as seamless. You need to first make a team, then invite (or add) that user into the team, and then use `foks kv put --team <your-team>`. One key difference is that in Keybase, all user's profiles were essentially world-readable. FOKS aims for more privacy by default, so in order to add Bob to your team, Bob has to first allow you view his sigchain, so you can learn his public keys. The add vs invite distinction referred to above is because servers can choose different visibility policies. You can set up a server at foks.yourdomain.cc, and set it to "open-viewership", which means that any user can see any other user by default. If you and Bob are both on that host, you can add him to your team without his permission. But other hosts, like foks.app, do not work this way, and Bob has to authorize you to view him.
- dannyobrien 1y ago
  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.
  - kreetx 1y ago
    I would like to second this! I'm still using Keybase for e2ee git, and have been on the lookout for alternatives because Keybase isn't developed (AFAICT) and may just disappear when the people keeping it up lose interest.
  - maxtaco 1y ago
    Thanks Danny! The Keybase team (not including me) deserves all the credit, I've been gone for over six months. It's a great team and I miss working with them.
  - frytaped 1y ago
    Can't Keyoxide be considered as a decentralized, open source version of Keybase ?
- pmw 1y ago
  Max, this looks interesting and I'd like to follow the blog. Would you please add an Atom feed to the blog?
- xtajv 1y ago
  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.
- deleted 1y ago
  [deleted]
- deleted 1y ago
  [deleted]
- oooyay 1y ago
  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.
  - maxtaco 1y ago
    Thanks! Would love to see a file sync app, an MLS-based chat (where the encryption key is essentially a combination of the keys output from MLS and the PTK from FOKS). Password managers. I think there's the potential for something like a Hashicorp-Vault-style server-side secret key material manager, but many details left to reader. Maybe a Skiff-style Google-docs clone? I think there are lot of potential directions to go in.
    - packetlost 1y ago
      Something like pa should be easy enough to port to it as a first pass: https://github.com/biox/pa https://github.com/biox/pa IMO Vault is really nice, but something as simple as possible is better for managing secrets, especially when the storage layer has permission and sane encryption handled for you.
- jazzyjackson 1y ago
  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. https://keri.one/ https://keri.one/
  - rapnie 1y ago
    A good 3-part "Hitchhiker guide" introduction to Keri is available to get a quick overview. Here part two "What exactly is KERI?": https://medium.com/finema/the-hitchhikers-guide-to-keri-part-2-what-exactly-is-keri-e46a649ac54c https://medium.com/finema/the-hitchhikers-guide-to-keri-part...
- dpifke 1y ago
  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.
- vkaku 1y ago
  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? P.S. I built this for Group Encryption a few years ago, to help circulate key hives offline https://github.com/guilt/groupenc https://github.com/guilt/groupenc
singpolyma3 1y ago
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?
- maxtaco 1y ago
  Correct! Remote members of the team get access to shared team keys, and the team's data, even though they don't have accounts on that server. Knowledge of the team key suffices to allow a remote user to authenticate and transfer (encrypted) data to and from the server. There is very little server-to-server communication, which simplifies the design and software upgrades.
raphinou 1y ago
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.
- akafazov 1y ago
  Try looking into SSI (self-sovereign identity) and verifiable credentials - the use-case you are referring to.
  - raphinou 1y ago
    Thanks for the pointers. Are first glance, SSI seem to be mainly Blockchain based, which we diverted from to be able to have easy on premise deployments. Verifiable credentials look interesting, but need to check usability. We want our solution to be very easy to use.
- maxtaco 1y ago
  This would be a great application for us! We are not exactly there yet, for reasons of privacy. Right now, there is no way for alice@host to allow unauthenticated users to view her profile. But we can definitely allow this on a host-by-host basis. With this small change, I think your application fits very naturally. I wonder, what sort of interface is right for you? A library to compile against or a CLI app to shell out to? If a library, which languages?
  - raphinou 1y ago
    Interesting! We're at a very early stage of the implementation and develop in rust. We aim to provide multi-sig capabilities, as defined in a JSON file where the public keys of the signers can be found. If a signer looses a key, we want this 'signers' file to be updatable with the new key. We decided that signers can be humans of processes, so the keys are not an identity of a person, which might be an important detail. Currently, to update a signers file, other members of the multi-sig must sign the update. This works fine, but we are early enough in the project implementation to explore other approaches, hence my question. We'd rather not shell out to a cli, and would preferably go with a lib or rest interface.
hobofan 1y ago
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. [0]: https://getsops.io https://getsops.io
WhatIsDukkha 1y ago
For context this is the original keybase guy coming back to make a workalike opensource version - https://blog.foks.pub/posts/introducing/ https://blog.foks.pub/posts/introducing/
marcopolo 1y ago
The fact that this already has git support is amazing. I can easily migrate my Keybase git repos with a single command.
- pzduniak 1y ago
  I used to use Keybase Git repos for file-based secrets management for my toy DevOps project. Either FOKS Git repos or native support in SOPS would be pretty damn cool!
aitchnyu 1y ago
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.
- maxtaco 1y ago
  Thanks for these great questions! - limiting users to delete/push/force; this is possible but I don't see how to cryptographically guarantee it. The server can't really help since it doesn't know what's a pack, index data block or ref. The clients can enforce this policy, but then it would be possible to make an evil client that skirts the policy. How much protection do you think you need? - the server repo right now is implemented 100% as a postgresql DB, so yes, I think that means it's incremental backup-friendly? [1] - e2ee git has trouble being as efficient as regular git since the server can't tell you which blocks it has; however, there are pretty good optimizations made using indices and packfiles, the white paper has more details, and I hope to write a blog on it soon. - I'm not sure about the sqlite question. Is there a good way to backup sqlite incrementally over standard git? If not, then maybe the KV-store is better fit for this application. I agree that git over E2EE is the best storage, even for things like PDFs and photos. Yeah, FOKS should be hostable with a very thin VPS. The storage needs will scale (n log n) as the number of users due to the Merkle Tree, but for small n, this is likely fine! [1] https://www.postgresql.org/docs/17/continuous-archiving.html#BACKUP-INCREMENTAL-BACKUP https://www.postgresql.org/docs/17/continuous-archiving.html...
  - aitchnyu 1y ago
    Can we fetch incremental changes from KV-store? I want to read the KV store docs. Could you share that? Why is server repo specifically Postgres? Thanks for the answers!
    - maxtaco 1y ago
hofrogs 1y ago
[flagged]
- Datagenerator 1y ago
  [flagged]
  - hofrogs 1y ago
    I feel like this comment is AI-generated, also
    - brookst 1y ago
      Absolutely, I can see why you feel that way.
- kstrauser 1y ago
  And in reality, someone making a personal project used a tool at their disposal to add pretty pictures to their website, said website not being a part of the project in any way. If they vibe coded the app, sure, be skeptical. But there's no indication they did, just that they wanted images for their website, and they're a software engineer and not a graphics designer. I put about as much weight in the origin of those graphics as which website editor they use. If they were advertising themselves as a web designer, sure, maybe that's relevant. That's not what they're doing here though.
  - hofrogs 1y ago
    Not having any pictures at all is better than having AI pictures, in my opinion
    - brookst 1y ago
      Perhaps it’s a filter to intentionally scope audience.
    - lijok 1y ago
deleted 1y ago
[deleted]
pmw 1y ago
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?
- maxtaco 1y ago
  I'm not familiar with Radicle, but I'll check it out. For (1), consider the case of that server being hosted on AWS. Even though only members are authorized to SSH into it, the plaintext is still known to the cloud hardware, and can be exfiltrated that way. In FOKS, the server sees encrypted data only, so that attack is greatly mitigated. I would say that if the SSH server was hosted on one of the workstations of one of the team members, then the security advantages of FOKS would be much less. The KV-Store and Git server are implemented as "applications" on top of the FOKS infrastructure, so they aren't coupled. They see a sequence of Per-Team-Keys (PTKs); they use the older ones for decryption and the newest for encryption. I'd really love to see all sorts of other applications built on top of FOKS but we might need to do some work as to nailing the right plugin architecture.
akoboldfrying 1y ago
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.)
lordfnord 1y ago
[flagged]
deleted 1y ago
[deleted]
ethan_smith 1y ago
[flagged]
- minitech 1y ago
  Are all of this account’s comments AI-generated?
  - Retr0id 1y ago
    Yes, I clocked it in another thread.
bobvylan 1y ago
[dead]
xtajv 1y ago
Okay sorry nobody's said it yet. I'll say it. 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)
- horsawlarway 1y ago
  Eh - my take is it's just "Fox" (as clearly indicated by the large fox in the logo). Firefox did just fine with that name. I don't really think it's a huge problem.
- richrichardsson 1y ago
  It's literally that word in Afrikaans! edit: actually, I'm not sure if "fok" is used, but "fokken" is and it's fairly obvious what it means.
- disintegrator 1y ago
  Not a Firefox user I take it?
- password4321 1y ago
  Zero FOKS given
iovoid 1y ago
The whitepaper says: > 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.
- maxtaco 1y ago
  Easy multi-accounting is something that I hope we already have (`foks key switch` is pretty smooth). It's a feature I use a lot (I have a personal account on @foks.app and our company account is on @ne43.foks.cloud). This is a great point and I thought a lot about this. This is the sort of thing that can be changed later if it's really a good idea, but I got to thinking that having non-local admins would mean more server-to-server communication and more server-to-server trust, and I was trying to avoid that. Imagine alice@foo is an admin of bluejays@bar. One thing alice@foo will need to do is to make signed changes to bluejays@bar, when adding or removing members, let's say. Right now, the server at bar will check the validity of these signatures, that they were made with the alice@foo's latest key. So in other words, there would have to be some way for bar to authenticate to foo to allow bar to read alice's sigchain and to determine her latest key. I was thinking that keeping foo and bar separated was a good idea both in terms of privilege separation and keeping the network simpler (which would in turn be good for uptime and would simplify software upgrades).
fooqux 1y ago
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. 0: https://www.passwordstore.org/ https://www.passwordstore.org/
soundofvictory 1y ago
This project sounds incredibly interesting. Of course there is terrible AI-generated slop stock images on the homepage.
ymolists 1y ago
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 ?

301 points by ubj 1y ago

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.

eterps 1y ago
> TL;DR: FOKS is like Keybase, but fully open-source and federated What features from a user perspective does it currently have in common with Keybase? F.e. I remember Keybase mostly for secure messaging using public identities (HN, Reddit etc.), and sharing data/files.
- maxtaco 1y ago
  E2E-encrypted git. Keybase has KBFS, and FOKS has a poor man's equivalent, which is E2E-encrypted Key-value store.
  - eterps 1y ago
    Thanks! Sorry for being lazy, but I was wondering how you share something using the E2E-encrypted KV store (it wasn't obvious in the website)? In kbfs, I remember it was as easy as putting it in a comma separated usernames path.
    - maxtaco 1y ago
      It's not as seamless. You need to first make a team, then invite (or add) that user into the team, and then use `foks kv put --team <your-team>`. One key difference is that in Keybase, all user's profiles were essentially world-readable. FOKS aims for more privacy by default, so in order to add Bob to your team, Bob has to first allow you view his sigchain, so you can learn his public keys. The add vs invite distinction referred to above is because servers can choose different visibility policies. You can set up a server at foks.yourdomain.cc, and set it to "open-viewership", which means that any user can see any other user by default. If you and Bob are both on that host, you can add him to your team without his permission. But other hosts, like foks.app, do not work this way, and Bob has to authorize you to view him.
dannyobrien 1y ago
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.
- kreetx 1y ago
  I would like to second this! I'm still using Keybase for e2ee git, and have been on the lookout for alternatives because Keybase isn't developed (AFAICT) and may just disappear when the people keeping it up lose interest.
- maxtaco 1y ago
  Thanks Danny! The Keybase team (not including me) deserves all the credit, I've been gone for over six months. It's a great team and I miss working with them.
- frytaped 1y ago
  Can't Keyoxide be considered as a decentralized, open source version of Keybase ?
pmw 1y ago
Max, this looks interesting and I'd like to follow the blog. Would you please add an Atom feed to the blog?
xtajv 1y ago
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.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
oooyay 1y ago
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.
- maxtaco 1y ago
  Thanks! Would love to see a file sync app, an MLS-based chat (where the encryption key is essentially a combination of the keys output from MLS and the PTK from FOKS). Password managers. I think there's the potential for something like a Hashicorp-Vault-style server-side secret key material manager, but many details left to reader. Maybe a Skiff-style Google-docs clone? I think there are lot of potential directions to go in.
  - packetlost 1y ago
    Something like pa should be easy enough to port to it as a first pass: https://github.com/biox/pa https://github.com/biox/pa IMO Vault is really nice, but something as simple as possible is better for managing secrets, especially when the storage layer has permission and sane encryption handled for you.
jazzyjackson 1y ago
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. https://keri.one/ https://keri.one/
- rapnie 1y ago
  A good 3-part "Hitchhiker guide" introduction to Keri is available to get a quick overview. Here part two "What exactly is KERI?": https://medium.com/finema/the-hitchhikers-guide-to-keri-part-2-what-exactly-is-keri-e46a649ac54c https://medium.com/finema/the-hitchhikers-guide-to-keri-part...
dpifke 1y ago
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.
vkaku 1y ago
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? P.S. I built this for Group Encryption a few years ago, to help circulate key hives offline https://github.com/guilt/groupenc https://github.com/guilt/groupenc

singpolyma3 1y ago

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?

maxtaco 1y ago
Correct! Remote members of the team get access to shared team keys, and the team's data, even though they don't have accounts on that server. Knowledge of the team key suffices to allow a remote user to authenticate and transfer (encrypted) data to and from the server. There is very little server-to-server communication, which simplifies the design and software upgrades.

raphinou 1y ago

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.

akafazov 1y ago
Try looking into SSI (self-sovereign identity) and verifiable credentials - the use-case you are referring to.
- raphinou 1y ago
  Thanks for the pointers. Are first glance, SSI seem to be mainly Blockchain based, which we diverted from to be able to have easy on premise deployments. Verifiable credentials look interesting, but need to check usability. We want our solution to be very easy to use.
maxtaco 1y ago
This would be a great application for us! We are not exactly there yet, for reasons of privacy. Right now, there is no way for alice@host to allow unauthenticated users to view her profile. But we can definitely allow this on a host-by-host basis. With this small change, I think your application fits very naturally. I wonder, what sort of interface is right for you? A library to compile against or a CLI app to shell out to? If a library, which languages?
- raphinou 1y ago
  Interesting! We're at a very early stage of the implementation and develop in rust. We aim to provide multi-sig capabilities, as defined in a JSON file where the public keys of the signers can be found. If a signer looses a key, we want this 'signers' file to be updatable with the new key. We decided that signers can be humans of processes, so the keys are not an identity of a person, which might be an important detail. Currently, to update a signers file, other members of the multi-sig must sign the update. This works fine, but we are early enough in the project implementation to explore other approaches, hence my question. We'd rather not shell out to a cli, and would preferably go with a lib or rest interface.

hobofan 1y ago

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. [0]: https://getsops.io https://getsops.io

WhatIsDukkha 1y ago

For context this is the original keybase guy coming back to make a workalike opensource version - https://blog.foks.pub/posts/introducing/ https://blog.foks.pub/posts/introducing/

marcopolo 1y ago

The fact that this already has git support is amazing. I can easily migrate my Keybase git repos with a single command.

pzduniak 1y ago
I used to use Keybase Git repos for file-based secrets management for my toy DevOps project. Either FOKS Git repos or native support in SOPS would be pretty damn cool!

aitchnyu 1y ago

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.

maxtaco 1y ago
Thanks for these great questions! - limiting users to delete/push/force; this is possible but I don't see how to cryptographically guarantee it. The server can't really help since it doesn't know what's a pack, index data block or ref. The clients can enforce this policy, but then it would be possible to make an evil client that skirts the policy. How much protection do you think you need? - the server repo right now is implemented 100% as a postgresql DB, so yes, I think that means it's incremental backup-friendly? [1] - e2ee git has trouble being as efficient as regular git since the server can't tell you which blocks it has; however, there are pretty good optimizations made using indices and packfiles, the white paper has more details, and I hope to write a blog on it soon. - I'm not sure about the sqlite question. Is there a good way to backup sqlite incrementally over standard git? If not, then maybe the KV-store is better fit for this application. I agree that git over E2EE is the best storage, even for things like PDFs and photos. Yeah, FOKS should be hostable with a very thin VPS. The storage needs will scale (n log n) as the number of users due to the Merkle Tree, but for small n, this is likely fine! [1] https://www.postgresql.org/docs/17/continuous-archiving.html#BACKUP-INCREMENTAL-BACKUP https://www.postgresql.org/docs/17/continuous-archiving.html...
- aitchnyu 1y ago
  Can we fetch incremental changes from KV-store? I want to read the KV store docs. Could you share that? Why is server repo specifically Postgres? Thanks for the answers!
  - maxtaco 1y ago

hofrogs 1y ago

[flagged]

Datagenerator 1y ago
[flagged]
- hofrogs 1y ago
  I feel like this comment is AI-generated, also
  - brookst 1y ago
    Absolutely, I can see why you feel that way.
kstrauser 1y ago
And in reality, someone making a personal project used a tool at their disposal to add pretty pictures to their website, said website not being a part of the project in any way. If they vibe coded the app, sure, be skeptical. But there's no indication they did, just that they wanted images for their website, and they're a software engineer and not a graphics designer. I put about as much weight in the origin of those graphics as which website editor they use. If they were advertising themselves as a web designer, sure, maybe that's relevant. That's not what they're doing here though.
- hofrogs 1y ago
  Not having any pictures at all is better than having AI pictures, in my opinion
  - brookst 1y ago
    Perhaps it’s a filter to intentionally scope audience.
  - lijok 1y ago

deleted 1y ago

[deleted]

pmw 1y ago

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?

maxtaco 1y ago
I'm not familiar with Radicle, but I'll check it out. For (1), consider the case of that server being hosted on AWS. Even though only members are authorized to SSH into it, the plaintext is still known to the cloud hardware, and can be exfiltrated that way. In FOKS, the server sees encrypted data only, so that attack is greatly mitigated. I would say that if the SSH server was hosted on one of the workstations of one of the team members, then the security advantages of FOKS would be much less. The KV-Store and Git server are implemented as "applications" on top of the FOKS infrastructure, so they aren't coupled. They see a sequence of Per-Team-Keys (PTKs); they use the older ones for decryption and the newest for encryption. I'd really love to see all sorts of other applications built on top of FOKS but we might need to do some work as to nailing the right plugin architecture.

akoboldfrying 1y ago

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.)

lordfnord 1y ago

[flagged]

deleted 1y ago

[deleted]

ethan_smith 1y ago

[flagged]

minitech 1y ago
Are all of this account’s comments AI-generated?
- Retr0id 1y ago
  Yes, I clocked it in another thread.

bobvylan 1y ago

[dead]

xtajv 1y ago

Okay sorry nobody's said it yet. I'll say it. 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)

horsawlarway 1y ago
Eh - my take is it's just "Fox" (as clearly indicated by the large fox in the logo). Firefox did just fine with that name. I don't really think it's a huge problem.
richrichardsson 1y ago
It's literally that word in Afrikaans! edit: actually, I'm not sure if "fok" is used, but "fokken" is and it's fairly obvious what it means.
disintegrator 1y ago
Not a Firefox user I take it?
password4321 1y ago
Zero FOKS given

iovoid 1y ago

The whitepaper says: > 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.

maxtaco 1y ago
Easy multi-accounting is something that I hope we already have (`foks key switch` is pretty smooth). It's a feature I use a lot (I have a personal account on @foks.app and our company account is on @ne43.foks.cloud). This is a great point and I thought a lot about this. This is the sort of thing that can be changed later if it's really a good idea, but I got to thinking that having non-local admins would mean more server-to-server communication and more server-to-server trust, and I was trying to avoid that. Imagine alice@foo is an admin of bluejays@bar. One thing alice@foo will need to do is to make signed changes to bluejays@bar, when adding or removing members, let's say. Right now, the server at bar will check the validity of these signatures, that they were made with the alice@foo's latest key. So in other words, there would have to be some way for bar to authenticate to foo to allow bar to read alice's sigchain and to determine her latest key. I was thinking that keeping foo and bar separated was a good idea both in terms of privilege separation and keeping the network simpler (which would in turn be good for uptime and would simplify software upgrades).

fooqux 1y ago

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. 0: https://www.passwordstore.org/ https://www.passwordstore.org/

soundofvictory 1y ago

This project sounds incredibly interesting. Of course there is terrible AI-generated slop stock images on the homepage.

ymolists 1y ago

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 ?