Hacker News new | ask | show | jobs
by m348e912 965 days ago
Stupid question: If the decryption key is in the URL (which I assume it is), what's the point of decrypting client side?
1 comments

The whole URL with the decryption key gets sent to the user one time when it’s generated. The key is tacked on at the end after a “#” symbol like you would see in a bookmark. It’s not used by the app as a bookmark, but the value is still accessible in the browser (window.location.hash). This way, I can send users their links and their decryption keys, but I will never be able to access the keys myself.
Right, but your server logs should see the full request (and the keys), no?
I just see these in my server logs when someone generates a link:

INFO: [cloudflare ip]:47174 - "POST /generate_link HTTP/1.1" 200 OK

So you don't also see "GET /e47b07057738525b2f77fab1ef3197cac1b27e7672ea1a49bc5ae4f87eb19e8c/73a3257c89dbef144434269df702364eb0422554c508b6433266b4e65d07b344#p3d3pLH7ND2cr6EJztGmQosfPZdItxE_FQ5zCsGZ5bM=/ HTTP/1.1" 200 OK?

(That would be a test message I created a link for)

No, anything including and after the # is not seen by the server. Here is a screenshot from Fly that shows what it looks like from my end: https://imgur.com/a/41XxtHJ

If someone were to go to just the /sha256/sha256 link without the encryption key bookmark appended to it, they would see: Decryption failed: ChaCha20Poly1305 key must be 32 bytes.

Or with a wrong key they would see: Decryption failed:

Ah clever, that's the part I was missing. Cool idea and implementation. Thanks!