1. That your HTML used to genereate the RSA Key Pair hasn't been intercepted and modified.
2. That sending the public key is equivalent to encrypting the document with the public key.
3. That there's nothing sensitive in the response.
4. That RSA crypto in Javascript is going to be quicker than SSL for either party (encryption client side, decryption server side).
There are other problems I can see but don't really have time to articulate.
Crypto is really, really hard. Fast crypto is harder. Secure, fast crypto is even harder still.
Security in general is really hard too. SSL is the way to go without user changes being required. some sort of crypto-tunnel (SSH, VPN, SSL) is the way to do it client side on an untrusted network.
It was a very naive implementation and it clearly has several faults. Thanks for pointing some of them out. There isn't any solid use case, and we're all better off letting nginx/apache/$SERVER handle the encryption rather than doing it inside the application.
I was just trying to jump on the "Look mommy! Look at what I can do with Javascript and HTML5" bandwagon :)
1. That your HTML used to genereate the RSA Key Pair hasn't been intercepted and modified.
2. That sending the public key is equivalent to encrypting the document with the public key.
3. That there's nothing sensitive in the response.
4. That RSA crypto in Javascript is going to be quicker than SSL for either party (encryption client side, decryption server side).
There are other problems I can see but don't really have time to articulate.
Crypto is really, really hard. Fast crypto is harder. Secure, fast crypto is even harder still.
Security in general is really hard too. SSL is the way to go without user changes being required. some sort of crypto-tunnel (SSH, VPN, SSL) is the way to do it client side on an untrusted network.