[jinseokim]

First of all, this is a cool idea. I always love to see something private and encrypted. But I found some concerns and ideas about your project (and I think you may can fix these):

0. This has XSS vulnerability. If attacker writes down this memo: <script>do_the_evil_things()</script> and passes to people, they might be unknowingly attacked(get tracked by attacker their IP/Browser fingerprint, mine cryptocurrencies for attacker, etc...)

1. This basically works under server-side encryption. When user type their text in the website, it is encrypted with the secret key on your config file and saved on the database. This is only effective when attacker only succeeds to crack the database. Also, you can read the text. I know you won't, but you know, cryptographers don't trust anyone. If you want to mitigate this, you might want to learn about end-to-end encryption. In short: the hash of the private link is the secret key. The browser randomly generate the key and encrypt/decrypt the text. The server only receives/saves the ciphertext.

2. AES-256-CBC is unsafe because it provides confidentiallity and not authenticity.[1] This means the attacker who can only crack the database can edit the ciphertext to pseudo-arbitrary plaintext under certain circumstance without knowing of the key. Also under another circumstance, attacker can use 'Padding oracle attack' to recover the ciphertext. it seems your service is not in this case: Laravel's encryption is AES-256-CBC + MAC, which mitigates this problem. So this is safe, but next time, if you write some crypto-related things without Laravel, you'd better use some high-level library such as libsodium or sjcl.

3. This service uses CloudFlare. Using CloudFlare might be safe on small project because they have rock solid WAF to prevent general attacks. But it may be unsafe for a whistleblower from NSA: when it matters with state-sponsered attackers or law enforcements, CloudFlare can be attacked/warranted. Then it becomes another attack vector.

Again, your service and idea are cool. But you should remember that this area is full of land mines, dragons, and dinosaurs with laser guns.

Welcome to privacy/crypto world!

[1]: https://arxumpathsecurity.com/blog/2019/10/16/cbc-mode-is-ma...

[beingflo]

Your point on cloudflare is something I'm grappling with for an application I'm working on. On one hand I would love the simplicity of something like cloudflare pages or vercel etc. Their preview links on pull requests and automatic deployments would make frontend work very convenient. But on the other hand I have exactly your concerns about warrants. Is there some nice middle ground to avoid completely manual builds and deployment on a VM? Maybe some convenient CI, but this service would also need an ssh key to be able to deploy, so we're in a similar situation again I suppose.

Edit: I spent some time thinking about it and might as well document it here if someone finds it interesting. For context, my application does client side encryption with keys stored only in the browser. The catastrophic case would be if the frontend application is modified to extract those keys. That's why I don't necessarily trust a hosted option (which typically needs control of the SSL certificate as well). Instead I would like to serve the client from a server under my control.

One solution is to use Github Actions and have it automatically deploy via ssh. This doesn't really increase my attack surface, since the code is already at Github anyway. So if this platform is compromised / warranted they could modify my application to their liking.

A second solution would be to use any CI service and restrict the capabilities of the ssh key in the `authorized_keys` to only trigger a fixed command without actually being able to log in. The command would pull the code / image and deploy. This way a compromised key could only be used to trigger a new deployment of authentic code, not inject malicious code.

[gigamick]

This is good! As I said in another post, the reason I posted this here was to get feedback and improve. All of these points are excellent and I will address them and get back to you.

[sandreas]

If you would like to get into client side encryption, you could take a look here:

https://pilabor.com/blog/2021/05/js-gcm-encrypt-dotnet-decry...

Notes:

  - This is symmetric encryption via AES-GCM, but asymmetric should work similar
  - In-browser randomness (for key generation) is somewhat questionable, so try to read more about this topic
  - This is meant as an intro to the topic - real security takes much more, like thinking about secure key storage, backup/recovery keys, etc.

[gigamick]

XSS resolved but happy for you to tell me if it is or isn't!

Appreciate the feedback!