[HN Gopher] FOKS: Federated Open Key Service
___________________________________________________________________
FOKS: Federated Open Key Service
Author : ubj
Score : 134 points
Date : 2025-07-10 12:49 UTC (10 hours ago)
(HTM) web link (foks.pub)
(TXT) w3m dump (foks.pub)
| maxtaco wrote:
| 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 wrote:
| > 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 wrote:
| E2E-encrypted git. Keybase has KBFS, and FOKS has a poor
| man's equivalent, which is E2E-encrypted Key-value store.
| eterps wrote:
| 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 wrote:
| 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 wrote:
| 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.
| pmw wrote:
| Max, this looks interesting and I'd like to follow the blog.
| Would you please add an Atom feed to the blog?
| singpolyma3 wrote:
| 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 wrote:
| 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.
| WhatIsDukkha wrote:
| For context this is the original keybase guy coming back to make
| a workalike opensource version -
|
| https://blog.foks.pub/posts/introducing/
| marcopolo wrote:
| The fact that this already has git support is amazing. I can
| easily migrate my Keybase git repos with a single command.
| pzduniak wrote:
| 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!
| hofrogs wrote:
| AI-generated images on the front page really take away from the
| trustworthiness of this thing..
| kstrauser wrote:
| 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 wrote:
| Not having any pictures at all is better than having AI
| pictures, in my opinion
| brookst wrote:
| Perhaps it's a filter to intentionally scope audience.
| lijok wrote:
| And you're not just having a kneejerk reaction?
| kstrauser wrote:
| Why is that different from disliking their font preference?
| It's an aesthetic choice, made by someone who's not
| advertising their web design expertise, that's purely
| subjective.
|
| If this site were their product, maybe that'd matter. But
| why does that matter in this context?
| chowells wrote:
| Because it shows a lack of respect for and understanding
| of the work graphic artists actually do. Now if that's
| your brand, great. You are communicating it effectively.
| If it's not your brand, it's probably worth considering
| the subtext in your presentation.
| eadmund wrote:
| > it shows a lack of respect for and understanding of the
| work graphic artists actually do
|
| No more than wearing off-the-rack clothes shows a lack of
| respect for and understanding of the work tailors
| actually do.
|
| No more than wearing factory-woven cloth shows a lack of
| respect for and understanding of the work weavers
| actually do.
|
| No more than heating a can of soup shows a lack of
| respect for and understanding of the work chefs de
| cuisine actually do.
|
| In my cases as well as yours, one certainly can choose to
| spend extra for the luxury of the best to meet the want,
| but it is also fine to spend less and meet the need. In
| my cases as well as yours, judging someone for the value
| he assigns to a luxury is gauche.
| XorNot wrote:
| It's free software. Graphic artists don't work for free.
| progval wrote:
| It shows a lack of attention to detail when the
| illustration for "Merkle Trees" is not a forest (it has
| cycles). And "A Simple Key Hierarchy" could use an
| illustration of a real example instead of nonsense.
| tln wrote:
| Those images (bootstrap, vault) are so tertiary to the both the
| article and the project.
|
| I'm excited to try this out personally! Thanks for building
| this maxtaco
| pmw wrote:
| 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 wrote:
| 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.
| ethan_smith wrote:
| Federation in key services solves a critical problem: it prevents
| centralized control while maintaining the convenience of
| discovery and verification across organizational boundaries.
| minitech wrote:
| Are all of this account's comments AI-generated?
___________________________________________________________________
(page generated 2025-07-10 23:00 UTC)