Hacker News Reader

Comment by forty | Hacker News Reader

Doing cryptography in a webapp and saying the server doesn't know the secret doesn't work, as the crypto code comes from the server without any way for the user to check whether it has been tempered with our not.

View on HN

The crypto in this case doesn't come from the server. Nothing goes to the server for encryption. It's actually the browser that's generating the key pair and encrypting and decrypting. This is what makes all of this unique.

See: https://github.com/Corgea/retriever/blob/main/js/crypto.js

Right, but how do we know that https://retriever.corgea.io faithfully returns the code in that GitHub repo? We still have to trust corgea.io.

Totally valid concern!

Retriever.corgea.io is actually hosted on Github pages (do a CNAME check to see).

https://mxtoolbox.com/SuperTool.aspx?action=cname%3aretrieve...

You can see the canonical name is corgea.github.io which is the domain for GitHub pages. But, to counter my own argument, does this really prove that this domain is actually pointing to the OSS repo? No, other than we're not here to lie to anyone, I'm happy to show that updates made to the OSS repo show up on Retriever.

Otherwise, you can totally run Retriever on your machine and have peace of mind :)

Right, so you might as well just skip the public key cryptography, which isn't doing anything in your design. Instead, just rely on TLS, and give each piece of content a UUID. Then you can just promise not to read it, the same way you're promising not to steal keys.

You can look at the code in your browser's debugger. It's not minified, and is actually quite simple. You can also watch the network inspector to see that it's not sending data back to the server.

Performing a cryptographic penetration test every time you (or, behind your back, your browser) loads a page is a problematic strategy for deploying cryptography on the Internet.

I think the previous comment came across as snark, but it's not snarking; it's a genuine suggestion. The thing they're trying to build can work, and find users, without the performative cryptography.

Agreed on continuous code audit issue! This is the non-resolvable problem with browser-based services.

But I think the cryptography is not entirely performative, and your suggestion of a UUID KVS is not the same model.

In Retriever's model, as I understand it, Alice generates the keypair which Bob will use to send data to Alice. Alice sends the pubkey to Bob (via URL) and Bob encrypts and submits. Bob then sends a new URL to Alice to decrypt and read. (Not sure why this second URL exchange is necessary, unless it contains the encrypted data?).

Only the original receiver (and Retriever/page host) can decrypt the data. Neither of the URLs are secrets, although possession of the first URL would allow an attacker to encrypt arbitrary messages for Bob, and maybe that's why Bob waits for Alice to send the second URL.

That said, it's a fun experiment but too awkward for anything but ad hoc secret sharing between strangers with no better comms channels. Which is not something I do.

I'm not sure I follow. What is the degree of assurance the cryptographic version of this web page can provide that a UUID and a database can't? Remember, the web page can itself surreptitiously decrypt anything Alice or Bob encrypt or decrypt.

Zero, unless you host it yourself.

Agreed, not practical but a bit more involved (both simpler and more complicated) than a UUID KVS.

Right but that works just as well to determine that some js that just uses ordinary network-layer security to send some data doesn't steal anything.

> we’re not here to lie to anyone

A sound foundation for managing my secrets

lol

Reply on news.ycombinator.com