Oh, wait, I think Schneier answered that:
Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so.
They are:
1. The contests are generally unfair.
2. The analysis is not controlled.
3. Contest prizes are rarely good incentives.
I'd submit that (1) doesn't count here, because the idea you're demonstrating is so obviously flawed that contestants aren't at any disadvantage. But (2) and (3) are absolutely valid here: there's no structure to the contest (it's a bunch of Hacker News people poking at a page at random with no collaboration, milestones, or test plans), and $1000 buys ~3 hours of cryptanalysis work if you source it from software security people instead of actual cryptographers (who bill north of $450/hr).
I have no idea who you are and so I don't want to sound like I'm offended by what you've posted. But you are like the 100th person to staple SJCL onto a web app and posit that they've created something more secure than a private wiki. Actual professional cryptographers have addressed similar claims in the past. Here's Nate Lawson:
http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
Instead of the brinksmanship of offering a contest, why don't you instead just listen to the arguments people are making and try to learn from them?
Triple bonus points for noting that AES and SHA3 were the products of design contests, after Schneier wrote this, and then observing the differences between those design contests and the one at the top of this thread.
Considering that tptacek is a Matasano researcher, why wouldn't you address the specific issues you have with the article? It doesn't seem filled with platitudes, and it's not self-referential at all, much less self-aggrandizing.
What is self-aggrandizing are people offering crypto snake-oil with bluster and boasts and contests instead of entering into the dialog and state of research. It's a very good thing that the establishment is skeptical and careful about this sort of thing.
The weirdest part is that everyone seems to take this so personally. Sarah Flannery, a teenager at the time, took it better when her crypto algorithm was broken. Her attempt was no slouch either.
Regardless, what do you think of someone who publicly calls something a terribly insecure idea, and then reacts with snark and doesn't actually attempt to crack the system when the opportunity is put before him by someone willing to bend over backwards to help him crack it?
Propose a plan to actually crack the system. Do you want the database? Do you want to control the network where I log in?
Engineering doesn't work that way. Your proposed solution doesn't become more sound simply because you feel aggrieved at the way people react to it.
Also: it's deeply dishonest to suggest that the only reaction you've received to this design is "snark". As I pointed out above, with a link and everything, and as you yourself acknowledged in your original post, you've been given a litany of reasons why your proposed design is flawed. You just don't seem to like hearing them.
Instead, I'm inclined to believe you just can't.
In other words, sometimes, you have to put your money where your mouth is. The OP is doing that. You're not.
I'm attempting to give those who believe that JS crypto should never be used a way to make a clear public demonstration. What better target could you ask for? A web application hacked together in a few hours by someone with no training in computer security who isn't even a professional software engineer and who is willing to arrange scenarios favorable to the attacker.
I'm not aggrieved by the negative reaction. I have no skin in this game. I don't earn anything if people walk away believing this idea is more secure. I just wish you wouldn't keep repeating the same canard about having to bootstrap the crypto on every use while attacking the messenger and the manner in which the message is being delivered.
If you can tell me this English word, I will paypal you $10.
--
Despite no one winning my "contest", my sticky-note encryption system is not particularly secure.
Different systems are secure against different threats. Sticky notes are secure against people who can't get physical access to their location.
The question in this case is what attacks this experiment is secure against.
I've taken the sticky note down. It had the word "contrite"
There were plenty of exploits you could have done, without having local access to my machine. Just one example- If you view my profile, you can determine the company I work for. Use linked/etc to message someone there, and offer to split my generous reward with them, if they tell you the word.
Just because no one took me up on my offer doesn't mean my sticky-note was secure.
Yes, of course it was a silly "contest", but that's the point - Contests like this don't prove anything at all about how strong or weak your solution is.
Those are creative solutions to your contest. I should have been cleverer.
Where are these people that are actually suggesting plausible attacks rather than just mocking the idea of a contest? I don't see them.
Bruce Schneier is not God. stop kissing his butt. ;)
By the way....
"3. Contest Prizes are rarely good incentives..."
meanwhile...
"Our Twofish cryptanalysis contest offers a $10K prize..."
"2. The analysis is not controlled..."
meanwhile....
"..There are no arbitrary definitions of what a winning analysis is...We are simply rewarding the most successful cryptanalysis research result, whatever it may be and however successful it is..."
LMAO...this is from the same article!
"The above three reasons are generalizations. There are exceptions, but they are few and far between. The RSA challenges, both their factoring challenges and their symmetric brute-force challenges, are fair and good contests. These contests are successful not because the prize money is an incentive to factor numbers or build brute-force cracking machines, but because researchers are already interested in factoring and brute-force cracking. The contests simply provide a spotlight for what was already an interesting endeavor. The AES contest, although more a competition than a cryptanalysis contest, is also fair.
Our Twofish cryptanalysis contest offers a $10K prize for the best negative comments on Twofish that aren't written by the authors. There are no arbitrary definitions of what a winning analysis is. There is no ciphertext to break or keys to recover. We are simply rewarding the most successful cryptanalysis research result, whatever it may be and however successful it is (or is not). Again, the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain."
This contest encrypted something with AES, stuck it in a database, attached a web app to it, stapled SJCL to the web app, and then said "decrypt the encrypted data in the database and I'll give you $1000".
Propose a practical attack against this app and I'll help you carry it out.
http://www.matasano.com/articles/javascript-cryptography/
"SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser."
http://www.matasano.com/articles/crypto-challenges/
My problem is with people who don't want to learn crypto, but do want to use it anyways.
There's a stark contrast between someone wanting to learn crypto (and being humble about the process) and someone who's new to crypto but being anything but humble.
I am at a loss.
[1]http://en.wikipedia.org/wiki/RSA_Factoring_Challenge
But just because it has no advantages doesn't mean it won't work. A three wheeled car will still get me from point A to point B.