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!

  • codectl@lemmy.zipEnglish
    2·
    2 days ago

    Creator of crypt.fyi here! Thank you for pointing out the lack of clarity in the ‘why’ statement. It really should state that sensitive data is shared through insecure channels in plain text. The in plain text part is key, as it leaves the contents indefinitely vulnerable.

    Is it too hard to ask normal people to use asymmetric cryptography?

    Peoples eyes have glazed over at the mere sound of the words ‘asymmetric encryption’. It’s a bit out of touch of a statement to make haha. I believe these individuals still deserve more accessible tools that make them incrementally more secure and maybe it can be a gateway to even more secure/private solutions.

    • drspod@lemmy.ml
      1·
      2 days ago

      The URL contains the decryption key, so how do you imagine users of crypt.fyi share a URL to their recipients?

      • codectl@lemmy.zipEnglish
        1·
        9 hours ago

        It’s expected to be shared via an otherwise insecure channel (email, SMS, etc.). That is where there is a large compromise on convenience. I have a feature that I want to implement that separates the key from the URL so the URL and key can be shared via separate channels https://github.com/osbytes/crypt.fyi/issues/54