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.

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.

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

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.

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.

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.