client-side encryption?

[anarcat]

To make this "the best pastebin that ever was or will be" (#62), one thing I think is missing is client-side encryption. I know there's a way to expire pastes, but that still requires trusting the server somehow. It would be nice if, like Up1 or lufi, pb could allow clients to upload opaque blobs that would be rendered with a key stored in the URL anchor (so it's not visible to the server).

The commandline client would also need to be updated, obviously, and this would complicate things quite a bit, but I wonder if this was considered at all.

[buhman]

I wonder if this was considered at all

I've desired this for years.

Somewhat tangential to what you describe, I wrote https://github.com/ptpb/cryptio with the goal that even without client-side participation, the server would be unable to examine the content of any paste.

[anarcat]

I've desired this for years.

I'm really happy to hear that! I was worried this would get closed as a "out of scope, use PGP" or something. :)

I think there's room to keep the current implementation and just fix the clients and the web-visible parts (in pbs?) so that they support client-side encryption. naturally, this means web browsers need to trust the server to send the right software to not sniff the private keys from their URL and so on, but that's what dedicated clients are for.

i'm not sure how cryptio would work on the server though: the key would still need to be stored somewhere. the approach Up1 and Lufi took is to "urlencode" (pardon my PHP) the secret key in the URL fragment (#foo) which is not (supposed to be) sent to the server. is that what you had in mind?

in that case cryptio would be used for the dedicated client and something similar would be used in the webapp for users who can't use the client.

[buhman]

i'm not sure how cryptio would work on the server though

That's why I said "tangential"; it's a separate idea. It's more of a data-privacy thing than a zero-trust thing.

the key would still need to be stored somewhere

Yeah; the server would have (temporary) knowledge of the key, but only while a request is being serviced. As far as storage, the key would become the paste's identifier, and the server-side identifier would be some key derivation of that.

[buhman]

just fix the clients and the web-visible parts (in pbs?)

The "authoritative" client is pbwww; I don't think it's a good idea to build on that (other than maybe to steal the UI, because UI design is the boring/hard part), even though I wrote much of it.