Every engineering team shares secrets through Slack. API keys, database passwords, production tokens, all pasted into DMs that persist forever on Slack's servers.

Workspace admins can read them. They're never revoked. One Slack breach and credentials are exposed in a single dump. The alternatives don't fix the core issue. Email sends plaintext across multiple servers and can be forwarded endlessly. Password vaults like 1Password and LastPass are centralized single points of failure. If the provider is breached, everything stored there leaks at once.

Enter Cloak - the only way to safely share secrets, utilizing a single, groundbreaking idea: trust no one. So what exactly is Cloak? Cloak is a slack bot where you can share credentials without the secret ever touching a single server. Secrets are encrypted in the sender's browser, routed through Canton's privacy ledger and decrypted only in the recipient's browser.

The server never sees it. Slack never sees it. Our own bot never touches it. When the recipient is done, the contract self-destructs: gone from the ledger, permanently.

Easily accessible through slack and incredibly safe, Cloak is the premier solution for institutional secret sharing, proudly built on Canton.

Detailed Technical Write Up:

The trust model starts at registration.

When a user runs /cloak-register, the bot allocates a dedicated Canton party identity and creates a UserIdentity contract on the ledger, binding their Slack account to an on-chain identity visible only to their node and the operator. The user receives a DM with a one-time key setup link. Opening it in the browser triggers client-side generation of an RSA-OAEP 2048-bit keypair via the Web Crypto API (crypto.subtle). The private key is stored in the browser's IndexedDB as a non-extractable CryptoKey object. The browser's native crypto engine holds it, and no JavaScript on the page can read the raw key material out. Only the SPKI-encoded public key is exported and uploaded to the server. This is the foundational security guarantee: the decryption key exists only inside one browser, on one device, and the server never sees it.

With keys in place, the sharing flow is fully zero-knowledge. When a user runs /cloak-send aws-key @bob in Slack, they get a compose link that opens in the browser. The compose page fetches the recipient's RSA public key from the server, generates a random AES-256-GCM key, encrypts the secret locally, wraps the AES key with RSA-OAEP, and posts only the resulting ciphertext envelope {v:1, k, iv, t, c} to Canton. The recipient clicks a one-time link, and their browser fetches the encrypted contract from Canton via a 60-second read-only JWT, unwraps the AES key using their private key from IndexedDB, decrypts the secret, and displays it. After acknowledging receipt, the Canton contract archives itself. The secret is permanently gone from the ledger. The plaintext secret exists only in two browsers, only for the moments they need it. Not on Slack's servers. Not on our bot server. Not on Canton. Not on any non-party node. This makes Cloak useful for any scenario where credentials need to move between people securely: DevOps teams rotating production keys, banks sharing API credentials with integration partners, compliance teams proving a credential is valid without revealing it.

It works inside Slack, where teams already share secrets today, but with three independent privacy layers that no existing tool combines: Canton's sub-transaction privacy (data is absent from non-party nodes), end-to-end browser encryption (even party nodes only hold ciphertext), and ephemeral contracts that self-destruct after acknowledgement.

Implementation:

Layer one -> Canton's sub-transaction privacy: The SecretTransfer contract lives only on the sender's and recipient's nodes. Every other participant on the network has nothing.

Layer two -> end-to-end browser encryption: Before the secret even reaches Canton, it's encrypted in the browser. The private key lives in IndexedDB and never leaves the device. Even Canton only stores ciphertext.

Layer three -> everything is ephemeral: One-time links. Sixty-second read-only tokens. Auto-clearing viewers. Acknowledge receipt and the contract self-destructs.
We wrote five Daml contract templates and got protocol-level privacy and that was possible only because of CANTON.

Ensuring complete privacy and trustlessness in a product is crucial and is something that needs to be thought out thoroughly when developing an app that involves managing secrets and API keys. Throughout the course of developing our project, we found ourselves constantly finding flaws within our privacy system and ways where our security would fail.

Our first implementation of this app was done completely via the Slack interface, that is, the user would type their secret key in plain text and receive it in the same format via a Slack DM. However, there was a fundamental design flaw with this approach. Since we were displaying the secrets in the Slack interface anyway, it defeated the purpose of using Canton to privately send over the secrets, as they would still be exposed to Slack (which is an uninvolved third party). We had to completely rearchitect the send and view flows so that encryption and decryption happen exclusively in a custom web page. When a user runs /cloak-send, they receive a time-limited link to our web page to send the secret, rather than typing it in a model within Slack. And when a user receives a token, they again view it in this web page. This way, the secrets would never be exposed to Slack, and only visible on the browser for a few seconds.

Later on, we discovered that the secrets were still not entirely private. With the new web page we implemented, the secret still has to travel from the sender's browser to our server to Canton, and then back out from Canton to our server to the recipient's browser. Our server became a middleman in that path and we realized that the plaintext secret would be visible to our own backend during transit. This meant that anyone with server access, a compromised deployment, or a leaked log could read every secret passing through the system. Our solution to this was end-to-end encryption. The sender's browser encrypts before anything leaves the device, and the recipient's browser decrypts after retrieval. Our server only ever touches ciphertext that it cannot read. So even if our own infrastructure got compromised, the attacker gets nothing.

Each of these discoveries followed the same pattern - we'd build what felt like a complete privacy model, then stress-test our own assumptions and find the next gap. These challenges forced us to dive deeper into Canton and helped us to arrive at a product that is robust and truly emphasizes privacy.