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!

  • drspod@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago
    1. Encrypt

    Your secret is encrypted right in your browser before it ever leaves your device. Only people with the special link, that you’ve explicitly shared, can decrypt it.

    1. Share

    Share the secure link with your intended recipient. The link contains everything needed to decrypt the message, unless a password is specified.

    So you still need to share a secret - the URL - over some other secure channel, otherwise you still risk leaking your secret data. Sure, it’s easier to share a short piece of text than a large file, but this still doesn’t solve the motivating problem that the tool is setting out to solve, namely:

    Why crypt.fyi?

    The Problem with Common Practices

    Every day, sensitive information like passwords, API keys, and private data is shared through insecure channels:

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

    A web-based tool for temporary data sharing like this could make public-key crypto easy for non-technical people by doing all of the key management for the user. “Your key has been generated and stored in your browser. Share this public key with your correspondent and they can send secure messages to you.”

    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?