Regarding 10M thingy, what do you think about using one of Secret Sharing schemes?
There are schemes, that allow dividing the secret into ROLES, i.e. BCNext would be general, and let's say 18 soldiers.
To "vote" (make transfer) there would be needed vote of general and k out of n soldiers.
General is not able to do generate Shared Secret by himself.
If there would be conspiracy of soldiers, they wouldn't be able to retrieve Shared Secret without general.
a general with VETO power? yups exactly |
|
|
|
|
Regarding 10M thingy, what do you think about using one of Secret Sharing schemes?
There are schemes, that allow dividing the secret into ROLES, i.e. BCNext would be general, and let's say 18 soldiers.
To "vote" (make transfer) there would be needed vote of general and k out of n soldiers.
General is not able to do generate Shared Secret by himself.
If there would be conspiracy of soldiers, they wouldn't be able to retrieve Shared Secret without general.
|
|
|
|
Could I kindly ask you to run test also on my code?
Are the inputs and outputs of all of your functions byte arrays? almost, was it specified anywhere how input output should look like? take a look at github, there's description of input output there. |
|
|
|
Bad idea. REALLY BAD IDEA to change the client software and hard-define transaction rules inside the client. Am i alone who think so?
Idea itself is okay - allow people to decide. But the execution is not the best I'd say. If there ever be alternative server, It'll have to copy such quirks. The more such quirks, the uglier it gets. |
|
|
|
Is anyone here running nxtcrypto forums? If so can I somehow "reset my password"?
I don't see link anywhere. I once found an contact e-mail somewhere, but my question was left without an answer.
The same. Sent the letter 3 days ago. Account I was sending an e-mail was fnxtcrypto at gmail. I've somehow stumbled upon it somewhere... |
|
|
|
|
Is anyone here running nxtcrypto forums? If so can I somehow "reset my password"?
I don't see link anywhere. I once found an contact e-mail somewhere, but my question was left without an answer.
|
|
|
|
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! Could I kindly ask you to run test also on my code? |
|
|
|
Something told me, to do tests on Jaguar's test set, and glad I did, cause I've found small bug in my implementation. Here's my code, https://github.com/gimer/curve25519nxtinside testing.js there are some simple tests along with Jaguar's tests. It's based on objects rather than modules. I doubt it'll beat hoax implementation though. Here are some numbers, from my machine. testCurveKeygen: 764.000ms
testCurveSign: 0.000ms
testCurveVerify: 1200.000ms
testCryptoKey: 703.000ms
testCryptoSign: 1498.000ms (~~ 15ms/sign)
Oh, PS, also api is a bit strange, I'd find it more covenient if everything passed to JS would be wrapped in typed arrays already. |
|
|
|
My new results, I forgot to turn off miner when doing previous tests  chrom-opera: curveSelfTest : ok
sign time: 25.000ms
verify time: 16.000ms
sign+verify time: 41.000ms
verified? true
doing 20 signs
sigs20: 396.000ms
doing 20 verifies
verify20: 307.000ms
true,true,true,true,true,true,true,true,false,true,true,true,true,false,true,true,true,false,true,false
chrome: curveSelfTest : ok
sign time: 25.000ms
verify time: 16.000ms
sign+verify time: 41.000ms
verified? true
doing 20 signs
sigs20: 396.000ms
doing 20 verifies
verify20: 307.000ms
true,true,true,true,true,true,true,true,false,true,true,true,true,false,true,true,true,false,true,false
I don't think I'll get to anything better than that... Also on what data do you operate inside functions? As I find requirement, to take input as "hex strings" quite ugly. P.S. My sign looks more or less like this: function crypto_sign(privKey, messageHash)
{
var pubAndS = this.c.genPubWithS(privKey);
var sess = pubAndS.s;
var x = SHA256(...);
var Y = this.c.genPub(x).key;
var h = SHA256(...);
var vh = this.c.sign(h, x, sess);
return {sig: vh, key: pubAndS.key};
}
|
|
|
|
@gimre: On what kind of cpu r u testing, gimre?
laptop, i7, 2.2G @Jaguar0625: 9.8ms/getPublicKey with javascript?
Yes, but don't worry, I ran your code too and it was faster . These are the results for your code on my machine (i am using the test js/html from your repo): Javascript needs 5.5ms/getPublicKey
Javascript needs 12ms/sign
Javascript needs 9.5ms/verify
I suspect you're seeing slower numbers on your machine because you're testing in FireFox. AFAIK, Chrome has a faster JavaScript interpreter. WOW, these look incredible! |
|
|
|
I would appreciate if anyone would share his (her?) results from within the browser
I am not speed testing the bare Curve25519 functions but the getPublicKey, sign and verify function from Cryto class (converted to javascript). On my i7 950 3.07GHz (you need to tell us what cpu u r using) using firefox v26 I get: Speed test
Javascript needs 21.66ms/getPublicKey
Javascript needs 46.92ms/sign
Javascript needs 39.34ms/verify
Finished glad you figured, I also went <100ms for whole sig+verify, will post details later (the thing is I operate on data in bit different format, so I'll have to preprocess it first... and that'll have penalty for sure) |
|
|
|
The visible public account number (your public key) is a maximum of 20 digits, 64 bits, long (10 as in decimal). Anyone heard of the "birth day attack" ? For you who have not, http://en.wikipedia.org/wiki/Birthday_attack. I hope everyone here ;p I guess it is not my "birthday", (after some hinting) and i am not going too have my small investment stolen by some 16 year old script kiddie. Therefore, im creating my own cryptocurrency, whos with me? It's been repeated hundred of times already, your account is your PK, which is 256bits, once you do first trasaction, you're safe. |
|
|
|
Actually, there might be a bug in the C++ code. I compiled it and ran a few tests with sign, but the signature that gets generated is different each time i run the program (typically the sign of an uninitialized variable somewhere). The problem appears to happen somewhere in divmod.
It's a normal behavior, not a bug, don't waste too much time on that. That depends on algo. In case of Nxt's EC-KCDSA "k" value is picked not choosen randomly, So if you feed it with the same data, sig should be te same... (k is calculated from 1360-1365, that's Y in NXT code https://bitbucket.org/JeanLucPicard/nxt-public/src/4073c21098076d3469b3f74d49e73ffabe3a2001/Nxt.java?at=master#cl-1360and it's based on "sig priv key" (s based on user's pub key) and message ) |
|
|
|
My code is finally working uff, took me a lot to figure out how to do that is_negative crap in my representation.
So what's the logic behind is_negative? I've actually partially* answered to that in code flaws thread: Can you please ask that guy what the reasoning behind the strange is_negative(long10 x) function is? It's kind of hard to understand.
I'm also interested in this. a) why there is is_overflow at all... (I thought it'd be simpler to have element of long10 have always reduced mod q....) b) the second part is magic, as there shouldn't be something like "negative", so I assume job of that xor is to split values into two groups... (why?) (edit: added is_negative, snippet) /* checks if x is "negative", requires reduced input */
private static final int is_negative(long10 x) {
return (int)(((is_overflow(x) || (x._9 < 0))?1:0) ^ (x._0 & 1));
}
I might shed some more light upon that, but probably not today (UTC) edit:Oh, P.S. 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 |
|
|
|
Why the "getBaseTarget" is recalculated each time for the same (last) block? For simplicity?
Yes. This is a reference code. also it costs almost 0, and it's easier just to recalculate it, than cache it somewhere (you'd have to place it everywhere where lastBlock is altered) |
|
|
|
Are you saying that you can't verify 25% of signatures? Isn't that a pretty serious issue?
It was already reported. Where? What am I missing? Why isn't this a big deal? there's uber hack for this: sign; while( cannot verify) { change timestamp; sign again } |
|
|
|
|
I think 25% is probably overestimate, but curve edit (I mean curve25519 ofc) as a function is not surjective, so one should expect that...
|
|
|
|
My code is finally working uff, took me a lot to figure out how to do that is_negative crap in my representation. My current times: priv in: 210, 196, 255, 153, 6, 54, 138, 84, 232, 24, 222, 198, 233, 178, 192, 61, 46, 110, 249, 92, 37, 250, 62, 206, 16, 71, 242, 136, 153, 234, 194, 151,
genPubWithS: 58.000ms
pub: 18, 173, 235, 164, 40, 128, 113, 104, 72, 242, 216, 5, 56, 18, 81, 45, 182, 177, 242, 122, 147, 174, 222, 226, 103, 224, 136, 35, 255, 173, 112, 52,
sess: 74, 142, 86, 157, 36, 54, 116, 31, 195, 152, 94, 81, 151, 234, 6, 58, 52, 159, 55, 156, 194, 136, 214, 121, 86, 234, 144, 80, 73, 255, 6, 14,
msghash: 224, 94, 33, 147, 82, 148, 111, 121, 162, 115, 175, 49, 25, 9, 193, 102, 90, 114, 177, 246, 58, 178, 213, 252, 205, 21, 160, 52, 210, 239, 202, 17,
genPub: 30.000ms
x: 56, 202, 26, 238, 143, 109, 13, 46, 68, 242, 230, 144, 117, 26, 35, 82, 185, 104, 189, 171, 185, 231, 219, 160, 226, 15, 25, 173, 12, 47, 149, 72,
Y: 255, 86, 46, 149, 26, 72, 141, 90, 42, 124, 209, 211, 33, 126, 7, 149, 222, 249, 90, 197, 87, 173, 210, 15, 153, 198, 14, 116, 91, 27, 139, 99,
signing:
sha: 77, 170, 60, 190, 71, 254, 202, 56, 39, 211, 119, 32, 153, 190, 64, 97, 46, 28, 8, 115, 115, 149, 16, 121, 182, 69, 186, 159, 37, 229, 120, 65,
sign: 0.000ms
vh[0]: 38, 92, 148, 183, 122, 6, 174, 55, 94, 129, 218, 168, 118, 156, 21, 98, 10, 23, 24, 244, 169, 75, 62, 154, 5, 88, 16, 114, 241, 17, 201, 1,
vh[1]: 77, 170, 60, 190, 71, 254, 202, 56, 39, 211, 119, 32, 153, 190, 64, 97, 46, 28, 8, 115, 115, 149, 16, 121, 182, 69, 186, 159, 37, 229, 120, 65,
verify: 49.000ms
hashing sig: 255, 86, 46, 149, 26, 72, 141, 90, 42, 124, 209, 211, 33, 126, 7, 149, 222, 249, 90, 197, 87, 173, 210, 15, 153, 198, 14, 116, 91, 27, 139, 99,
h_verify: 77, 170, 60, 190, 71, 254, 202, 56, 39, 211, 119, 32, 153, 190, 64, 97, 46, 28, 8, 115, 115, 149, 16, 121, 182, 69, 186, 159, 37, 229, 120, 65,
verification =?= vh[1]:
ALL TIME: 160.000ms
priv in: 212, 215, 120, 183, 50, 2, 38, 73, 6, 176, 105, 222, 132, 202, 18, 161, 165, 186, 129, 60, 222, 69, 25, 30, 201, 220, 102, 201, 246, 118, 112, 127,
genPubWithS: 62.000ms
pub: 223, 120, 104, 231, 254, 142, 4, 197, 103, 120, 80, 42, 121, 163, 172, 175, 112, 183, 92, 53, 174, 174, 106, 175, 52, 132, 33, 254, 147, 202, 189, 89,
sess: 1, 235, 206, 226, 194, 0, 108, 59, 21, 56, 112, 230, 43, 5, 58, 166, 186, 14, 192, 10, 136, 169, 0, 168, 141, 157, 253, 109, 92, 164, 141, 6,
msghash: 224, 94, 33, 147, 82, 148, 111, 121, 162, 115, 175, 49, 25, 9, 193, 102, 90, 114, 177, 246, 58, 178, 213, 252, 205, 21, 160, 52, 210, 239, 202, 17,
genPub: 31.000ms
x: 160, 134, 16, 204, 227, 72, 60, 80, 61, 72, 20, 184, 27, 50, 91, 144, 58, 143, 93, 94, 182, 218, 63, 185, 180, 103, 235, 92, 143, 69, 250, 90,
Y: 25, 68, 99, 3, 220, 120, 0, 254, 135, 235, 145, 49, 33, 175, 178, 51, 85, 109, 83, 123, 79, 242, 47, 246, 21, 239, 130, 81, 185, 235, 67, 122,
signing:
sha: 49, 103, 140, 21, 153, 144, 6, 45, 72, 166, 26, 232, 129, 182, 10, 195, 121, 74, 78, 165, 215, 241, 27, 222, 250, 58, 48, 194, 134, 161, 137, 176,
sign: 1.000ms
vh[0]: 89, 34, 99, 164, 248, 105, 148, 205, 219, 19, 132, 9, 153, 239, 28, 161, 205, 194, 27, 242, 214, 227, 85, 241, 251, 224, 148, 72, 150, 64, 18, 15,
vh[1]: 49, 103, 140, 21, 153, 144, 6, 45, 72, 166, 26, 232, 129, 182, 10, 195, 121, 74, 78, 165, 215, 241, 27, 222, 250, 58, 48, 194, 134, 161, 137, 176,
verify: 50.000ms
hashing sig: 25, 68, 99, 3, 220, 120, 0, 254, 135, 235, 145, 49, 33, 175, 178, 51, 85, 109, 83, 123, 79, 242, 47, 246, 21, 239, 130, 81, 185, 235, 67, 122,
h_verify: 49, 103, 140, 21, 153, 144, 6, 45, 72, 166, 26, 232, 129, 182, 10, 195, 121, 74, 78, 165, 215, 241, 27, 222, 250, 58, 48, 194, 134, 161, 137, 176,
verification =?= vh[1]:
ALL TIME: 168.000ms
Is that fast or slow? (above I'm doing equivalent of java code): Curve25519.keygen(pub,sigPriv,priv); // generate pub and sigPriv // time1
..
Curve25519.keygen(sigPub, null, sigPriv); // generate sigPub from sigPriv // time2
..
Curve25519.sign(v, hash1, hash2, sigPriv); // return (v, hash1) as a sig // time3
Curve25519.verify(Y, v, hash1, pub); // generate Y // time4
hash(hash(message)+Y) == hash1
) |
|
|
|
If Curve25519 is proved to have flaw, is it easy for us to upgrade the system to other crypto functions?
Thanks.
Changing it won't be easy and won't be instant, but should be doable. Basically, the code would have to be released earlier with some hardcoded number - let's call it X - where to start "new" signature system. After block X all sigs would be checked with NEW system More problematic is that public keys would have to be updated, but still doable, NXT could require to send first transaction signed with both NEW and old privkeys. P.S. more problematic would be what to do with user IDs... |
|
|
|
|
Show Posts
