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.
