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!
Edit: Hi & welcome! Nice to come by and discuss these kind of things!
How is the key circulated? Over RSA or something? Or do you have to send the link+key somehow to the recipient?
Yeah GCM is nice with the inbuilt authentication. AES 256 I guess?
NIST is aaaabout to chose an algo, right? I dug deep down in all that quantum stuff like a year ago, but it didn’t seem like they’d chosen Rivests algo just yet ^^
BTW is the GCM adding a lot of space? I’m on AES CTR (which just aligns to the block size) + RSA for authentication.
The key is transmitted in a URL query parameter. I’m planning to optionally have it transmitted separately from the URL but ultimately, the decryption key would be transmitted via otherwise insecure / normal means. This is where the understandable and healthy critique around the security/privacy of the tool stems. I shared with another user that this tool is an incremental step in the direction of more secure and ephemeral transmission of data with convenience and accessibility as a core tenant of the tools existence. Yup it is AES 256 and I believe NIST has finalized post-quantum recommendations. I’ll likely be using ML-KEM which increases the resulting data size considerably but is also considerably faster.