Topic: [ANN] Nxt Bounty for working JavaScript code that signs and verifies signatures - page 5. (Read 8451 times)

@hoax: I tried your code. It works. But somehow firefox has timing problems. Running crypto_sign needs about 630ms which is slow but not horrible. But crypto_verify needs more than 11 seconds ?!
Can you tell me why firefox is having trouble?

To compare with my version (i7 CPU 950 3.07GHz):

Edit: Updated speed test result due to bug.

I agree hoax, 10ms is impossible.

I don't believe that
can be achieved.

I have working implementation of nrs: https://github.com/moadib/nxt_crypto_js

On my PC(core i5 2.6ghz) algo took approx 200ms for one signature on Google V8(chrome, nodejs).

I'm also tried compile c++ code to js with emscripten and it give approx 2x faster unreadable file. This is not enough too.

P.S. also i think that other(which not have Google V8) browsers will show worse results

I committed a small test runner tonight that does 10000 adds, multiplies, subtracts, and divides with BigNumber, Long, and Int (as a baseline). These are the results I'm seeing on my dev machine:
(you can run it with this commandline: node longperftest.js)
488.002ms BigNumber
5.058ms Long
0.330ms Int

I think this effectively rules out BigNumber . [Looking at its implementation, it's slow because it supports arbitrarily large numbers by storing them as strings and then converting them to digits to perform operations on them. In addition, it doesn't support the bitwise operations that we need]

I also looked at the goog.math.Long implementation and it seems quite optimized. It is storing the high and low 32-bits in two 32-bit integers and then uses integer math directly. I don't see a lot of potential for optimizations. Unfortunately, JavaScript only natively supports 64-bit floating point numbers, so it's 64-bit integer math will never be as fast as languages that support 64-bit longs natively.

Regarding the slowness of recip, I'm doubtful that we will be able to get it much faster. If the intent is for having this code run in the browser, I think we're stuck. JavaScript servers (like node.js) would probably implement this logic in C/C++.

I haven't yet, but maybe i should do that first. Good idea.

Well I am experimenting with the second possibility, but the Long10 build from Long is very slow. Function recip takes 10ms to compute.
Did you make some timing tests?

I'm still thinking through that. Right now, I've found two possibilities.
- http://jsfromhell.com/classes/bignumber - nice because it would allow us to get rid of the long10 stuff.
- http://docs.closure-library.googlecode.com/git/class_goog_math_Long.html - will allow the code to stay more similar to the original code

I'm leaning towards the second until everything is working and then maybe switching to the first because it would allow us to remove some of the extra long stuff, but I still need to evaluate how intrusive the changes are. If they're equally intrusive, it might make sense sense to just use the first one from the beginning.


Thanks. I suspect there are still a few bugs that need to be investigated.

To be a little more transparent with my process, when I'm doing a bulk conversion of code from one language to another, I like to do it in phases:
(1) Do a bulk conversion so that there the code doesn't have any compiler errors in the new language
(1a) Build a test harness (it should almost certainly fail at this point)
(2) Make more significant changes (e.g. convert JavaScript to use correctly operate on 64-bit values) in a phased approach (so that each major change is a separate check-in)
(3) Bug fix / diff source and target code a lot
(4) If necessary, improve performance refactor.

Right now all I've done is phase 1. There's still a good amount of work remaining, but at least a decent groundwork has been laid.

Jaguar0625
I ran js.core & java.core for a same hash key - the result is different.
You can use java ScriptEngine for mix java & javascript code for testing.

Bump

Fully support this bounty. Need more people to get involved with Nxt

That was fast Jaguar. But tell me: with what data type did you replace the Java long type?

Just to give an update, I went through the Curve25519 class and converted it to valid JavaScript. I tried to minimize the changes (since Java and JavaScript are both C based, there is a lot of commonality between their syntax). So, at this point, the JavaScript isn't optimal, but it should be pretty easy to compare against the source. I think it is important to keep the code similar until we get rid of all bugs and then we can optimize it, if necessary.

I think the next step would be to come up with a small test runner so we can gain some confidence that the port works. My idea would be some basic black box testing where we capture a bunch of inputs and outputs from the known good (Java) implementation and then replay them against the JavaScript implementation. Any differences will pinpoint bugs in the port.

Any other thoughts?

I'd be willing to collaborate and split the bounty if you want.

I also started working!

I am going to work on converting the Curve25519 tonight.
I also created a repository where I'll be pushing changes if anyone else wants to help out: https://github.com/Jaguar0625/JavaScriptNrs.

Thanks!

Creating a new thread for this bounty.