Pages:
Author

Topic: Nxt source code flaw reports - page 27. (Read 113369 times)

full member
Activity: 168
Merit: 100
IDEX - LIVE Real-time DEX
January 09, 2014, 02:26:55 PM
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://bitcointalksearch.org/topic/m.4345122 plz.

why js not java? bounty still open?

two words: thin client
hero member
Activity: 687
Merit: 500
January 09, 2014, 02:26:26 PM
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://bitcointalksearch.org/topic/m.4345122 plz.

I am on it but I think it will a lot slower than you want Sad
hero member
Activity: 687
Merit: 500
January 09, 2014, 02:24:55 PM
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://bitcointalksearch.org/topic/m.4345122 plz.

why js not java? bounty still open?

Well we already have code writte in java Wink
Take a look at class Curve25519.java.
hero member
Activity: 687
Merit: 500
January 09, 2014, 02:23:25 PM
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?  Smiley

//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().
newbie
Activity: 56
Merit: 0
January 09, 2014, 02:21:57 PM

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() Wink
legendary
Activity: 866
Merit: 1002
January 09, 2014, 02:12:50 PM
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://bitcointalksearch.org/topic/m.4345122 plz.

why js not java? bounty still open?
newbie
Activity: 50
Merit: 0
January 09, 2014, 01:57:21 PM
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 Smiley

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?  Smiley

//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).
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 01:08:39 PM
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://bitcointalksearch.org/topic/m.4345122 plz.
legendary
Activity: 866
Merit: 1002
January 09, 2014, 12:43:15 PM
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? Smiley

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
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 12:24:13 PM
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.
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 12:19:38 PM
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? Smiley
legendary
Activity: 866
Merit: 1002
January 09, 2014, 12:05:02 PM
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.
newbie
Activity: 50
Merit: 0
January 09, 2014, 11:49:36 AM
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.
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 10:38:46 AM
Grin

We completely derailed this thread.
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 10:30:10 AM
Perhaps all those three are one guy.

Or a gal...
full member
Activity: 238
Merit: 100
January 09, 2014, 10:27:02 AM
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 Grin

Come-from-Beyond is BCNext, and Jean-Luc seems to be another guy. Perhaps all those three are one guy.
hero member
Activity: 784
Merit: 501
January 09, 2014, 10:08:09 AM
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 Smiley
legendary
Activity: 1176
Merit: 1134
January 09, 2014, 10:07:39 AM
Not if they precalculated a change that ends up with same hash
legendary
Activity: 866
Merit: 1002
January 09, 2014, 10:03:29 AM
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"
legendary
Activity: 2142
Merit: 1010
Newbie
January 09, 2014, 10:01:50 AM
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 Grin

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 Grin
Pages:
Jump to: