[HN Gopher] Show HN: TideCloak - Decentralized IAM for security ...
___________________________________________________________________
Show HN: TideCloak - Decentralized IAM for security and user
sovereignty
Hey HN! After 6 years of R&D, our small team is excited to share
our project TideCloak - an IAM designed to help developers move
fast without worrying about catastrophic breaches or overpowered
admins with keys to the kingdom. Traditional IAMs rely on
centralized authority - admins, root certificates, and decryption
keys - which create glaring vulnerabilities in a breach. To address
this, we've integrated Keycloak (Red Hat's IAM) with a
decentralized key architecture powered by our (academically
validated) Ineffable Cryptography. Here's the idea: keys are split
across a decentralized network (our Cybersecurity Fabric) so no one
ever holds the full key. Even in a breach or F$%k up, there's no
unchecked authority exposed. Right now, TideCloak uses the
Cybersecurity Fabric as an IdP, meaning users authenticate without
their credentials being stored or shared. Essentially, users bring
their own authority - without needing to trust anyone else to keep
it safe. Coming soon: - Identity Governance Administration to
prevent super admin abuse. - User-sovereign digital assets, where
assets are secured with unique decentralized keys to protect
against mass breaches. We've just launched a free developer
sandbox, and we'd love your feedback: https://github.com/tide-
foundation/tidecloak-gettingstarted It's still early stages, and
your input will help us improve. Thanks for taking a look - ask us
anything!
Author : SaltNHash
Score : 21 points
Date : 2024-12-19 10:17 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| HumanOstrich wrote:
| What is the "Cybersecurity Fabric"? I see it mentioned a lot, but
| having trouble filling in details.
|
| Update: I found the answer and the research paper[1]. Based on
| what I've gleaned so far, this looks pretty awesome. It's like..
| Horcruxes, but the participants assemble it blindly and instead
| of getting a soul, you get access to something without revealing
| the key.
|
| [1]: https://arxiv.org/abs/2309.00915
| whatnotests2 wrote:
| Amazing. I wanted this, but didn't want to build it.
|
| You did.
|
| Thank you!
| SaltNHash wrote:
| Cheers! The idea is that anyone can tap into the Fabric, but
| also participate in it (coming soon)
| dboreham wrote:
| A common weakness in schemes like this is that the user has to
| trust that the decentralized network operators don't collude and
| don't all have the same vulnerabilities.
| laxk wrote:
| How does TideCloak's decentralized key architecture relate to W3C
| DID standards [1]? Do you see TideCloak aligning with DID Core
| principles in future development?
|
| [1] https://www.w3.org/TR/did-core/
| SaltNHash wrote:
| 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.
| vednig wrote:
| Are the encryption quantum safe?
| SaltNHash wrote:
| 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.
| AlphegA wrote:
| They're working with a quantum safe research team from
| Wollongong Uni to create a quantum safe key. The whole scheme
| by itself is based on shamir SS that is quantum safe.
| ajb wrote:
| Given that IAM is used by cloud providers as a lock-in mechanism,
| how do you plan to get them to allow users to use your IAM? Or is
| this not aimed at that market?
|
| Congrats on the launch!
___________________________________________________________________
(page generated 2024-12-19 23:01 UTC)