FOKS: Federated Open Key Service(foks.pub) |
FOKS: Federated Open Key Service(foks.pub) |
https://medium.com/finema/the-hitchhikers-guide-to-keri-part...
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
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.
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.
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?
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.
There is very little server-to-server communication, which simplifies the design and software upgrades.
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
> 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.)
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.
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?
We'd rather not shell out to a cli, and would preferably go with a lib or rest interface.
> 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.
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).
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)
Firefox did just fine with that name. I don't really think it's a huge problem.
edit: actually, I'm not sure if "fok" is used, but "fokken" is and it's fairly obvious what it means.
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.
- 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...
Why is server repo specifically Postgres?
Thanks for the answers!
Of course there is terrible AI-generated slop stock images on the homepage.
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.
The best docs for the KV store are in the white paper, Section 5.1. White paper is linked to from foks.pub
Postgres seemed to check all the boxes for me. I wanted to keep things very simple at first in terms of setup and ongoing management, so didn't introduce other storage backends for other parts of the system.
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.
I wonder if the policy you describe could be implemented as world-visible team with world-visible users. Others have commented on the need for something like this, so I think it should be pursued with high priority. What's slighlty fuzzy to me is how these totally world-viewable teams and users would interact with more closed-down users on other servers.
World visible teams and users might be a way to define our multi-sigs members. But we would still need a JSON file for others characteristics of the multi-sig. I'll keep an eye on foks as if it becomes a good fit, it might let us concentrate on our service and not on key management intricacies. My email is on my HN profile, in case you want to notify me of advancement fitting our use case.