TW

Note: I fixed #147 which fixes the +list issue. This issue (that bepasty-cli creates such broken items) is a separate issue and not fixed yet.

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...

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...

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...

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")?

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.

IIRC, the bepasty-server code currently assumes that a cookie-based session is established. For a interactive, browser-based session, this is fine. For automated stuff, you could have a look at how...