Hacker News Reader

Comment by m348e912 | Hacker News Reader

Stupid question: If the decryption key is in the URL (which I assume it is), what's the point of decrypting client side?

View on HN

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!

Reply on news.ycombinator.com