Nxt source code flaw reports

[ricot]

Now onwards to the 100k one... Killing a copy-coin in a day...
Do we have a supercomputer available for the job?

[edit]
Was any discussion in that thread somewhere close to that bug or haven't we touched that at all yet?

[Come-from-Beyond]

Now onwards to th 100k one... Killing a copy-coin in a day...
Do we have a supercomputer available for the job?

No.

5 y.o. computer is enough.

[Come-from-Beyond]

So... was this related to the found flaws?

thnx  

No

[CrazyEyes]

Well done rico and bloodyrookie

[jkoil]

looks like a needless if-block

Code:

			for (i = 32; i--!=0; ) {
				if (i==0) {
					i=0;
				}

or does it have any purpose? At least a place for a breakpoint ...

[gsan1]

When generating a block, you have 2 signatures that could go wrong.
One is the generationSignature, which is calculated from the previousBlock, so there is no chance in changing it when it fails. (i.e. 25% invalid block).
The other one is the blockSignature. Currently, this is only generated once and contains a hash of e.g. all the transactions. If that signature fails in NRS, the client will just output invalid block and don't continue to try.
If Bob isn't using NRS, he could generate the blockSignature again with different data, i.e. different transactions. It's relatively easy to find a payload that will generate a valid hash.
Bob could then transmit the perfectly fine block, which NRS would have not enabled him to do. So he got an advantage by not using the default client.

Well, u and BloodyRookie explained 99% of the serious flaw. I think u both should get 1'000 NXT. Post ur account.

@BloodyRookie: Post ur Nxt account, plz.


PS: The description of the serious flaw is:

Code:

An incorrect block signature is not recalculated. This gives ability to use less than 50% of the stake to attack the network.

Congrats  
I was so close to find out this flaw, but you were faster. Well even if I detected no flaw, it gave me a really good understanding of NXT works.   Time to invest some more money in NXT I guess.  

[Come-from-Beyond]

looks like a needless if-block

Code:

			for (i = 32; 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.

[msin]

When generating a block, you have 2 signatures that could go wrong.
One is the generationSignature, which is calculated from the previousBlock, so there is no chance in changing it when it fails. (i.e. 25% invalid block).
The other one is the blockSignature. Currently, this is only generated once and contains a hash of e.g. all the transactions. If that signature fails in NRS, the client will just output invalid block and don't continue to try.
If Bob isn't using NRS, he could generate the blockSignature again with different data, i.e. different transactions. It's relatively easy to find a payload that will generate a valid hash.
Bob could then transmit the perfectly fine block, which NRS would have not enabled him to do. So he got an advantage by not using the default client.

Well, u and BloodyRookie explained 99% of the serious flaw. I think u both should get 1'000 NXT. Post ur account.

@BloodyRookie: Post ur Nxt account, plz.


PS: The description of the serious flaw is:

Code:

An incorrect block signature is not recalculated. This gives ability to use less than 50% of the stake to attack the network.

Congrats guys!  Can we get a summary on what flaws are left to be uncovered?

[Come-from-Beyond]

Congrats guys!  Can we get a summary on what flaws are left to be uncovered?

The fatal flaw with 100K reward. It will kill a copy-coin in a day, an old computer is enough for the attack.

[BloodyRookie]

Account number is in my sig.

[msin]

Congrats guys!  Can we get a summary on what flaws are left to be uncovered?

Each flaw has a small description. Here r SHA256 hashes of these descriptions:

bd34c891e9e3df9ea8b8eafc4dc3edc129f81365d42bf204ea58271e320f3ce5 - 1K reward
888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530 - 10K reward
f5236644f4306699bb0fa90a905afe2454683c0aad6995e4433d712e2fdb257c - 100K reward

The flaws must be reported before the 3rd of April, after that date they can be revealed at any moment.

Well, I guess it's appropriate that the fatal flaw is the last to be discovered.

[grizmoblust]

Congrats guys!  Can we get a summary on what flaws are left to be uncovered?

Each flaw has a small description. Here r SHA256 hashes of these descriptions:

bd34c891e9e3df9ea8b8eafc4dc3edc129f81365d42bf204ea58271e320f3ce5 - 1K reward
888f278c773d39b8334a651d84ee78871bd0e5d45e09be8fdb190ba1b2969530 - 10K reward
f5236644f4306699bb0fa90a905afe2454683c0aad6995e4433d712e2fdb257c - 100K reward

The flaws must be reported before the 3rd of April, after that date they can be revealed at any moment.

Well, I guess it's appropriate that the fatal flaw is the last to be discovered.

It sounds like bcnxt knows the fatal flaw according to his wording.

[BloodyRookie]

Edit:  A little friendly reminder...      Hey ricot and BloodyRookie... you need to take a look quick!

I think that was related to the block id flaw.

[Come-from-Beyond]

Not a fatal flaw, but something to think about.

What you do is forge /every/ chain, keep every alt chain you have. Forge on it and wait until you can forge on everything, even after you get a block. And then spam those out because theres a small chance they could become the longest

You don't get penalized in transparent forging, because you forge on everything. You get a block, your forge time in 2 minutes. At 90 seconds, someone else forgers you ignore this, and forge at 2 minutes as if you didn't receive.
now there are two chains, the longest, and one thats off by only 30 seconds, you receive both. but the 30 second longer one is advantageous to you, because it gives you a lower forging time, so you forge on it.
as soon as you can (even if you have received other blocks for it).and so on and so forth, creating an incentive to create exponential alt chains and process non-longest chains.

If this can happen, then the network would under a lot of pressure.

Regards
j0b and ZjP

Sounds like multiverse concept. We already have coins and anticoins, superposition of transactions lost in limbo, event horizon that limits rate of the transactions, time warp of transparent forging...

[Jaguar0625]

But I'd be very interested in hearing why the unverifiability happens and to see numbers on how often that happens.

Sometimes verification faces a situation similar to

Code:

X * 0 == Y * 0

In this case it's impossible to make sure that X == Y.

It happens ~ each 4th time.

Are you saying that you can't verify 25% of signatures? Isn't that a pretty serious issue?

[Jaguar0625]

In this case, let's say B is malicious and wants to replace A(1, 2, 2) with a different block. In this case, B(1, 2, 10) does not chain to the last block in A so it is put in as a future block. The two possible chains for A are:
A.1: { (0, 1, 1), (1, 2, 2), (2, 3, 3) }
A.2: { (0, 1, 1), (1, 2, 10) }

Since A.2 has a higher difficulty, it will be chosen. As far as I can tell, I don't see anything preventing a malicious attacker from manipulating cumulative difficulty scores in order to get blocks dropped.

Maybe I haven't slept enough, but I think you're right, but...

This would imply two things:

• He would have to be generator of (1,2,10) - ok he can predict that
• but he would also have to be generator of (1,2,2) (coz verify generation signature would't pass)

so basically he would invalidate his own block...

This would also work if B was manipulated to have both new chaining blocks and future blocks, e.g.
B: { (0, 1, 1), (1, 2, 2), (2, 3, 3), (3, 4, 4), (1, 2, 10) }

In effect, this would keep transactions (B(3, 4, 4) in the example completely hidden from A.

Or am I missing something?

I think this is good example, that those situations (adding to end of chain AND invalidating tail of chain) are (or rather should, as they are not now)
mutually exclusive cases...

So, isn't this something that can be taken advantage of by a large account holder? The largest account holder right now has 70M NXT, which means that he should be able to forge 7% of blocks. At this rate, it seems very possible that he can generate two blocks within the block height of 720 that clients look at when syncing. (Not to mention that this could also be exploited if there was collusion by among some of the top account holders).

I don't think anyone has replied to this yet.

[Jaguar0625]

Good. We'll get some bitcoins to set a reward for Nxt crypto algo audit. Yes, bitcoins, not nxts, coz if the algo is flawed nxts won't be worth a lot .

@CfB, have the developers considered switching to Ed25519 instead?
I think it could easily be deployed (i.e, require all txes + blocks > 40k block to have new sig).

There are many advantages.
First one being it's much better verified and tested than current sing+verify.
Second one is probably speed (although I haven't tested), as computations in Edward's form should be easier.

Do u have fast java implementation?

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?

[liyi3c]

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);
				
			}

[Come-from-Beyond]

Are you saying that you can't verify 25% of signatures? Isn't that a pretty serious issue?

It was already reported.

[Come-from-Beyond]

I don't think anyone has replied to this yet.

It will be changed soon.