SaltNHash

Great material. Good onya for sharing!

Tide team here. Our dev Sasha built this PoC in a few weekends, using our SDK. Her core idea: Remove the risk of compromised keys, and the overhead of managing them at scale, by never having a key to steal. Instead the SSH signing operation is distributed across nodes using novel MPC-based threshold EdDSA – the key literally never exists in whole, not even momentarily in a TEE.

KeyleSSH is: - Browser-based SSH console - Auth via OIDC, signing via distributed novel MPC-based threshold EdDSA - appx 30 lines of core signing logic (the SDK does the heavy lifting)

It isn't (yet): - Production-ready. It's a PoC. - Fully decentralized. The nodes currently run on our testnet – we're working toward a proper decentralized mainnet. If you run infrastructure and are curious about operating nodes, happy to chat. - A silver bullet. Browser-based means endpoint compromise is still a threat vector.

Live demo: demo.keylessh.com Source: github.com/sashyo/keylessh

AMA about the protocol, the SDK, or the threat model.

Yes it does. It replaces it with a break glass quorum approved process.

Hi HN,

Keycloak is a popular open‑source Identity & Access Management (IAM) server, but like most IAMs it lets any admin make instant, irreversible changes. In regulated or high-security setups that "god mode" is a nightmare.

We built Keycloak-IGA, a fork that bakes a light weight approval workflow into the server, which must be cleared before high stakes changes can go live:

Features include: - Draft → Pending → Approved states for user, role, client & realm changes - Quorum engine (default "70%" of admins) - four-eyes control enforced by code - Zero overhead unless you switch it on - Emits audit events aligned with PCI-DSS, SOX, ISO 27001, HIPAA, NIST 800‑53

Try it in a few mins git clone https://github.com/tide-foundation/keycloak-IGA cd keycloak-IGA docker compose up # spins a demo realm with IGA extensions pre-wired

Walkthrough video(4min): https://www.youtube.com/watch?v=BrTBgFM7Lq0

Looking for feedback on: - Does the built‑in model beat the usual "proxy + ticket + webhook" approach? - Is 70% quorum sane? Would you prefer fixed reviewers, AD groups, etc.? - What's missing before you'd trust this in prod?

Background & design notes: https://github.com/keycloak/keycloak/discussions/41350

MIT licensed, so fork away, and tell us what you think.

Thanks!

Someone once asked how would you cope with lawful interception of corrupt law enforcement agencies, so allow me to explain TideCloak in that context: imagine a corrupt agency requests the identity information of a specific user of TideCloak: they file a subpoena from the TideCloak operator – however the root identity of the user doesn't reside there. It's with Tide's Fabric. So, the agency has to file subpoenas in all the jurisdictions that this particular user's ID is split. Let's say that's this user's authority is spread across 17 countries across 9 jurisdictions – you'll need the cooperation of all those jurisdictions to get access to a single user identity. Still possible for an Interpol-coordinated task force for a valid law enforcement operation, but that's going to be very hard to get under the radar if the agency is corrupt.

Regrettably, neither this particular post nor the github content has any chatgpt-inflated content. This is entirely all human-manure.

In the end, it boils down to trusting only what you can verify. Unlike any comparable system today, every cog in TideCloak's architecture is entirely verifiable to its administrators, operators and end-users – so there's no requirement to blindly trust any single component. There is no "us" to trust due to the decentralized nature of the fabric. I can explain how decentralizing each aspect works in TideCloak, but unfortunately, it’ll take more than half a page...

License file now added to the Github, thanks! Currently, the Cybersecurity Fabric (decentralized network service) is in Beta, so we're only offering free "as-is" developer licenses. We anticipate that eventually, the service will be approx 50c/user/month or there abouts.

Tricky question, because the answer to this will evolve in time (as planned). First, thanks for pointing out the license issue on Github. We'll fix that right away. The Cybersecurity Fabric operates based on the Tide Protocol: our WIP open standard. TideCloak is exactly that: just an implementation of that protocol on a Keycloak IAM. The protocol is "source available" but "commercially restricted" - similar to the BSL modus operandi. It'll take us some time to properly document that protocol to a level adequate for release - but in the meantime, we'll provide office hours and direct interactions with the community to share that knowledge.

That point is pure gold! This is such a critical aspect that we hardly see addressed even in the leading platforms. This exact sentiment was the drive behind our SDKs primary premise: Assume a breach! Assume an error-prone junior dev. Assume belief an example code is real code. We aim to have our technology protect user's authority/identity from buggy developers. We want to protect the organization's systems from mistakes the developers or administrators have made. We aim to protect companies from themselves. Our documentation is in its very early days. We've got the technology, but we don't have a (much needed) sample api service yet to demonstrate how the dev DOESN'T need to verify the JWT or qualify against blacklists (the SDK will do it), DOESN'T need to worry about session hijacking, etc. But that's exactly what we're working towards.

Not sure how to quantify "how much is new" as like all other breakthroughs are "built on the shoulders of giants". I'd find it almost impossible to answer that same question accurately if it was asked about something like Kyber (Post quantum cryptography) - which would probably be newer than Tide. A proper answer would require quite a lengthy seminar, I'm guessing. Your last question is a fascinating one and the answer is: no. We're not asking people to suspend their disbelief. On the extreme contrary: we'd encourage them to challenge it as much as they should challenge their current beliefs. Today's automated belief in all existing Zero-Trust vendors may be misplaced/misguided. The blind beliefs in all IAM vendors should be re-examined. We ask for people to question their automated belief in the integrity of processes such as: "JWT introspection" where the same entity that generated an attestation is now requested to validate it, or if an OIDC connection is "secured" by a shared "client secret", there's no need to verify the JWT signature, or it's safe to send passwords over HTTPS because it's secure by SSL, or it's safe to store passwords on a server because it's hashed and salted, or passkey is foolproof because it's stored in the TPM, etc... How many of these beliefs are verifiable to the end-user???

Check how many analogies I managed to squeeze into this thought piece https://medium.com/bugbountywriteup/how-nature-holds-the-key...

So many great points raised here! Allow me to try and cover as much as possible. In a way, you can say TideCloak uses the Fabric as a key vault for (1) each user's authority (2) its own central authority. This way, even when TideCloak is completely breached, neither its users or own authority and authorization can be compromised. For simplicity, let's call those "authorities" keys. Whenever use of those keys is required, TideCloak makes a request to the Fabric, and as a swarm, the Fabric manifest that request in a multi-party fashion (a few steps up from standard SSS) and replies with the required artefact (access token, ephemeral decryption keys, signed consent, etc) in such a way that the secret keys are never assembled or exposed. Tidecloak itself, therefore, holds no user credentials or root certificate, so a breach of the IAM or an administrator is far less consequential. That API request is, for all intents and purposes, the coordination you mentioned. The Fabric is a "centralized dependency" as much as DNS is, or the internet. Yes, without the Fabric, those vaults are inaccessible – but the Fabric is robustly highly-available and resilient. Regarding the potential flak you mentioned, if you meant from describing the technology in high level terms, noted! If you meant because the approach we’re proposing introduces (and requires) a shift from today's paradigm, I think you’re devastatingly spot on. We’re expecting this concept to attract pushback, because it demands relinquishing centralized ownership of those authorities to some "ineffable" vault that no one can access. It's a big ask – but, it's also the only guarantee that if no one can access it, it can never be compromised. In my mind I’d liken it to the objection "on-demand hosted" architecture attracted in the early 2000s, which later became the ubiquitous "cloud". We can't avoid the resistance to change other than by continuing to push forward with the help of the significant academic scrutiny we’ve received to date, and the tailwind of a community interested in advancing it through participation.

You understand it perfectly. This is an example of an SPA that displays content based on authentication/roles – all client side. This was to demonstrate the simplest, most straightforward implementation in a few minutes. If you look closer, the authentication is secure by a signed-JWT which can easily be extended to server side content customization and direct api/db access. Developers in our beta program are already doing this across ReactJS / NextJS / Java / Dotnet / PHP/ Etc.

Absolutely true! And that’s only half of it. In schemes like this, how can you even tell the operators are following protocol? How do you know it's not a façade? At the edge of all those schemes, there's a point where you simply must rely on blind trust. Solving this challenge was one of our greatest motivations – and the only way to replace blind trust is through total verifiability. As far as we’re aware, our approach is the only one that allows verifiability on all facets: 1) access to source code, 2) having the ability to verify client-side code in run-time is another (in two different ways), and 3) last, but most important, anyone can opt to run parts of their keys on their own privately hosted nodes – so even if the entire network is colluding, you have the guarantee your own nodes aren't. Happy to elaborate.

Analogy = Nailed! Can we use that one?

Thanks. The ideal end game is for the Cybersecurity Fabric to become a de-facto standard for best practice security inside the biggest platforms in the world (Entra, Okta, AWS, Google etc). So individuals can login with Tide (i.e. with their own authority). The protectionism only works until one plucky provider decides to use an open standard and starts winning business from the others... But let's assume that's years down the track, if we're right about that.

For now we're quite happy to provide an alternative for platform developers not bound to the big end of town.

The TideCloak (Keycloak) component does provide for options like federating or synchronizing with other IAMs in greyfield enterprise environments, to stage the integration.

Cheers! The idea is that anyone can tap into the Fabric, but also participate in it (coming soon)

The multi-party-computation and zkps used to generate the keys, authenticate to them, encrypt / decrypt and sign with them are PQ resilient. The key presentation layer (i.e. the key standard we've currently deployed) are elliptic curve based, so in theory would be susceptible. We're already working on other key presentations, including PQC algorithms, all handled in multi-party. We're already able to manage SSH keys in the Fabric.

Yep - there's already a working group in the Keycloak community aligning with various standards. In our case, the Cybersecurity Fabric is the component that handles ownership, secure portability and revocation.

Funny! That was exactly how our first design conversation went! A year after and lots of tests and experiments to validate we came up with Splintering - a method that encrypts a 'human-grade' password (aka 'much weaker than a private key') and shards it across multiple nodes so the complexity and difficulty of breaking it increases to levels corresponding to a cryptographic key. Splintering is an added-security extension to a fully decentralized authentication scheme. For details on how exactly, you're welcome to dive into the paper or at a glance the flow diagram on our git, where we’ve also published our open source code. https://github.com/tide-foundation/Tide-h4x-for-Privacy