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.
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
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?
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.
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.
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.
Thank you. The challenge here is how to trust it. I think leading with stating that this is a paradigm shift is key, and then it's important to show how it pivots from first principles. Right now, the description has what appear to be proprietary product terms (fabric, ineffable, etc) where ordinarily there would be some more familiar terms of art from cryptography.
How much of this is net new, and are we asking people to suspend their disbelief?
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???
reply