Hacker News new | ask | show | jobs
by SaltNHash 539 days ago
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.
1 comments

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