3 ms·

calm down and let them have some fun mr. security expert. Bruce Schneier is not God. stop kissing his butt. ;) By the way.... "3. Contest Prizes are rarely g

calm down and let them have some fun mr. security expert. 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."

tptacek 13y ago
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".
- absherwin 13y ago
  No, I've invited you to propose attacks and help you carry them out. Do you want to try to use a malicious network to inject code to steal my password? Find a vulnerability in one of the endpoints to take control of the server? Try to find a cross-site attack? Propose a practical attack against this app and I'll help you carry it out.
  - pfortuny 13y ago
    But the claims about JS crypto deal with the users' security in live settings: they usually are not related to "app" issues but users', which is not the same.
- sinnerswing 13y ago
  So? You guys wrote an article about it... http://www.matasano.com/articles/javascript-cryptography/ 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."
  - tptacek 13y ago
    I'm lost. What are you trying to say here?
    - doe88 13y ago
      I think what is trying to say, is: let peoples learn by their mistakes. I really don't understand your focus on making a kind of witch hunt anytime someone try to learn and implement crypto. It is certainly the responsability of the developer to try not making mistakes but it's also the responsability of the user to know what to expect of what he is going to use. And I think most people on HN are smart enough to consider this kind of post with a grain of salt and not expect too much of it.

tptacek 13y ago

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

absherwin 13y ago
No, I've invited you to propose attacks and help you carry them out. Do you want to try to use a malicious network to inject code to steal my password? Find a vulnerability in one of the endpoints to take control of the server? Try to find a cross-site attack? Propose a practical attack against this app and I'll help you carry it out.
- pfortuny 13y ago
  But the claims about JS crypto deal with the users' security in live settings: they usually are not related to "app" issues but users', which is not the same.
sinnerswing 13y ago
So? You guys wrote an article about it... http://www.matasano.com/articles/javascript-cryptography/ 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."
- tptacek 13y ago
  I'm lost. What are you trying to say here?
  - doe88 13y ago
    I think what is trying to say, is: let peoples learn by their mistakes. I really don't understand your focus on making a kind of witch hunt anytime someone try to learn and implement crypto. It is certainly the responsability of the developer to try not making mistakes but it's also the responsability of the user to know what to expect of what he is going to use. And I think most people on HN are smart enough to consider this kind of post with a grain of salt and not expect too much of it.