Comment by motohagiography | Hacker News Reader

Comment by motohagiography | Hacker News Reader

motohagiography

> keys are split across a decentralized network [...] so no one ever holds the full key. [...] in a breach there’s no unchecked authority exposed.

so shamir secret sharing, which requires users to coordinate to unlock vaults and get tokens, and if one key gets compromised, the attacker still has to solve the coordination problem with a threshold of other key holders. that's within the realm of things we trust today.

there are a few black boxes and flags in the description that would ordinarily get hammered pretty hard by security people who have to make decisions about this stuff, but more charitably:

I'm guessing the fabric is probably a ledger that users subscribe to and that's how it becomes decentralized? imagining how this works, tidecloak adds its fabric as a party to each users (ephemeral?) SSS vault, where the fabric would usually be a centralized dependency, but if the number of SSS parties on the user vault is 3 or greater, your fabric key also requires coordination with another party to participate in unlocking the vault, so it can only participate optionally in an SSS vault decrypt- and probably just for something like a change/recovery operation?

(I'm speculating a bit to draw out some concrete corrections, as the some of those term usages in the description would draw heavy flak in a technical sales or architecture meeting.)

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 on news.ycombinator.com