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 certain that the code does not change, is your data truly safe from the host.
Cortesi (http://corte.si) has done some interesting writing on the subject. http://corte.si/posts/security/hostproof.html
He implemented a similar service (http://cryp.sr + http://corte.si/posts/security/crypsr.html ), and also worked on creating a browser addon that would verify a webpage against a known hash (https://github.com/cortesi/apphash).
Here are a couple of HN submissions on cryp.sr which have some discussions on the "Host Proof" concept:
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.
>Won't protect against Man-in-the-middle attacks (eg. javascript substitution)
I think it is pretty much the case that anything that works as man-in-the-middle will also work if an endpoint is compromised.
As others have pointed out, this doesn't protect the data from a compromised server, but I think it has a different motivation.
It appears the purpose of this is to reduce the liability of whoever is running the server. Perfect for magnet links and such.
This is another step in the right direction of protecting the web and its maintainers from legislation.
[1] http://www.w3.org/TR/html401/intro/intro.html#fragment-uri
PasteBin itself is a DMCA notice magnet already for some very litigious people, as I know from having read through more public DMCA notices than most people would bother reading through. So if you're worried about legal liability, consult a lawyer to make sure that your technical solution would actually help you in court.
There's something called "willful blindness" that you might want to understand if you plan to run a PasteBin clone where people could be expected to post magnet links to pirate content. You could also do worse than to have a lawyer explain your DMCA obligations to you, too. If people start posting pirated stuff to your site, you're going to want to be very clear about them, lest you find out that you technically don't have DMCA safe harbor because you flubbed one of the requirements.
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.
They allow you to shorten the URL by using another service. But now snipurl.com has your URL fragment and can read your stuff!
Imagine a world where SOPA had passed, and everyone who ran a website was legally responsible for everything that their users did.
In that scenario, one way for website operators to protect themselves is to make it impossible to know what their users are doing.
The 3rd party URL shorting service is not storing or associated with the encrypted data and is also not responsible for it.
So this may not be about private data so much as it is about protecting the freedom of information.
See the section "When opening a ZeroBin URL: "
the "pasting" and "opening" sections cover this
here is the algo i was using for the client-side enc/dec.
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 :)
"The key is never transmitted to the server, which therefore cannot decrypt data."
but it does seem like the resulting queries could be stored in the servers logs, as the key needs to be part of the request? edit: no it doesn't, I needed to read more :) the key is the anchor part of the URL. neat!
Cool trick though.
Needs an alternative way of unlocking. A short link and then a passphrase generating key.
- 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.
More importantly, I noticed another query before it: GET /qsml.aspx?query=http%3A%2F%2Fsebsauvage.net%2Fpaste%2F%3F9f9ee11adc3a2093%2312WGK1zDE5Nqpz8mwVa%2BA%2BQQ8%2F12zJqHb5935uRvWdw
Bing was searching for my link on the internet in case it wasn't a URL. Knowing this, couldn't someone demand Google give them someone's search history to sebsauvage.net; and, if whole URIs are returned, the anchor tag will also be provided?
This doesn't seem completely private. The webserver may not know what's in your text; but your search providers will; or will have the knowledge to be able to.
1) The encryption and decryption features do not provide data confidentiality to users because the encryption/decryption environment is not controlled by the end users. The host retains complete control over the algorithms used and the input and handling of keys and plaintext. Users would need to verify that the client-side environment is safe to use on every single page load.
2) The host will still be legally required to block access to encrypted messages once someone sends them a URL containing the key. Furthermore, the host will still be liable to produce log files identifying users. Extensive case law exists in multiple countries to support these two statements.
Similar comments were made in the HN discussion of CrypTweet[1].
When you post new content to your friend list, your client uses your private key & your friends' public keys to post a separate encrypted copy of the content for each friend. Thus only they (and you) can read the content.
Note before people point out all the flaws in this idea =)... I'm aware that this would have problems on the key management side of things, plus one-encrypted-post-per-friend would get computationally (and bandwidth) intensive as your friend list (or "circle") increased in size. I'm also not convinced people actually want this - Facebook has made it abundantly clear that most people don't care about online privacy.
I would use it, though!
It really is true that if you have an idea there is already someone also working on it. I have been putting together something very similar and I'm just days away from launching it. I just set up the server last night. I will have to get it up ASAP now. Fortunately its a little different to this but built on a very similar concept.
Shouldn't a wrong key decrypt the text to just unreadable garbage?
Imma gonna clear all my caches and de-bank my cash. Imma gonna get a plane ticket to the Isle of San Mosh. Imma gonna get away from The Man, away from all this tosh.
Imma gonna paste my data where nobody can see. Imma gonna paste my data where it can be truly free. Imma gonna paste my data in grandma's apple tree.
I continue to read unprofessional things like that in the startup environment. I'd say leave the humor to your customers. Just my opinion. People always talk about "scaling". A phrase like that does not.
