I'll just leave this here...

http://www.matasano.com/articles/javascript-cryptography/

(The OP's page has third-party javascript loading onto it (Google Analytics).)

From that page:

Why can't I use TLS/SSL to deliver the Javascript crypto code?

You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.

So, you can deliver the JS to the browser securely!

If you have a secured channel to the server (e.g. SSL), then you can just trust the server to encrypt on that end.

It doesn't matter if you are running server-trusted JS crypto in your browser, or server-encrypted data. Either way, the server is dictating the code/algorithms in use, and could backdoor/subvert the encryption.

This project addresses a different problem. One where you want to have multiple people reading a message at anytime in the future without the need for end to end communication in real time.

Right. Matasano is pointing out that securing communications with JS is basically doomed. But they admit that if you can secure the transmission of the entire contents of the page (HTML, JS, everything), then your JS crypto should be OK. They just can't think of a reason to do that, which obviously you have. :)

edit: sneak points out that you have Google Analytics loading on that page, so your data could be compromised that way - theoretically :)

> But they admit that if you can secure the transmission of the entire contents of the page (HTML, JS, everything), then your JS crypto should be OK

Nope. The server operator can still serve you (perfectly secured over an SSL channel) backdoored javascript crypto code.

Which can be clearly viewed by the community.

Only for that point-in-time. Nothing stopping it from serving backdoored JS _just to your IP_, or _just for five minutes that one time_. Dynamic web app, remember? :)

Most of the issues discussed in this post are addressed in my Blog (http://deadropus.blogspot.com/) with more on the way.

Some feedback on main screen: Instead of explaining a theory (e.g., ' in today's world '), why don't you describe directly what it is

Like:

Store content securely in a Drop

1. Get your URL 2. Store content 3. Set password

-> then you can have a link that explains how it works and why this is super secure.

Thanks for the feedback! I'll set something up like that.

I like the simplicity, but I think you will want to put up some concrete examples on the homepage of what this could be used for. Also I don't think you should put those on a separate page-- they need to be on the homepage so that you engage attention and interest right away.

Great feedback.

Lots of these coming up recently. We launched ours in November: https://onetimesecret.com/

Here's another that opensourced their code last week: http://pwpush.com/

After a user has seen the message and navigates to another site, anyone can use the back button to see the unmasked message. I like it though - maybe you can turn it into something that allows you to pass notes to coworkers at work?

Good catch! I'll work on a solution for that.

When you try to create an empty Drop, you get a weird message like this :

{"iv":"6p7sXVuJe+MR9EcAvSYNxQ","v":1,"iter":1000,"ks":128,"ts":64,"mode":"ccm","adata":"","cipher":"aes","salt":"A+pgCtAsfyQ","ct":"DNsHqh4bMEs"}

That is the encrypted packet representing your message. Once you enter the password, it displays the plain text message.

Somewhat similar, this is a great service for sending passwords or other confidential information:

https://www.thismessagewillselfdestruct.com/

Another alpha using Twitter's Bootstrap without a clear description on what it does isn't too exciting. I wish people spent a little more time polishing ideas before posting on HN.

In your blog post, the period got typo'd into the https: link. While it's not difficult to fix, others might not catch that at first and think that something has gone awry.

Good catch! Thanks!

Anyone who needs to share a message really securely is not going to that via your service, however sincere your promises might be.

I can't really understand what it does. Can you please explain 'like I'm a 6 year old'? :)

It is a secure way to post messages. Anyone can see the posting (which is encrypted) but only someone with the password can actually read the plain text message. The password should be transmitted outside the scope of the site.

So it's only as secure as the method used to transmit the password to the other party?

That is known and outside the scope of the project. So, the idea would be to post a message that one or more people who know the predetermined password could read in a central location.

It's also only as secure as his javascript that you are downloading (from his server) to encrypt the message with.

like secret sender, but less secure? https://secretsenderapp.heroku.com/