
Multi-core cryptography for Node.js - jorangreef
https://github.com/nodejs/node/issues/678#issuecomment-269466849
======
zbentley
> Seriously, we really need to ensure together that Node can competently
> handle concurrent multi-core HMAC on 4GB files, or it's pretty quickly going
> to fade into irrelevance.

I am getting really tired of the tendency of engineers to do this: take an
argument that "technology X should behave like Y", get some pushback/criticism
about it, and then extremitize that argument to "if technology X does not
support _this one specific use case_ which requires it to behave like Y,
technology X is _completely useless_ ".

Like, I think I come down towards your side on making sensible heruistics for
when to offload CPU-intensive work to other available hardware. I can see a
lot of potential drawbacks (implementation-wise and operationally), but it
would be a useful capability to have. But falling back to "Node will become
irrelevant if you don't do this!" when people don't want to incorporate the
library he built into core is both rude and not constructive.

~~~
jorangreef
I purposefully tried to make the comment constructive and inclusive, hence the
"we" and "together".

Hashing 4GB files may roll some eyes but I don't think it's helpful for Node
to be shying away from it or dismissing it out of hand. I don't think that's a
positive attitude for Node to have as a community going forward. Stress tests
like this should only improve Node. What's there to lose? We should be saying
"4GB, bring it on!"

Positively speaking, there's so much more we could be doing that we're not. We
should be pushing the multi-core data plane side of Node far more than we are.
There's so much potential for SIMD etc. in many APIs. Node is C++ under the
hood after all. Javascript is just the control plane, not the data plane. And
I actually do think Node has been lagging slightly in the performance
department, and I don't mind if people call that out. This issue in particular
has been open since 2012 (going back to the archives).

Lastly, my intention is definitely not to incorporate crypto-async into core.
Core crypto has a completely different streaming crypto api. crypto-async was
designed more as a stopgap for us at Ronomon in the meantime, but also as a
proof-of-concept, to get the ball rolling and show people that the issue was
worth pursuing.

So I stand by the remark and hope the issue will be a catalyst and wake-up
call. Node has had some spectacular success but there's alot of work still to
be done.

~~~
synthmeat
A lot of pushback is just a kneejerk, but a lot of it is also by people who
have a really good mental model how Node works. Changing models is hard and
takes time.

Personally, I'm all for "multi-core data plane", but done responsibly with
future design in mind and over a longer period of time. Great that
conversation is happening.

------
mahemm
Something that scares me here--where is the awareness of emergent security
errors arising from multi-threaded cryptography?

As an example, consider a multithreaded streaming crypto API which consumes a
symmetrically-encrypted data stream with an HMAC at the end. If multiple
threads are simultaneously decrypting this stream, then how do they
synchronize and verify their respective HMACs (let alone one shared one)?
Frequently, in my experience, the answer is never--they just pass results
blindly to an application thread which then operates on this data. By the time
some last thread has belatedly realized that the entire stream was forged,the
attacker has already been able to force the application to run malicious code.

------
doomslice
Everything in the comment chain from the node core devs seemed very
reasonable. Add async crypto support as an option, investigate further whether
async crypto should be the default by looking at performance numbers from
real-world apps that are using it.

Not exactly sure what the issue is beyond that progress is going pretty slow,
but no one has actually submitted a PR for it yet so you'd be arguing for
priorities instead of whether they want to support it at all.

------
edf13
Some very impressive and practical performance gains... Main repo for the
project with further details:

[https://github.com/ronomon/crypto-
async#performance](https://github.com/ronomon/crypto-async#performance)

~~~
lioeters
Thanks for the link!

"While crypto-async is a fraction slower per call than crypto (possibly
because of the overhead of interacting with the threadpool), for buffers
larger than 1024 bytes it shines and provides N-cores more throughput. crypto-
async achieves up to __3x more throughput __. "

------
discussedbefore
Microsoft's Bing group customized Node.js for CPU-bound tasks:
[https://github.com/Microsoft/napajs/wiki/Why-
Napa.js](https://github.com/Microsoft/napajs/wiki/Why-Napa.js)

Napa.js: A multi-threaded JavaScript runtime
[https://news.ycombinator.com/item?id=15498219](https://news.ycombinator.com/item?id=15498219)
(Nov 2017)

Their deal-breaker against using node-cluster was a need to use shared memory
for IPC.

------
IloveHN84
Imagine if using CUDA/C++ with OpenMP for crypto!

~~~
kbumsik
I doubt we could benefit much from that. That approach would significantly
increase latency because of PCI overhead. As mentioned in the OP, most crypto
operations are small chunks of data.

