David Bau

It is ridiculous that even in light of the COMODO HTTPS hack, the writer would go as far as to say that SSL/TLS is a better solution.

The writer also ignores that there are potential solutions to many of the problems pointed out:
In case of random number generation, check out seedrandom: http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html
And while it's true that the server may always send "poisoned" JavaScript code, projects that heavily depend on such code, such as Cryptocat, now ship browser plugins that perform integrity checks on the code for you: https://chrome.google.com/webstore/detail/dlafegoljmjdfmhgoeojifolidmllaie

Furthermore, and most importantly, by using SSL/TLS, the data being sent by the browser to the server is encrypted as it passes through the network, but however remains readable by the server when it reaches it. Whereas with client-side JS crypto, the server cannot read the sensitive data. If the writer does not trust the server to send correct JS code, how can he trust it with the sensitive data itself, in plaintext, which is what he is doing by using SSL/TLS? As I mentioned above, there exist browser plugins for a few projects to verify the integrity of the JS crypto they use.

I'll wait for the cryptographers to weigh in; but, it's in Javascript.. already a language that's going to be hard to Do It Right in. (The first third of the code is a BigInteger implementation)

Then, I looked to see if the standard constant-time comparisons were in there to resist timing attacks. No dice there.

So... cool. He put a nice wrapper on JSAES[1], jsSHA2[2] by way of webtoolkit.info[3], RSA and ECC in Javascript by Tom Wu[4], and seedrandom.js by David Bau[5].

But then then says it's "New BSD license"[6] when it should be GPL[7].

I didn't start this comment sound negative. But, I think a few things are important:

* Credit authors.

* Respect their licenses.

* Put a big fucking notice on top of your slick webpage: "FOR DEMONSTRATION PURPOSES ONLY-- NOT REAL CRYPTO"

[1] http://point-at-infinity.org/jsaes/
[2] http://anmar.eu.org/projects/jssha2/
[3] http://www.webtoolkit.info/javascript-sha256.html
[4] http://www-cs-students.stanford.edu/~tjw/jsbn/
[5] http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html
[6] http://code.google.com/p/cryptico/
[7] http://code.google.com/p/cryptico/source/browse/trunk/aes.js

I agree. This is something that XMLSchema got both right and wrong. The XMLSchema basic datatypes [0] are well defined and for the most part fit nicely in host languages. However, they really screwed up with the complex types making it difficult to map onto programming languages for multiple reasons (sequence/choice can't be easily modeled in most programming languages without intermediate types, extension versus restriction, derivation versus substitution groups.) For a good write up of the design philosophy behind XMLBeans, see:

http://davidbau.com/archives/2003/11/14/the_design_of_xmlbeans_part_1.html

[0] http://www.w3.org/TR/xmlschema-2/

Here is pi, written as a number to infinite precision (from http://davidbau.com/archives/2010/03/14/python_pipy_spigot.html ):

def pi_decimal_digits():
q, r, t, j = 1, 180, 60, 2
while True:
u, y = 3*(3*j+1)*(3*j+2), (q*(27*j-12)+5*r)//(5*t)
yield y
q, r, t, j = 10*q*j*(2*j-1), 10*u*(q*(5*j-2)+r-y*t), t*u, j+1

If you mean that pi can't be written as a number to infinite precision using place-value notation (as opposed to a more useful notation like Python) then I agree that only a finite prefix can ever be observed.