Topic: NXT Coin Security - page 3. (Read 8426 times)

Is that a question or a statement? If the latter, then that's all I needed to hear! 

I need moooar nxt 

O' rly? so you are saying if you randomed satoshi's address you will be very sad and just delete it?

More like told they just won the jackpot!

can someone who has a reddit account post in the thread http://www.reddit.com/r/CryptoCurrency/comments/1rxtvs/nextcoinorg_new_nxt_forums/cdtuqum and let them know this was never an issue to begin with?

The short answer is when a client has a full load of the blockchain, and has a list of all accounts' public keys and addresses, and if a user attempts to create an account with a truly unique passphrase that happens to generate a 256bit account address that shares the same first 64bits with an already-existing account, then that first account is notified that the passphrase is unusable.

No, about my signature.

yer talking about the secret?

To make more fun I could have wrote that only 4 of this 9 digits are different 

I was worried about that, but no, brute forcing 9-digit account is not any easier than brute forcing 20-digit account. It is just that the first 11 digits are zeros. But you still need to match the full 64 bits, including all starting zeros.

How about memory consumed O_O! I have to delete alot of hentai to accommodate that rainbow table

Yes.  CfB *could* have straightened us all out a bit earlier though, instead of letting us all flip the f**k out...

Please, please, I beg you, bruteforce my tiny account! It is only 9 digits! I haven't sent a bit... oups, NXT from it! So it all be yours!  
Or stop spreading bullshit here  

sorry i closed that other thread.  thanks for this description.

BCNext/CfB: very slick

I had this idea first glance, but I asked for source and was given the vanity gen. I read the source I ran it a little I grabbed a pen and exercised my dusty shameful math skills then I said into myself: huh..... I think I need more of this coin....

Do the same op.

Yes, but one can work around it. All that has to be done is the public key of the account needs to be announced to the network somehow. You can sign a transaction (send 1Nxt to yourself) on an air-gapped computer, then broadcast it to the network using a connected computer. Or a special transaction type could be created, which purpose is just to announce the public key of the account, with zero amount of money moving and no fee.
When you try to broadcast that transaction to the network, you will get an error if the account already exist. Then you just need to try again, generate a new account number offline. It is extremely unlikely though - unless you used a common password and not a randomly generated one.

That might be a problem for offline or paper wallet creation. Something I would like to see in future. Since when offline it can't be known if an account already exists.

I started writing this post in reply to http://nextcoin.org/index.php/topic,471.msg3484.html#msg3484 , only to find that the thread has been locked before I was able to post it. So copying it here:

Then I am correct, you need at least one outgoing transaction before the full public key of an account is stored in transactions.nxt. After that, the full 256 bits are used. But before any outgoing transactions, it is physically not possible for the network to know the account public key - let's say I generated an account using the vanity generator, and gave the account number to someone to send me money. I have never entered my password in the client yet, the account public key could not possibly be known to the network yet.


One other thing I want to point out, the maximum possible password length is irrelevant when trying to evaluate the risk of collisions. Of course, if you use 100000 character passwords, the number of collisions will be enormous. However all that means is that you don't need a 100000 character password. To determine the brute force resources required to find a collision all that matters is the total number of different accounts possible - which currently is 2^64 if you compare account id only, or 2^256 if you compare the full 256-bit public key. Second, it matters how long it takes you to calculate an account number given a password. You cannot indeed compare with bitcoin and the sha-256 hashing power of the bitcoin network, because in addition to sha-256 Nxt is using curve25519 - and there are no asics that calculate that (actually... I don't know, the bitcoin mining asics certainly don't, but who knows what type of hardware NSA has).

Assuming a perfect distribution, you need to try 2^64 different passwords to generate all possible 2^64 account numbers (ignoring the full-public key comparison). So how fast can one do that? On my laptop, with the Vanity.java code I posted on bitcointalk, I can go through 8000 passwords per seconds. This means it will take me 2^64/(8000*3600*24*365) = 73,117,802 years to generate all possible account numbers and have a 100% certainty that the one I am after has been found. Somebody doing this exercise of course will not be after one account only, but would be creating a rainbow table to be used against any account created now or in the future. But try to estimate how much storage space this rainbow table will require...
And that's only for accounts which have only ever received transactions, with no outgoing transactions. Once you send money from your account, its public key gets known to the network, so the account is protected to 2^256 against collisions - try the above calculation now again.