Basically, we look though the profiles of every stakeholders and group them into three groups: Group 1 : veteran accounts opened before the fundrasing; Group 2 : accounts opened during the fundrasing but showed further activity; Group 3: accounts opened for NEM registration only (1 post)
Not all of group 3 are sock puppets. I know I asked a friend to open an account and post it. I paid for her. Sent her TX via PM. She is unique stakeholder, even though she is listed in group 3. Plus she has over 10 K twitter followers. If this thing picks up, she might be an asset in promotion  |
|
|
|
If general public lose confidence, it's bad for all crypto -- Nxt included |
|
|
|
sweet! so did you claim my bounty? We need to lower the transaction fee. 1 nxt is way too high for being useful in tipping |
|
|
|
I agree. She should be sent the full source code of 0.73
What for? She already said that wouldn't check the implementation. Didn't we want her to check the algos? Plus, send her bloodyrookie's fix, and see how that compares with the original. Let's complete the 1st step - audit the implementation and then move to a higher level. Is that 10 BTC offer still open? |
|
|
|
If someone wants to write up an overview of what exactly we need for the crypto auditing, I can send it to a few Crypto experts I've been in contact with. Just PM me.
Please, CfB, help with that. Edit: what kind of 'experts'? I've been in contact with several people, including Matt Green (zerocoin). I was originally referred to Matt by Susan Waters ( http://cs.jhu.edu/~susan/) who was his professor, and Susan also recommended Lisa Yin in the same email. I've had contact with Lisa and she sounds open to an audit. Lisa has a PHD from MIT in Crypto. I have contact with a few other academics as well. Right, Lisa. I remember ( https://bitcointalk.org/index.php?topic=345619.msg4989534#msg4989534). Well, what do you think, CfB? Just do it. We need someone to check that Curve25519 and Crypto have no bugs. You should email him (or her directly) the source for 0.73 Her email is listed at http://people.csail.mit.edu/yiqun/She already wrote in that email: I am wondering what you are looking for in the code review. If it is mainly the correctness of the implementation, then I would take a pass. I feel that what would be most helpful for Nxt is to review how the above crypto algorithms are utilized within the Nxt currency system to achieve the intended security goals. " If I understand it correctly, that means she is not willing to check any code. Checking the principal algorithm is not enough. Usually the problems come with the implementation of the algorithm. I agree. She should be sent the full source code of 0.73 |
|
|
|
How does running potentialy malicious software used to directly access your money inside a VM protect the money that you're using the software to access? That's not good logic. Sure it segregates the rest of your system, but it does not protect the money.. Don't put most of your money in VM client account. There is a huge difference. The source code can be audited. Then I can compile the open source code and run that. Then I can distribute those binaries to friends and family to use.
No one (at least not 99.999%) compile the source and run it. They just download and run the executable. There is no way to be sure if they are same. At some point, there has to be trust involved. You trust your operating system (did you compile it yourself?) You trust your browser (did you compile it yourself?) There is no such thing as zero trust. I personslly won't run bter software on my main system as I don't trust them (yet). To each it's own. |
|
|
|
If someone wants to write up an overview of what exactly we need for the crypto auditing, I can send it to a few Crypto experts I've been in contact with. Just PM me.
Please, CfB, help with that. Edit: what kind of 'experts'? I've been in contact with several people, including Matt Green (zerocoin). I was originally referred to Matt by Susan Waters ( http://cs.jhu.edu/~susan/) who was his professor, and Susan also recommended Lisa Yin in the same email. I've had contact with Lisa and she sounds open to an audit. Lisa has a PHD from MIT in Crypto. I have contact with a few other academics as well. Right, Lisa. I remember ( https://bitcointalk.org/index.php?topic=345619.msg4989534#msg4989534). Well, what do you think, CfB? Just do it. We need someone to check that Curve25519 and Crypto have no bugs. You should email him (or her directly) the source for 0.73 Her email is listed at http://people.csail.mit.edu/yiqun/ |
|
|
|
If someone wants to write up an overview of what exactly we need for the crypto auditing, I can send it to a few Crypto experts I've been in contact with. Just PM me.
Please, CfB, help with that. Edit: what kind of 'experts'? I've been in contact with several people, including Matt Green (zerocoin). I was originally referred to Matt by Susan Waters ( http://cs.jhu.edu/~susan/) who was his professor, and Susan also recommended Lisa Yin in the same email. I've had contact with Lisa and she sounds open to an audit. Lisa has a PHD from MIT in Crypto. I have contact with a few other academics as well. Right, Lisa. I remember ( https://bitcointalk.org/index.php?topic=345619.msg4989534#msg4989534). Well, what do you think, CfB? Just do it. We need someone to check that Curve25519 and Crypto have no bugs. You should email him (or her directly) the source for 0.73 |
|
|
|
So stolen accounts for some and audited open source clients for others it is then...
How can people fail to grasp the most basic importance of this. It has nothing to do with "open source initiatives". Its that people MUST know its safe to use based not on a persons guarantee (trust), but on open code that can be audited by anyone, anywhere, any time. This is peoples money and livelihoods were talking about.
If someone wants to release closed source software for Nxt, so be it. Just don't download and install them. Or run them on virtual machines with no access to parent OS. Besides, open source doesn't really mean "safe" as most people just download and run the compiled binaries. There is no way to be sure if the complied executable is the same as "sources" . |
|
|
|
You guys sure are quick! Here's the full scoop. DGEX is proud to present Offspring - The Cross-Platform 2nd Gen Crypto Client.http://offspring.dgex.comScreen shots? |
|
|
|
If someone wants to write up an overview of what exactly we need for the crypto auditing, I can send it to a few Crypto experts I've been in contact with. Just PM me.
Please, CfB, help with that. Edit: what kind of 'experts'? I've been in contact with several people, including Matt Green (zerocoin). I was originally referred to Matt by Susan Waters ( http://cs.jhu.edu/~susan/) who was his professor, and Susan also recommended Lisa Yin in the same email. I've had contact with Lisa and she sounds open to an audit. Lisa has a PHD from MIT in Crypto. I have contact with a few other academics as well. Right, Lisa. I remember ( https://bitcointalk.org/index.php?topic=345619.msg4989534#msg4989534). Well, what do you think, CfB? Any update on this? |
|
|
|
On each server, only the server admin will know the wallet address for that server, so we compartmentalize the financial risk.
How is that different than trusted gateway? Here we are trusting (1) Server Admin (that's human) (2) Hack protection of the server (2) Client software |
|
|
|
We have the original c implementation by djb - let some cryptographers (dmitry was no crypto guy!) port it for us!
The bug was in original c version. The port by dimitry is just fine. I know one thing: we still need a cryptographer for auditing! Yes, after implementing the fix from BloodyRookie. I think BloodyRookie patch should be implemented |
|
|
|
We have the original c implementation by djb - let some cryptographers (dmitry was no crypto guy!) port it for us!
The bug was in original c version. The port by dimitry is just fine. |
|
|
|
No, but we can compare the results |
|
|
|
First one (left) is total crap: /* v = x - h k mod q
* returns v != 0 */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
uint8_t tmp[65];
unsigned w, i;
for (i = 0; i < 32; i++)
tmp = x;
for (i = 32; i < 64; i++)
tmp = 0;
mula32(tmp, h, k, 32, -1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
Second one is the one we use in Nxt. /* v = (x - h) s mod q */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
uint8_t tmp[65];
unsigned w;
int i;
for (i = 0; i < 32; i++)
v = 0;
i = mula_small(v, x, 0, h, 32, -1);
mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
for (i = 0; i < 64; i++)
tmp = 0;
mula32(tmp, v, s, 32, 1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
That's bad. What about comparing outputs of NRS, ur and some other implementation, like NaCl? If ur and NaCl return the same values and NRS returns different ones then we could assume that ur implementation is correct. There is also this c# version https://github.com/hanswolff/curve25519Can't this ported to java? Ops that's actually port from same Java that Nxt uses. Maye look at that C# version on how (if) he fixes the bug |
|
|
|
First one (left) is total crap: /* v = x - h k mod q
* returns v != 0 */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
uint8_t tmp[65];
unsigned w, i;
for (i = 0; i < 32; i++)
tmp = x;
for (i = 32; i < 64; i++)
tmp = 0;
mula32(tmp, h, k, 32, -1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
Second one is the one we use in Nxt. /* v = (x - h) s mod q */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
uint8_t tmp[65];
unsigned w;
int i;
for (i = 0; i < 32; i++)
v = 0;
i = mula_small(v, x, 0, h, 32, -1);
mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
for (i = 0; i < 64; i++)
tmp = 0;
mula32(tmp, v, s, 32, 1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
That's bad. What about comparing outputs of NRS, ur and some other implementation, like NaCl? If ur and NaCl return the same values and NRS returns different ones then we could assume that ur implementation is correct. There is also this c# version https://github.com/hanswolff/curve25519Can't this ported to java? |
|
|
|
First one (left) is total crap: /* v = x - h k mod q
* returns v != 0 */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
uint8_t tmp[65];
unsigned w, i;
for (i = 0; i < 32; i++)
tmp = x;
for (i = 32; i < 64; i++)
tmp = 0;
mula32(tmp, h, k, 32, -1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
Second one is the one we use in Nxt. /* v = (x - h) s mod q */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
uint8_t tmp[65];
unsigned w;
int i;
for (i = 0; i < 32; i++)
v = 0;
i = mula_small(v, x, 0, h, 32, -1);
mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
for (i = 0; i < 64; i++)
tmp = 0;
mula32(tmp, v, s, 32, 1);
divmod(tmp+32, tmp, 64, order25519, 32);
for (w = 0, i = 0; i < 32; i++)
w |= v = tmp;
return w != 0;
}
ok, so "curve25519_i64-wip.tgz" is the one used in Nxt. I deleted the first one |
|
|
|
|
Show Posts
