Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FOKS: Federated Open Key Service

foks.pub

Post reply on HN
Print view View original

61–70 of 82 posts

Re: FOKS: Federated Open Key Service

#61

Post by kreetx »

dannyobrien wrote: post #11
maxtaco wrote: post #2

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 n…

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.

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.

Re: FOKS: Federated Open Key Service

#62

Post by aitchnyu »

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.

Re: FOKS: Federated Open Key Service

#63

Post by akoboldfrying »

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

Re: FOKS: Federated Open Key Service

#64

Post by maxtaco »

aitchnyu wrote: post #62

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 w…

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

Re: FOKS: Federated Open Key Service

#65

Post by maxtaco »

raphinou wrote: post #58
maxtaco wrote: post #55

Earlier quoted context omitted.

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…

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 deta…

An attack that might be of concern with this configuration is the server suppressing updates to this JSON file, or showing different versions of the JSON file to different clients. What you're describing is pretty close to what FOKS is getting at with signature chains and Merkle Trees, but maybe it's overkill for this particular application.

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.

Re: FOKS: Federated Open Key Service

#66

Post by aitchnyu »

maxtaco wrote: post #64
aitchnyu wrote: post #62

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 w…

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…

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!

Re: FOKS: Federated Open Key Service

#67

Post by xtajv »

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)

Re: FOKS: Federated Open Key Service

#68

Post by maxtaco »

aitchnyu wrote: post #66
maxtaco wrote: post #64

Earlier quoted context omitted.

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…

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!

No incremental fetch right now other than what postgresql provides by default. If you're hosting a FOKS server, there is important metadata to backup too.

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.

Re: FOKS: Federated Open Key Service

#69

Post by xtajv »

maxtaco wrote: post #2

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 n…

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.

Re: FOKS: Federated Open Key Service

#70

Post by horsawlarway »

xtajv wrote: post #67

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…

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.

Post reply on HN