New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client-side encryption? #230

Open
anarcat opened this Issue Sep 4, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@anarcat

anarcat commented Sep 4, 2018

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

This comment has been minimized.

Member

buhman commented Sep 5, 2018

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.

@buhman buhman added the enhancement label Sep 5, 2018

@anarcat

This comment has been minimized.

anarcat commented Sep 5, 2018

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

This comment has been minimized.

Member

buhman commented Sep 5, 2018

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

This comment has been minimized.

Member

buhman commented Sep 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment