Privacy

671 readers

156 users here now

Protect your privacy in the digital world

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 nice, civil and no bigotry/prejudice.
No tankies/alt-right fascists. The former can be tolerated but the latter are banned.
Stay on topic.
Don't promote proprietary software.
No crypto, blockchain, etc.
No Xitter links. (only allowed when can't fact check any other way, use xcancel)
If you post news exclusive to a country please name it. ~(This isn't a bannable rule, just a recommendation!)~
If in doubt, read rule 1

Related communities:

founded 3 months ago

MODERATORS

fxomt@lemm.ee

fxomt@lemmy.dbzer0.com

otter@lemmy.ca

shaytan@lemmy.dbzer0.com

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

submitted 1 week ago by Blaze@lemmy.zip to c/privacy@lemmy.dbzer0.com

25 comments fedilink hide all child comments

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!

you are viewing a single comment's thread
view the rest of the comments

[–] Valmond@lemmy.world 1 points 1 week ago* (last edited 1 week ago) (1 children)

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.

[–] codectl@lemmy.zip 2 points 4 days ago (1 children)

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.

[–] Valmond@lemmy.world 1 points 1 day ago

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).