Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
go fix hkdf in JXcore or remove it #488
@yaronyg - shouldn't this be an external / addon instead of being core to JxCore (or NodeJS)? We could still get the native speed if we follow an AddOn approach. I've gone through nodejs add-ons and they're fairly straight-forward, especially with the 'nan' helper. Also, Async support if this is blocking the JS thread really should be there.
Also, what is the use case(s) and where in a codepath / call sequence is this happening? what are the performance targets? I ask as what makes the vNext hkdf method that @mpodwysocki had done not-performant enough to meet "some requirement"?
Is this called 1,000/second or is this something done per session intermittently? If it's 400/ops or 800/ops in the pure JS version, why isn't that enough?
Also, of the variables (see the benchmark code below) what is static per session, server, etc. And what truly needs to be optimized. I ask as the boringssl sync'd here, and the function HKDF
I've updated the gist breaking down each step and the derive is clearly NOT the significant portion of the overall call - all steps up through
With the above results, the big CPU intensive calls are:
today we determined that the benefit of just doing HKDF.derive based upon the updated boringssl implementation is not enough and the hkdf.js implementation is to be used until a later point. Given the primary load is done in the steps prior (computesecret & generatekeys) we'd have to extend even further the native implementation.
At a later date will revisit, and also revisit potentially native addon vs. jxcore - core implementation.