Adds crypt.fyi to Encrypted Messaging

[dillonstreator]

Type

Addition

---

Changes

Adds crypt.fyi to Encrypted Messaging. It is an ephemeral sensitive data sharing platform that offers a range of client interfaces for interacting with the service (web, cli, chrome-extension). It offers a suite of configurations beyond the standard for comparable private pastebins, including max read count, IP/CIDR allow-listing, and webhooks. The project aims to provide the highest standard of privacy, security, and useability/accessibility.

---

Supporting Material

https://github.com/osbytes/crypt.fyi
https://www.crypt.fyi/about
https://www.crypt.fyi/privacy
https://github.com/osbytes/crypt.fyi/blob/main/SPECIFICATION.md

---

Affiliation

I'm the developer of crypt.fyi

---

Checklist

• I have read the Contributing guide, and confirmed my PR aligns with the requirements
• I have performed a self-review (valid Markdown formatting, spelling, and grammar)
• I have indicated whether I have any affiliation with any software / services added
• I agree to follow the repositories Contributor Covenant Code of Conduct

[ltguillaume]

I've been using hemmelig.app for this for a while now, but your option for a webhook is absolutely great.

[dillonstreator]

hemmelig.app looks nice and has good configuration options! I did find a couple of things that give me cause for concern that I've addressed in crypt.fyi

1. Race condition in read & delete operations Race condition in read and delete HemmeligOrg/Hemmelig.app#348. This issue is quite common in lots of existing comparable tools.
2. The plaintext password is sent to the server for comparison. crypt.fyi differs here in that neither the decryption key or password are sent. There is a form of zero-knowledge proof happening wherein the client sends a sha512 hash of the key + password on the create side and the read side also requires a hash to confirm it can properly decrypt the contents. Only when the hash matches does the system release the encrypted secret for client-side decryption.

[ltguillaume]

hemmelig.app looks nice and has good configuration options! I did find a couple of things that give me cause for concern that I've addressed in crypt.fyi

1. Race condition in read & delete operations [Race condition in read and delete HemmeligOrg/Hemmelig.app#348](https://github.com/HemmeligOrg/Hemmelig.app/issues/348). This issue is quite common in lots of existing comparable tools.

Good catch, and it's great you've already opened an issue for that 😃👍

2. The plaintext password is sent to the server for comparison. crypt.fyi differs here in that neither the decryption key or password are sent. There is a form of zero-knowledge proof happening wherein the client sends a sha512 hash of the key + password on the create side and the read side also requires a hash to confirm it can properly decrypt the contents. Only when the hash matches does the system release the secret.

(Disclaimer: I haven't checked your code, so I'm going on how I interpret your explanation above.)
So, when reading a secret, instead of sending the password in plaintext (+TLS) to the server, crypt.fyu lets the client send the same key+password hash that was sent to the server when creatin the secret in order to check whether the secret should be released to the client, right?

I'm just wondering how this hash is then saved in the database, because if that hash is saved in plaintext, you might say you effectively save the second factor in the database as plaintext next to the secret, which - one could argue - would be worse than saving a hash of a password next to the secret, even if that password is actually sent to the server with only TLS.

That said, if my interpretation is correct, it is pretty much only a matter of best practices, because effectively the server-side password/hash check would already be circumvented if the database is compromised, unless the password would be part of the client-side decryption process.

[dillonstreator]

unless the password would be part of the client-side decryption process

The password is also part of the decryption process. The client runs two encryption cycles if a password is provided. First with the randomly generated key and second with the password.

This hash proof is protecting against brute force secret release when a low-entropy password is used. It also prevents the server from ever receiving a password. I see that bcrypt is used by hemmelig.app, so correction is that it's not stored in plain text.

crypt.fyi does store the hash in plain text and I can actually improve on that and apply server side encryption to add an extra layer of security from database compromise. osbytes/crypt.fyi#69

Appreciate you taking an interest!

[ltguillaume]

Great, thanks for the explanation and willingness to take a look at the possible improvement!

While I have some hours into improving Hemmelig.app a bit and will therefore likely keep using it myself when I need to send a secret to others, I do like the fact that your UI is significantly easier for new users, so I'll likely start recommending it to people who need to send me secret info.