Share sensitive information securely with zero-knowledge AES-256 end-to-end encryption. Features include burn after reading, password protection, and customizable expiration times.

From an author:

I wanted to share crypt.fyi - a free, open-source tool I built for securely sharing sensitive data/files. It uses client-side encryption and zero-knowledge architecture.

Key features:

- Zero-knowledge architecture
- End-to-end encryption using AES-256-GCM (actively investigating post-quantum encryption options)
- Self-hostable
- Suite of configurations (password, burn after read, max read count, ip/cidr-allow list, webhooks)
- Strict rate-limiting
- Strict CSP to mitigate supply chain attacks
- Web, cli, and chrome-extension clients
- Fully open source (Github)

The problems I aimed to solve: Many people share sensitive info (passwords, keys, etc.) through email, Slack, or SMS - which often leaves plaintext copies in multiple places. Existing solutions either require accounts, aren’t open source, or have security/privacy/ui/ux/feature/config gaps/limitations.

crypt.fyi is built with privacy-first principles:

- No logging of sensitive data
- No analytics or tracking
- Separation of web and api servers
- All encryption/decryption happens client-side using shared cross-platform cryptography primitives from noble cryptography
- TLS encryption for all traffic
- Encrypted data is automatically destroyed after being read with strong guarantees around once-only reads

The entire codebase is open source and available for review. I’d love to get feedback from the privacy community on how to make it even better!

  • @[email protected]
    1•3 days ago

    This is the problem that digital signatures solve.

    The difficulty is not with sharing the URL but with public key distribution, and that’s why in PKI we have keyservers which associate public keys with identities (eg. email address), or certificate authorities that attest the association of identity and public key and establish a chain of trust.

    A web app implementing this would play the role of the keyserver, and users would have some kind of userid that identifies them.

    • @CosmicGiraffe
      1•2 days ago

      Sure, but then you’ve just shifted the problem up a level. Now I have to trust that the user id you provide me in the insecure channel really is you. Which means either trusting the insecure channel or trusting that the web app has confirmed who you are in some other way before giving you an ID.

      We have to reject the first since we could skip all the asymmetric crypt and just send a symmetric key directly in the insecure channel.

      If we’re trusting the web app has confirmed your identity, we’ve moved from “just quickly go to this page and it’ll generate you a public key” to “go to this site, upload a photo of your ID and a video of you saying that its you and whatever other verification is needed, then it’ll give you a public key”.

      You originally wrote:

      The one sticking point is that your recipient needs to visit the site before you can send your vacation photos to them, but is it really that hard?

      The hard part isn’t them going to the site in advance, it’s them establishing trust with the site that they are who they claim to be.