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?
Topic: Nxt source code flaw reports - page 17. (Read 113378 times)
It was already reported.
Where? What am I missing? Why isn't this a big deal?
In the same way, I can prepare many other id_n with a secret phase set n and generate subsequent blocks,
It's too expensive.
let's see this.
As far as I know, only transaction sender or block generator will get his public key put into Account. So if I create an account a_1 with secret phase s_1, public key p_1, ID id_1. and send some nxt to it. note the public p_1 will not known to public as a_1 is just reciever.
Now I can just prepare many accounts with ID id_1 but diff s_n and p_n due to public key -> id collision. after a_1 get mature after 1440 blocks, I choose the best one of my infinite secret phases s_1....s_n to generate next block with very high success possibility.
this is possible because in Transaction.verify() and Block.verifyBlockSignature(), we only check:
In the same way, I can prepare many other id_n with a secret phase setn and generate subsequent blocks,
Now, can I predict future?...
As far as I know, only transaction sender or block generator will get his public key put into Account. So if I create an account a_1 with secret phase s_1, public key p_1, ID id_1. and send some nxt to it. note the public p_1 will not known to public as a_1 is just reciever.
Now I can just prepare many accounts with ID id_1 but diff s_n and p_n due to public key -> id collision. after a_1 get mature after 1440 blocks, I choose the best one of my infinite secret phases s_1....s_n to generate next block with very high success possibility.
this is possible because in Transaction.verify() and Block.verifyBlockSignature(), we only check:
Code:
Account account = accounts.get(Account.getId(generatorPublicKey));
if (account == null) {
return false;
} else if (account.publicKey == null) {
account.publicKey = generatorPublicKey; // we will get here and pass the checking below
} else if (!Arrays.equals(generatorPublicKey, account.publicKey)) {
return false;
}
if (account == null) {
return false;
} else if (account.publicKey == null) {
account.publicKey = generatorPublicKey; // we will get here and pass the checking below
} else if (!Arrays.equals(generatorPublicKey, account.publicKey)) {
return false;
}
In the same way, I can prepare many other id_n with a secret phase set
Now, can I predict future?...
wait. not remember if someone mentioned this before.
from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
Remember that famous payloadLength=2147483647?...from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
wait. not remember if someone mentioned this before.
from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
Yes...from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
First of all, I hope there's some limit to response size on Jetty side, else attacker can spam nodes with very long answer to any request.
Then, NRS should test blocks from "getNextBlocks" response on:
1. Matching with ids from "getNextBlockIds" response.
2. Matching each other before put to futureBlocks. You can do almost all checks you do in pushBlock()!
At least it makes attaker's life harder. Right now he can send any garbage to "getNextBlock" response, that is parseable as empty block for example.
There's is common problem with peering code in NRS: you test only cryptographic part of data (hashes, keys and so on), but assume that data structures is correct. Remember that famous payloadLength=2147483647?...
wait. not remember if someone mentioned this before.
from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
from line 4552 to 4631.
If the attacker send infinite garbage blocks, futureBlocks will out of memory...
Does the fatal flaw have to do with creation of blocks from 1 to say 1440? Maybe to 720.
Pardon? I don't get the question.
Does the fatal flaw have to do with creation of blocks from 1 to say 1440? Maybe to 720.
Devs, can you do Peer.sendToAllPeers() in new thread? At least for "sendMoney". It's takes minutes to send request to 150+ peers.
Workaround is to press F5 and re-unlock account immediately, just to watch transaction confirmation.
Workaround is to press F5 and re-unlock account immediately, just to watch transaction confirmation.
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...
No, i have not. Only equations of the algorithm. Trying to understand if Curve.sign|verify does what its supposed to. Join the irc channel and we can talk further.. if you want. There are some good guys in there, ZjP is one of them.
Regards
j0b
Regards
j0b
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)
Code:
/* 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));
}
private static final int is_negative(long10 x) {
return (int)(((is_overflow(x) || (x._9 < 0))?1:0) ^ (x._0 & 1));
}
I have to say I don't, but I could spend some time doing one if I knew there'll be possibility to include it.
Currently we don't need it coz Curve25519 works fine.
Hi all experts on crypto science, I'm wondering whether I understand it clear, so I have some naive questions here.
Is there any flaw in Curve25519? So we need to have an independent review of those crypto class and sign/verify function? If it's an open question or argument, then it should be an academic research on Curve25519 and I don't think one independent reviewer can conclude it in a short time.
Is Ed25519 better than Curve25519? Is it because Ed25519 is slow in Java that Nxt doesn't use Ed25519?
If Curve25519 is proved to have flaw, is it easy for us to upgrade the system to other crypto functions?
Thanks.
Ed25519 is a cryptographic system. Curve25519 is a cryptographic primitive. If u want to compare something u have to compare Ed25519 and [EC-KCDSA based on Curve25519].
I have to say I don't, but I could spend some time doing one if I knew there'll be possibility to include it.
Currently we don't need it coz Curve25519 works fine.
Hi all experts on crypto science, I'm wondering whether I understand it clear, so I have some naive questions here.
Is there any flaw in Curve25519? So we need to have an independent review of those crypto class and sign/verify function? If it's an open question or argument, then it should be an academic research on Curve25519 and I don't think one independent reviewer can conclude it in a short time.
Is Ed25519 better than Curve25519? Is it because Ed25519 is slow in Java that Nxt doesn't use Ed25519?
If Curve25519 is proved to have flaw, is it easy for us to upgrade the system to other crypto functions?
Thanks.
I have to say I don't, but I could spend some time doing one if I knew there'll be possibility to include it.
Currently we don't need it coz Curve25519 works fine.
@CfB, have the developers considered switching to Ed25519 instead?
Do u have fast java implementation?
I have to say I don't, but I could spend some time doing one if I knew there'll be possibility to include it.
looks like a needless if-block
or does it have any purpose? At least a place for a breakpoint ...
Code:
for (i = 32; i--!=0; ) {
if (i==0) {
i=0;
}
if (i==0) {
i=0;
}
or does it have any purpose? At least a place for a breakpoint ...
U should ask the author of the code.
yes ... hmmmm, no... maybe the one should ask, who decides to compile that
8921045556724335400 
thx
I also doubt if it is the flaw. Fine, let's keep dig
thxI also doubt if it is the flaw. Fine, let's keep dig
someone can generate a block in legit way and try to modify some bytes so that it has block_id = 0, as pushBlock only check blocks.get(block.getId()) != null where it does = null, the next generated block will override genesis block in analyze()
Code:
if (previousBlock == 0) {
lastBlock = GENESIS_BLOCK_ID;
blocks.put(lastBlock, this);
baseTarget = initialBaseTarget;
cumulativeDifficulty = BigInteger.ZERO;
Account.addAccount(CREATOR_ID);
}
lastBlock = GENESIS_BLOCK_ID;
blocks.put(lastBlock, this);
baseTarget = initialBaseTarget;
cumulativeDifficulty = BigInteger.ZERO;
Account.addAccount(CREATOR_ID);
}
Good catch. Post ur Nxt account, plz.
PS: This is not the flaw.
I came across this: http://crypto.stackexchange.com/questions/12743/is-curve25519-java-secure. So it seems like curve25519 doesn't natively support signing. I'm curious as to why it was chosen?
It's one of the best crypto-primitives, it's not supposed to "natively support signing". Different signing schemes could use Curve25519.
I don't think anyone has replied to this yet.
It will be changed soon.
Jump to: