Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL.
Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant bignum hacks that exploit how binary math works.
If you've got a counter to this, then by all means, I'd like to see it.
"Turing completeness" does not mean "safe environment in which to run cryptography". There are in fact math problems in Javascript environments, but they are far from the worst problems you face there.
Again, you say javascript cryptography is flawed, and then say it's a browser environment problem. Let's break this down.
If the flaw is in how javascript does math, then that's something Autho.me has to deal with and I'd like to know about it.
If however, this is a flaw in browser environment, then all methods that use a browser are equally flawed. That includes OpenID, Oauth, SRP, and your own proposed solution of bcrypt. That's because, once I can exploit the browser environment, then I have access to anything the user submits.
That's the crux of my question: If you say there's an exploit against cryptography because of javascript math then demonstrate it. If you have exploits against the browser environment, then I can't fix those and they apply to your proposed solutions.
Let's take an example: An attacker can inject XSS code onto the login page and get the SRP password. Well, an attacker that can XSS the login page and get the password from your SSL/bcrypt solution. They've got access to the whole page.
So, if you find demos of failed math in javascript I'd like to see those.
Look, I'm just not wading into this. You and I should, as much as possible, avoid arguing; because of our personality types, we're just going to end up at the nerd equivalent of pistols at dawn.
You're telling people to use SSL with this. That is good. With SSL in the mix, my only real issue with AUTHO.ME is that it's a lot of moving parts for (what I think is) minimal value. You think "not having to implement bcrypt or PBKDF2" is major value. Guess what: this point is not worth a huge argument. And it's absolutely not worth a line-by-line evaluation of your crypto code, so I'm just not going to do it.
If you're planning on a doing an indie two-factor auth project, that value may be less minimal. I have no coherent opinion that stuff. Good luck with it. If you do something crazy, I'll call you on it, which is I think what you want.
Ignore Kaminsky, by the way. I can't imagine how using RSA instead of SRP could possibly make this safer, but I can imagine lots of ways in which it could make you much less safe.
Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant bignum hacks that exploit how binary math works.
If you've got a counter to this, then by all means, I'd like to see it.