41–50 of 75 posts
Earlier quoted context omitted.
So what happens when Zerobin or SnipURL is ordered to take down "all posts from the same client IP address as the post with the shortened URL of ..."?
Don't log IPs? End user IP's are mostly dynamic anyway.
Projects like this scare me considering the issues PasteBin has in regards to sensitive data being shared illegally; and that was without encryption. I'm foreseeing legal hiccups and requirements for policing the content.
- Host such data off of a server bought with a stolen credit card and accessed via anonymous proxies.
- Use any of the normal pastebin sides out there with offline encryption methods. (E.g. use PGP + copy/paste encrypted text into browser)
- Host such data off of a hacked server.
I don't really see how ZeroBin is scary. You could even do something like this: https://dgl.cx/wikipedia-dns with a hacked domain account + a hacked server. I'm sure the amount of traffic could be small enough for the hack to remain hidden for a long time.
It's not really true that (due to the data being encrypted client side) your data is safe even if someone were to gain control of the server. It's something often claimed by these "Host Proof" style services. As long as you are downloading the client side code from the server, someone just needs to make a small change to the javascript and they get access to your data. Only if you can trust the code, and then make ce…
Think the tired old "does linking constitute a copyright violation?" question. If someone posts a list of magnet links or torrent URLs to ZeroBin, they can claim plausible deniability: they cannot know the content of the pastes they host.
This reduces to deep questions about internet freedom. For example, if ZeroBin couldn't for some legal reason host "infringing" links, they couldn't host any links, and Tor, I2P, Freenet, and other onion/mix networks would be similarly illegal. Or can it be illegal to participate in an anonymous networks or not? Some parties would like to see the answer to be "yes". But we all know that there's copying bits and there's copying bits: at some point it doesn't matter, at some points bits can't be legal or illegal but just bits.
Technology like ZeroBin can help drive the liability question down to the very, very basics where it can be eventually solved.
Earlier quoted context omitted.
You could save a local copy of the html and javascript to make sure you're using the same code every time. You'd probably have to make a few tiny changes (absolute/relative URLs, etc), though.
Or you could just use PGP.
i made a chatroom implementation on exactly the same principal a few years ago using long polling. the password to the chatroom served as the client-side encryption/decryption key, the encryption algo was AES and a random IV per word. here is the algo i was using for the client-side enc/dec. http://www.myersdaily.org/joseph/javascript/alphac.html
All messages with the same key are XORed with the same stream of data, given more than one message encrypted with the same key that is trivially reversible - see any cryptography text book for details. Your "seed" doesn't help because you include it in the message...
The genius of this is the realization that browsers do not send the named anchor (technically "fragment identifier"[1]) to the server. Using the named anchor as the cryptographic key enables users to pass around simple URLs to encrypted data. Data is stored on the server, but the server never has access to the complete URL with the key, so it cannot decrypt it. As others have pointed out, this doesn't protect the dat…
https://github.com/benadida/sessionlock
http://www2008.org/papers/pdf/p517-adida.pdf
He uses a token in the fragment identifier to authenticate every request; since the fragment identifier never gets sent to the server, a passive attacker never sees it -- it's a nice trick.
i made a chatroom implementation on exactly the same principal a few years ago using long polling. the password to the chatroom served as the client-side encryption/decryption key, the encryption algo was AES and a random IV per word. here is the algo i was using for the client-side enc/dec. http://www.myersdaily.org/joseph/javascript/alphac.html
Sorry dude, your home-brew encryption scheme (not AES) is trivially breakable. All messages with the same key are XORed with the same stream of data, given more than one message encrypted with the same key that is trivially reversible - see any cryptography text book for details. Your "seed" doesn't help because you include it in the message...
the crypto scheme was randomized between 3 algos to reduce the statistical data size for each. one was AES, one was alphacrypt, another one was something else. the json protocol exchanged an algo_id which was stored with each message.
as for home-brew, i used the encrypt/decrypt code i found at the provided location. i'm no crypto expert and the guy claims to have a mathematics PhD with "Eleven years of publishing scientific and technical papers (computer science and higher-level mathematics)", so hopefully his security assertions are not entirely without merit.
the key is not stored anywhere. it must be exchanged by other secure means, just like any symmetric encryption/AES.
if you encrypt "a" using a key "foo" and the lib selects a random seed char to tack onto every word, there can (from what i understand) be 255 variations to encode the same plaintext word...and this set varies for each key.
storing the seed, like storing a salt doesn't seem like it would help much. so it's not immediately obvious that having access to many messages encrypted using the same key would allow you to do any kind of trivial statistical analysis other than on word length alone.
if it is in fact trivially breakable, i would love to see it implemented by simply having access to the encryption code and ciphertext of 5 different messages of several words in length encoded using the same key 100 times each.
it'd be awesome to learn more about crypto....and about 100 other topics, too :)
