bepasty-server
bepasty-server copied to clipboard
Encrypt files client-side before uploading them to server with JS
Encrypt so server owner/user can't read the file contents.
this is a bit out-of-scope for bepasty-server as this is a server side application. encryption must be done client-side or it is rather pointless.
if you think about providing javascript to the client that encrypts stuff before upload: who wants to trust js code that he just got a second before and that could be different a second later?
maybe this could be an issue for bepasty-client, but that project does not even exist yet.
after discussing with some fellow hacker, I think this feature is useful, due to a slightly different reason.
it's not just that the server owner can't read the content (so encryption protect's the uploader's content), but it also gives the server operator DENIABILITY of knowledge about what files reside on the server (and it's even not just "plausible deniability", he REALLY does have no means to know).
This might solve the potential legal troubles that come with publically operating such a upload site.
some implementation ideas:
- encryption / decryption needs to be done clientside, e.g. using AES
- metadata AND data gets encrypted
- only the client has the key, the server won't ever see it (see previous post for 2 good reasons)
- the uploader transmits the pastebin url and the key to whoever needs to get and decrypt the content
- maybe the key could be in the "fragment" part of the URL, like
https://server/<storageid>#key
- so the client will have the url and key in one convenient piece but won't transmit the key to the server
clientside en/decryption code:
- If our focus is just on deniability (and not so much on protection of the content) we could do en/decryption maybe even by some javascript the server provides.
- WE can trust our javascript, thus WE will get the crypto we want for deniability.
- For the user it might be more difficult to trust it, because it's difficult for the user to verify the javascript (could change at any time).
- javascript crypto issues: how to "save" files to disk?
- if we have a commandline bepasty client in python, crypto is easy.
- some metadata that would not be hidden from us: time of upload, size of crypted upload, IP of uploader, ID of storage item
- hidden: data and metadata like filename, content-type, size of decrypted content, hash of decrypted content
if we could do en/decryption rather effortlessly on the client, the user experience of a crypted-only pastebin could be similar to a non-encrypted one. if we get there, we can solve problems by running crypted-only.
I already researched this option. We have to implement this in the fileuploader.js before the file is uploaded.
Displaypage then heavily realies on javascript. Or details are only shown in unencrypted mode.
did you find out how to decrypt a download in the browser before it is saved to disk? maybe without keeping the whole download in memory (-> "streaming mode")?
Currently our javascript is only involved in uploading. Taking the MEGA way would be downloading->decrypting->offering to save
I'll research in that.
use "html5 file api"?
jquery.fileupload.js already uses that: see: o.blob = slice.call(...)
if we get in between there, we could encrypt.
for writing, see there:
http://www.html5rocks.com/en/tutorials/file/filesystem/
https://code.google.com/p/crypto-js/ for js encryption / decryption?
http://sebsauvage.net/wiki/doku.php?id=php:zerobin maybe has some interesting concepts / uses some libs we could use also.
http://matasano.com/articles/javascript-cryptography/ http://tonyarcieri.com/whats-wrong-with-webcrypto
Maybe some issues will be (and some won't be) resolved by the WebCryptoApi.