…is safe or can people forge…
In contrast to the accepted answer, I would not call it “safe” from a cryptographic point of view and I would definitely not say that “ if you take good care of securing your environment where you run the JS code you will be OK. ” because the sad fact is: that’s not enough to ensure cryptographic “safety”.
We present the first micro-architectural side-channel attack which runs entirely in the browser. In contrast to other works in this genre, this attack does not require the attacker to install any software on the victim's machine -- to facilitate the attack, the victim needs only to browse to an untrusted webpage with attacker-controlled content. This makes the attack model highly scalable and extremely relevant and practical to today's web, especially since most desktop browsers currently accessing the Internet are vulnerable to this attack.
Our attack, which is an extension of the last-level cache attacks of Yarom et al., allows a remote adversary recover information belonging to other processes, other users and even other virtual machines running on the same physical host as the victim web browser. We describe the fundamentals behind our attack, evaluate its performance using a high bandwidth covert channel and finally use it to construct a system-wide mouse/network activity logger. Defending against this attack is possible, but the required countermeasures can exact an impractical cost on other benign uses of the web browser and of the computer.
Read that again: “recover information belonging to other processes, other users and even other virtual machines”. Now, guess how safe your signatures will be from that attack angle.
Besides the dangers mentioned in my answer, I‘ld like to point to a few things others already stated:
- Comments (1, 2) by CodesInChaos:
Are you using HTTPS? Without HTTPS a webapplication has no hope of being secure. … It still matters if your website was loaded over SSL (i.e. uses HTTPS) and if the web sockets run over SSL.
- Comment (1) by Hunter:
- Comments (1, 2) by dlongley:
Keep in mind that server has complete access to the users' private keys in the system you describe (and they should know that if it may affect their privacy). … if the private key can be accessed via JS, then the server can access it (and could, for example, send it to the server). The user must trust that the server won't do so, but it is technically possible. Users should know this if it affects their privacy (they shouldn't export and use the private keys in other systems, for instance).
- Answer (1) by Ninveh:
… and we don't know how well the guy who wrote and modified the code behaved. Some critical security routines there were modified by him, and this should ring a big red alarm bell over its usage. If you plan to use it for anything important, you need to pass the published code through a critical security/cryptographic review before usage.
- Comment (1) by C1D – the person that asked the question:
The client stores the private key not the server. My protocol will provide an official open source client but theoretically if a user enters his password into a rouge client it could steal it.
That somewhat summarizes the most obvious safety issues related to the questioned scenario.