Nxt source code flaw reports

[Come-from-Beyond]

Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian.

I'm not entirely sure who is who or whether all three are one, but that makes it more exciting

I just leave it here - http://en.wikipedia.org/wiki/Trinity_(The_Matrix)

PS: This explains why sometimes we see "The matrix has you..." in NRS

[1715318571]

1715318571

[1715318571]

1715318571

[gimre]

Not sure if its logic flaw, but somebody could simply change initial allocation in genesis block to give themselves a lot of NXT.

We have seen a case of altered client already, so changing genesis block's hardcoding and hypnotizing jean-luc into signing it as the official release, would be an obvious but effective way to steal a lot of NXT

James

and it would invalidate all existing transactions so it's a "no go"

[jl777]

Not if they precalculated a change that ends up with same hash

[ImmortAlex]

Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian.

C-f-B is from Belarus. ...but it doesn't mean his is not Russian.
Like, I'm from Russia, but it doesn't mean that I'm Russian

[NxtChoice]

Not sure if its logic flaw, but somebody could simply change initial allocation in genesis block to give themselves a lot of NXT.

We have seen a case of altered client already, so changing genesis block's hardcoding and hypnotizing jean-luc into signing it as the official release, would be an obvious but effective way to steal a lot of NXT

James

True, that's why noone knows who Jean-Luc is.

Maybe he is BCNext!

Well, BCNext, "Jean-Luc" and Come-from-Beyond are all three Russian.

I'm not entirely sure who is who or whether all three are one, but that makes it more exciting

Come-from-Beyond is BCNext, and Jean-Luc seems to be another guy. Perhaps all those three are one guy.

[Come-from-Beyond]

Perhaps all those three are one guy.

Or a gal...

[Come-from-Beyond]

We completely derailed this thread.

[gsan1]

When I unlock my account in the client and close the browser window, the client is still forging cause the java client is running. Then why does the client show the account locked, when I close the window and reopen it? Could we use a session/cookie to make this easier? This confuses a lot nxt users.

[gimre]

stuff that I've checked:
classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519

classes I think are ok: Account, Block, Peer, Transaction, User, UserAsyncListener,
(at first four I've looked more than 2 times)

most of anonymous objects (those in scheduledThreadPool.scheduleWithFixedDelay) also look ok (I want to make one more closer look to that big one, where there's block processing).

So IMHO, IF there are injected flaws they are inside main Nxt class.

[Come-from-Beyond]

stuff that I've checked:
classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519

classes I think are ok: Account, Block, Peer, Transaction, User, UserAsyncListener,
(at first four I've looked more than 2 times)

most of anonymous objects (those in scheduledThreadPool.scheduleWithFixedDelay) also look ok (I want to make one more closer look to that big one, where there's block processing).

So IMHO, IF there are injected flaws they are inside main Nxt class.

Hey, u shouldn't exclude inner classes, we r still interested in their review, what if not all bugs r found?

[Come-from-Beyond]

Well, I decided to give a small hint. In this thread we discussed a situation that is very close to the critical flaw. One of the guys asked a question that I didn't answer completely, coz otherwise I would reveal the flaw.

[gimre]

stuff that I've checked:
classes not actually worth looking at: Alias, AskOrder, Asset, BidOrder, Crypto Curve25519

Hey, u shouldn't exclude inner classes, we r still interested in their review, what if not all bugs r found?

I mean those initial classes are either tiny or empty.
In case of Crypto I was already checking it with pen+paper, as I've written on nextcoin forum.
I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

[Come-from-Beyond]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

[gsan1]

ok, looked at it again:

the blockID is a hash over everything in the block (including a payloadHash).
so as soon as you change a transaction, your block will get a different id.
and the id of the previous block is also saved in a block, because that's the reference to building up the chain.

so: everything safe

Wait, wait, wait... Back to Bloody Rookies attack from page 37 of this thread.
The result was: That attack won't work cause every block has the id of the previous block. And if you change one transaction, payloadHash will change and so the id of the block will change, making the blockchain corrupt.

Lets take a look at the method that returns the block id:

Code:

byte[] hash = MessageDigest.getInstance("SHA-256").digest(getBytes());
BigInteger bigInteger = new BigInteger(1, new byte[] {hash[7], hash[6], hash[5], hash[4], hash[3], hash[2], hash[1], hash[0]});
return bigInteger.longValue();

The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method.
Lets take a look at the initialization of the ByteBuffer that is used:

Code:

byte[] getBytes() {
			
			ByteBuffer buffer = ByteBuffer.allocate(4 + 4 + 8 + 4 + 4 + 4 + 4 + 32 + 32 + 64 + 64);
			buffer.order(ByteOrder.LITTLE_ENDIAN);
			buffer.putInt(version);
			buffer.putInt(timestamp);
			buffer.putLong(previousBlock);
			buffer.putInt(numberOfTransactions);
			buffer.putInt(totalAmount);
			buffer.putInt(totalFee);
			buffer.putInt(payloadLength);
			buffer.put(payloadHash);
			buffer.put(generatorPublicKey);
			buffer.put(generationSignature);
			buffer.put(blockSignature);
			
			return buffer.array();
			
}

The first 64 bytes of the getBytes() method (that are setting the blockID) are: version, timestamp, previousBlock, numberOfTransactions, totalAmount, totalFee, payloadLength AND NOT PAYLOADHASH! SO this attack is possible.

So: We can replace the transaction (going to the nxt/btcexchance) with another of the same amount (so numberOfTransactions, totalAmount, totalFee is the same), but we don't send the coins to the exchance anymore but to another account that is mine.

Could you follow me?  

//EDIT: This attack would only be possible in 0.4.7e because now a block contains the hash of the previous one (and not only the id).

[gimre]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

why js not java? bounty still open?

[minusbalancer]

Lets take a look at the method that returns the block id:

Code:

byte[] hash = MessageDigest.getInstance("SHA-256").digest(getBytes());
BigInteger bigInteger = new BigInteger(1, new byte[] {hash[7], hash[6], hash[5], hash[4], hash[3], hash[2], hash[1], hash[0]});
return bigInteger.longValue();

The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method.

Hash function is calculated based on all of the bytes from the block. Id is taken from first 64 bits of the hash. Not the first 64 bits of the getBytes()

[BloodyRookie]

The hash consists of hash[7], hash[6], ... hash[0]. So it consists of the first 64 bytes of the getByte method.

Could you follow me?  

//EDIT: This attack would only be possible in 0.4.7e because now a block contains the hash of the previous one (and not only the id).

No , the 64 bytes are taken from the hash and the hash is calculated from all the bytes we got from getBytes(). It is not the first 64 bytes of getBytes().

[BloodyRookie]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

why js not java? bounty still open?

Well we already have code writte in java
Take a look at class Curve25519.java.

[BloodyRookie]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

I am on it but I think it will a lot slower than you want

[ferment]

I think we could have better/faster implementation of Curve25519, but it's something that shoulbe further researched

Btw, we have 100'000 NXT bounty for fast JS-implementation. Look at https://bitcointalk.org/index.php?topic=345619.msg4345122#msg4345122 plz.

why js not java? bounty still open?

two words: thin client