 Show Posts
|
|
Pages: [1] 2 »
|
@ NRS crypto algo bounty contestants:
Guys, u were talking about splitting the bounty to 4 parts. Did u come to a decision? If u r agree to split the bounty then I won't spend time on speedtests.
Well I wouldn't mind. We all spend a lot of time coding. I guess hoax and gimre don't mind too, but I haven't heard Jaguar's opinion yet. I agree, 25% to everyone will be a fair. |
|
|
|
Please, get latest version, both functions now accept hex-string arguments: crypto_sign(message, secretPhrase) crypto_verify(signature, message, publicKey) |
|
|
|
I am willing to split among those who invested a lot of time as long as the other guys are willing to do the same  . I think it is fair. |
|
|
|
Bounty announcement
100'000 NXT will be paid for working JavaScript code that signs and verifies signatures using NRS algo.
- The licence must allow to use the code in any application
- Sign/verify speed must be not lower than 100 signatures per second on a 1 GHz CPU (1 core)
- All the code must be in a single non-obfuscated well-formatted .js file
- Input/output values must be strings like "8302504e4e57c6c65335289879c6915a273d3aae7bd086058e403fcd2bc18341"
The bounty is valid till the 20th of January, 2014 12:00:00 UTC. The complete code must be published in this thread.
Here is requirement to post code here, so... I've changed base math from long10-based(as in Nxt java sources) to more JS-friendly ( https://github.com/kosta/confidential-publishing/blob/master/js/curve25519/curve25519.js), have optimized them and now my implementation enough fast to met "speed requirement", at least at my computer it require less than 10ms for sign/verify. https://github.com/moadib/nxt_crypto_jsAny feedback would be appreciated. |
|
|
|
We should test everything in same environment  I would be appreciated if Jaguar0625 measure time for my latest version(which use rev22 math with some optimizations). Here are the latest numbers for hoax's code: Javascript needs 3.6ms/getPublicKey
Javascript needs 6.9ms/sign
Javascript needs 7.8ms/verify
Nice job! Thank you |
|
|
|
Hmmm.....you didn't understand what I was trying to say, so here we go again.
You're right. Thank you. I've fixed it and will look at this closer again |
|
|
|
Hmmm...chrome is indeed faster but even on a 3GHz maschine I don't get your results: Javascript needs 12.22ms/getPublicKey
Javascript needs 26.24ms/sign
Javascript needs 21.18ms/verify What am I doing wrong? Hmmm...chrome is indeed faster but even on a 3GHz maschine I don't get your results: Javascript needs 12.22ms/getPublicKey
Javascript needs 26.24ms/sign
Javascript needs 21.18ms/verify What am I doing wrong? Just runned in ff26: 22ms(avg)/sign 16ms(avg)/verify. As i can see it depends on loop count(more loops - better time) and browser wish(sometimes it do everything slower(extensions, synchronization, etc??). We should test everything in same environment I would be appreciated if Jaguar0625 measure time for my latest version(which use rev22 math with some optimizations). @hoax: I don't think your version of is_negative is compatible with the java version, or is it? /* checks if x is "negative", requires reduced input */
function is_negative(x)
{
return x[0] & 0xFF >= 0x80;
}
This check for overflow. Tested on Jaguar0625 tests(generated from Java) and get 100/100 passed, so... You can correct me if i'm wrong. And you can remove in your sources second argument from SHA256_write(m, m.length); it was my copy-paste typo, sorry  |
|
|
|
Thanks to Jaguar0625 for tests. I just runned my latest version(on github) on them, all tests are passed |
|
|
|
Javascript needs 5.5ms/getPublicKey
Javascript needs 12ms/sign
Javascript needs 9.5ms/verify
So, who said that 10ms is impossible? We talk about 1ghz core? But in overall, yes, i was too pessimistic On my pc(core i5 2.67ghz) i now get 7.5ms(avg) for sign and 5.5ms(avg) for verify in Chrome |
|
|
|
What else do you think is not working?
I was wrong But also confused by "It's a normal behavior"(c)CfB |
|
|
|
My js ported directly from this, not from Nxt sources ok, but did you actually test the c++ program? No, compared only with Nxt sources behavior. I'm getting quite terrible results from node.js - last time I checked they were 10 times worse than ones from the browser...
I would appreciate if anyone would share his (her?) results from within the browser
CPU - core i5 2.6ghz Chrome 32beta: crypto_sign - 64ms, crypto_verify - 32ms Node.js: crypto_sign - 88ms, crypto_verify - 44ms Firefox 26: crypto_sign - 80ms, crypto_verify - 60ms Results depends on "how you're measure" them Sometimes browser can be meditative and run JS slowly and i get worst results(~ x2 slower). And if i call this functions in 100x cycle then avg time is better(36ms, 29ms on chrome). |
|
|
|
My js ported directly from this, not from Nxt sources And about "helloworld" false result: CfB said that this is normal behavior :O As i can seen now, https://github.com/rev22/curve255js have nice performance only for one reason: it have simplified math, which can't work with negative numbers. This is reason, why "verify" used this math doesn't work. The only thing not working is the is_negative function, right? Not only, as i can see. |
|
|
|
hoax, did you test the original cpp code? I tried but I got funny results Sources of what? I have a few ideas about how to optimize the long class, but I need to spend time with a profiler first and see where all the time is being spent. Has anyone tried this already?
Look at my repo. I removed from Long all codepathsthat useless for long10 implementation. Also added multiplySmall, which faster when we multiple int64 by 1,2,4,9,19,38,76. Maybe we can optimize further but with loss of readability or insignificantly As i can seen now, https://github.com/rev22/curve255js have nice performance only for one reason: it have simplified math, which can't work with negative numbers. This is reason, why "verify" used this math doesn't work. |
|
|
|
Interesting... And the original Java code also returns false on verifying  Yep, just noticed that. Damn, i spend a lot of time for fixing wrong testcase! Ok, but your verify also return false for: So, let's examine this approach further. |
|
|
|
I think the speed could be improved a lot but it will take time.
What are you replacing the int10 and Long with?
Can you test my latest update? I'm afraid that using Long class for all math isn't good. I think that better use Long only in mul and sqr functions. Then we can remove all unnecessary optimizations from Long class. But fastest approach must forgive about Long class and use only JS-friendly math. I have working(and fast, more faster than latest version on github) sign function, but can't solve problems with verify, so continue my work. |
|
|
|
@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): Test
message: This is a secret message that needs to be signed
secret phrase: This is my very secret phrase
public key: 698168d8669c9310d68101dfcc974ed4ef454692da6f028f68114db5fdcc4f6a
Signing...
Signature: 94956bf3de7cfdedb2562a0eff698fed7f3e54bbf4476fbb23a192ddea04040f68efa5d03c3f9ebec4109401b50433f1df267299d8b1ad2c485046c45e6b38da
Verifying...
verify returned: true
Speed test
Javascript needs 174.5ms/sign
Javascript needs 145.5ms/verify
Finished Edit: Updated speed test result due to bug. Interesting, don't test on Firefox before. I believe that new version, which not use int10&Long can achieve your speed. I'll write here when update sources. |
|
|
|
I don't believe that Sign/verify speed must be not lower than 100 signatures per second on a 1 GHz CPU (1 core) can be achieved. I have working implementation of nrs: https://github.com/moadib/nxt_crypto_jsOn 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 |
|
|
|
Generated code approx 2x faster than my implementation, but not readable. And still not enough fast as required. Dependencies, included in script:
Long class from Google Closure Library (Apache license)
jssha256 by B. Poettering (GNU GPL) Other conditions are met? If GPL license not suitable i can easily change it for another. Used only in crypto_sign and crypto_verify functions. |
|
|
|
|
