4d ago

crypt.fyi - Secure Secret Sharing with Zero-Knowledge End-to-End Encryption

crypt.fyi crypt.fyi - Secure Secret Sharing with Zero-Knowledge End-to-End Encryption

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!

22 comments

Hate to be "that guy," but it's mildly amusing/concerning that both instances of the "crypt.fyi" links in the body text are not secure (i.e. "http" instead of "https").
- Looks like the original post on Reddit took 'crypt.fyi' (the name of the tool and also the domain) and converted it to a link with http protocol.
  
  aint that sus?
- The devil's in the protocols.

Also note that there's OnionShare, too. You don't need a TLS certificate or domain, don't need to port forward and can run it from home safely, routes over Tor so very hard to know you are even sharing something, well known and open source etc.
- This detracts a bit from the convenience factor in that it requires both sender and receiver to download an app as opposed to having access to a browser. It is however much safer as the client is static and versioned so the privacy guarantees are better.
  
  In the same way that having a hammer requires a second tool on-hand when I can otherwise just bang the screws into concrete with my adjustable wrench?

Interesting!
How do I decrypt the data when I download my friends holiday photos he shared with me?
How big can they be, can I share my favourite Judas Priest album with my niece?
This is not a criticism, but was there some specific reason for using GCM?
Good work!
- How do I decrypt the data when I download my friends holiday photos he shared with me?
  They're decrypted automatically in your browser via the key in the URL and additionally a password (assuming one was set when created). Both the key and password are used to encrypt the contents so the key alone is not sufficient to decrypt the contents. Regardless, it happens automatically entirely in your browser without ever sending the key or password to the API server.
  How big can they be, can I share my favourite Judas Priest album with my niece?
  I have the limit set to ~500kb right now. That's after encrypting the contents. How large is your favorite Judas Priest album? Maybe I can uptick to accommodate it haha.
  specific reason for using GCM
  Given the different tradeoffs on performance, security, and implementation complexity, GCM seemed like a reasonable choice. I'm making sure to use the OWASP recommended PBKDF iterations 1 2. I'm also looking into post-quantum options recommended by NIST 1.
  
  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.
- As stated at the beginning of the post, it's not mine, feel free to share your concerns on the author's Github: https://github.com/osbytes/crypt.fyi/issues !
  
  Oh sorry for that!
  Mebbe get the person over here :-)

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.
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?
- 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.
  
  The URL contains the decryption key, so how do you imagine users of cryptfyi share a URL to their recipients?
- Is it too hard to ask normal people to use asymmetric cryptography?
  I can't get them to understand the difference between their email password and their login password.
  It's been three decades now.
- Even if you're using asymmetric cryptography, you still have to trust the insecure channel. If an attacker can replace the URL sent there with their own then they can have the sender encrypt the files with an attacker controlled public key rather than the legitimate one
  
  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.

22 comments