It is accepted that the javascript library lacks the ability to create an adequate PRNG. My understanding that this was mainly due to the limits of a sandboxed browser enviroment that javascript resides in.

Is this correct? Can server side javascript generate provably secure cryptography due to system wide access?

1 Answer
1

As far as I know, there's no fundamental obstacle that would prevent you from implementing any crypto algorithm you want in JavaScript, whether on the server or the client side.
Compared to an optimized implementation written in C or assembly, JavaScript implementations of low level crypto primitives like block ciphers or PRNGs are likely to be slow and hard to secure against side channel attacks (although there are ways to do that, especially if you know the CPU and interpreter the code is going to run on), but they'll still work.

The big problem with doing crypto in JavaScript on the client side is that, unless you use a secure channel like HTTPS to deliver the code to the client, you have no guarantee that the code the client receives and runs is the same as the code you sent from the server. And if you do use HTTPS, you might as well just use it to send the data securely to the server, without any need for doing client side JavaScript crypto.

(That said, there are some rare cases where doing crypto even in client side JavaScript might make sense. For instance, in some cases, you might want to require the client to submit a proof of work before requesting an expensive operation from the server in order to guard against denial of service attacks. Alternatively, some expensive crypto operations, such as key stretching, can be safely and usefully offloaded to the client entirely (although you should still hash the client-submitted key with a conventional hash function before using it).

However, in both cases, the slowness of JavaScript crypto implementations provides an unwelcome advantage for attackers, who would presumably not run the actual JavaScript but instead reimplement the algorithm in a faster language. This is one use case where the proposed Web Crypto API might actually be useful, by providing access to fast native crypto primitives from JavaScript.)

In any case, the issues with secure code delivery don't apply to server side JavaScript, since there's no untrusted network over which the code would need to be sent. However, the performance issues with doing low-level crypto operations in JavaScript are certainly still present, unless your server JavaScript interpreter provides some API to let your JavaScript code make use of fast native crypto primitives.