this post was submitted on 27 Jan 2025
56 points (95.2% liked)

Privacy

516 readers
223 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!

  1. Be nice and no bigotry/prejudice
  2. No tankies/alt-right fascists
  3. Stay on topic
  4. Don't promote proprietary software
  5. No crypto
  6. If you post news exclusive to a country please name it. ~(This isn't a bannable rule, just a recommendation!)~

Related communities

founded 2 months ago
MODERATORS
fxomt@lemm.ee
fxomt@lemmy.dbzer0.com
otter@lemmy.ca
shaytan@lemmy.dbzer0.com
56
crypt.fyi - Secure Secret Sharing with Zero-Knowledge End-to-End Encryption (crypt.fyi)
submitted 4 days ago by Blaze@lemmy.zip to c/privacy@lemmy.dbzer0.com
22 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
[–] CosmicGiraffe@lemmy.world 1 points 3 days ago (1 children)

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

[–] drspod@lemmy.ml 1 points 3 days ago (1 children)

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.

[–] CosmicGiraffe@lemmy.world 1 points 3 days ago* (last edited 3 days ago)

Sure, but then you've just shifted the problem up a level. Now I have to trust that the user id you provide me in the insecure channel really is you. Which means either trusting the insecure channel or trusting that the web app has confirmed who you are in some other way before giving you an ID.

We have to reject the first since we could skip all the asymmetric crypt and just send a symmetric key directly in the insecure channel.

If we're trusting the web app has confirmed your identity, we've moved from "just quickly go to this page and it'll generate you a public key" to "go to this site, upload a photo of your ID and a video of you saying that its you and whatever other verification is needed, then it'll give you a public key".

You originally wrote:

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?

The hard part isn't them going to the site in advance, it's them establishing trust with the site that they are who they claim to be.