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").
this post was submitted on 27 Jan 2025
59 points (96.8% liked)
Privacy
3398 readers
396 users here now
Welcome! This is a community for all those who are interested in protecting their privacy.
Rules
PS: Don't be a smartass and try to game the system, we'll know if you're breaking the rules when we see it!
- Be civil and no prejudice
- Don't promote big-tech software
- No apathy and defeatism for privacy (i.e. "They already have my data, why bother?")
- No reposting of news that was already posted
- No crypto, blockchain, NFTs
- No Xitter links (if absolutely necessary, use xcancel)
Related communities:
Some of these are only vaguely related, but great communities.
- !opensource@programming.dev
- !selfhosting@slrpnk.net / !selfhosted@lemmy.world
- !piracy@lemmy.dbzer0.com
- !drm@lemmy.dbzer0.com
founded 8 months ago
MODERATORS
The devil's in the protocols.
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?
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!
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 :-)
Tried already: https://reddit.com/comments/1iarxev/comment/m9f5zmq
Cool, smart move!
I hope he does, I have my own secure sharing protocol so it would be wonderful to discuss a bit!
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.
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.
Thanks for the explanation!
Yeah, you could let the user encrypt the sensitive data with "your" public key for example (or use ssh I guess). For sharing keys, that's more complicated of course, especially if the person that is going to get the key doesn't know it will get the key beforehand (or the key can be encrypted with their shared public key).