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

This will be fixed by a special payment transaction that sends money to a full 256-bit address.

but that would leave open an attack for a spammer to megaspam the blockchain with millions and millions of empty accounts

Thank u for the explanation. I have zero tolerance to guys who think they r the smartest. That's why my last reply to etlase3 may look a little bit rude.

The 64bit issue you are talking about is real but trivial to fix, hard to exploit and easy to protect yourself against.

It can only be exploited if an account doesn't have an associated public key. In that case, the issue is real. 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.

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... You know, everything can be "cracked" or "bruteforced" in cryptography. However, if the time taken to bruteforce is more expensive or require more time than the validity of the data, then we consider this safe.

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. It doesn't require much modifications on the current codebase to do this.

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...

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

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.

Would u be so kind to not bother me with ur comments until u read the code and get its logic?

I guess what Come-from-Beyond means is that equivalent key sizes do not imply equivalent security and vice versa

There isn't really any room to disagree, 64 bits is not safe.

I would leave finding a solution to this problem to guys who will clone Nxt. With TF this attack is impossible.
PS: If u use the same account to hallmark these 300 servers then each of them will have 1/300 of the balance.

Ok, I went thru the decompiled code, and I think, you didn't improve it by much, because the new code now has a nice DOS attack vector...
If I send you a request that forks the blockchain just one block before the current one and I lie about cumulated difficulty, you'll automatically do a complete rescan of the blockchain. This takes (I guess) more than a second, so the next thread for requesting the blockchain will already wait (because of the synchronized block), so if there the same happens, your client will keep being blocked.
So how do you exploit that?
Well, you need 300ish servers, publish their addresses to the network, have all of them appear in good shape (maybe backed by some accounts so they get nice hallmarks), and have them send the wrong cumulative difficulty and one block to add.
The chance that there will be a request to one of your servers is quite high and the blacklisting is removed after 300s, so they'll be used again. But since the client will probably take way more than a second, you can even get by with fewer servers...
And you'll cause high cpu load and slow (or old) responses for the attacked peer, plus a lot of disk reads and writes.

Actually, on that note: Do you check anywhere if a hallmark appears twice? If not, you could back all of your servers with the same big account which would give them a nice bonus in being chosen for the post request...

Sorry, but I disagree that ur example is relevant.

 

Your answer is borderline incompetent, so it doesn't deserve much.

http://crypto.stackexchange.com/questions/2319/what-is-the-largest-performed-possible-bruteforce-attack-to-date

64-bit symmetric keys were broken in 2002.

This issue is fixed as well.

And if you fix that one, you can also fix this: https://bitcointalksearch.org/topic/m.4316634
Nearly the same issue, just different parameter

[edit]
Thanks CfB and JLP for the quick fix of the negative budget, starting to browse thru the decompiled code now.

Thank u for ur competent opinion.

This is a terrible answer to the question. 64-bits of protection is a design flaw.

To make sure that time/timezone is incorrect.

The NRS server runs on debian. The OS gets its time from timeservers and it is correctly. So why should I set this time manually back, so that transactions get sent?