Lots of signing in on the web is still done by sending unencrypted passwords over the wire (or worse: over the air). It's not that all those web developers are just too lazy or incompetent to use TLS, it's the history of SSL/TLS and the current state of things. The inventors of SSL can perhaps be forgiven for assuming one-domain=one-IP, for not anticipating mass name-based virtual hosting. A little less forgivable is not including the server name as part of the clientHello in the original spec for the TLS handshake in 1999. As a result of this history we find ourselves at least temporarily with unreliable support for SNI. Even Apache only started supporting it in version 2.2.12 (2009?), and only Chrome supports it on Windows XP (just one more good reason for all remaining XP users to get Chrome). What this means is that anyone on a name-based virtual-host server can be diligent about setting up a certificate, but when a user attempts to connect to their website using "https://" chances are, because of a lack of implementation in the user's browser or a lack of implementation in the web server, the user will see an ugly warning, and if that connection is made with AJAX, the connection will just silently fail. This de-facto requirement that a secure connection have a dedicated IP address has been an enormous contributor to IPv4 address exhaustion.
So here's a Google-closure-compiler-advanced-optimized slightly-altered adaptation of Tom Wu's RSA encrypter, wrapped in an anonymous self-invoking function to avoid the almost inevitable name collisions that multiple compiled scripts might entail, and to make closure-compiler's 211 "dangerous use of the global this object" warnings moot. It introduces into global scope only
RSAKey and two
RSAKey.setPublic(n,e), which sets the
RSAKey public key, and
var rsa = new RSAKey();
rsa.setPublic(n,e); //modulus, public exponent as hex strings