NXT Coin Security

[bizz]

Why not?  A 20 digit long string of numbers is a perfectly valid visibleID. It corresponds with the visibleID of 1e+58 other accountIDs

Are we all talking past each other here? Are we all even talking about the same thing???

When someone else enters a passphrase that gives already used account they'll see a big red message saying that this account can't be used.

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.

[1714829777]

1714829777

[1714829777]

1714829777

[1714829777]

1714829777

[utopianfuture]

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:

transactions.nxt still contains public keys data.

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.

So it is all good ?

[Jean-Luc]

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.

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.

[lophie]

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.

[opticalcarrier]

<lots o awesome shit>

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

BCNext/CfB: very slick

[starik69]

FACT - NXT CAN BE BRUTE FORCE COLLISION ATTACKED VERY MUCH MORE EASILY THAN BTC.

There are too few wallet combinations available making it too easy to brute force some passwords to access someone else's coins.

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  

[opticalcarrier]

So it is all good ?

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

[Come-from-Beyond]

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:

transactions.nxt still contains public keys data.

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.

Nxt has different types of transactions. For example, extended payment (not implemented now though) will include all 256 bits of the recipient. So rainbow tables is just a waste of time.

[lophie]

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

[Jean-Luc]

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  

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.

[starik69]

brute forcing 9-digit account is not any easier than brute forcing 20-digit account.

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

[lophie]

brute forcing 9-digit account is not any easier than brute forcing 20-digit account.

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

yer talking about the secret?

[starik69]

yer talking about the secret?

No, about my signature.

[opticalcarrier]

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.

[lophie]

then that first account is notified that the passphrase is unusable?

More like told they just won the jackpot!

[opticalcarrier]

then that first account is notified that the passphrase is unusable?

More like told they just won the jackpot!

[lophie]

then that first account is notified that the passphrase is unusable?

More like told they just won the jackpot!

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

[opticalcarrier]

then that first account is notified that the passphrase is unusable?

More like told they just won the jackpot!

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

[achimsmile]

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?

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

I need moooar nxt 

[Rokund]

I think it would be better to use full 256-bits as public key.

What's the point for author to use visible ID?

One reason I can guess is that it would be easier to remember.

Since it is still too long to remember, copy-pasting address will still be the most used way to pass public key.

If we still pass key via copy-past, the shorter id don't save any time. So the shorter(still long) id has no any meaning.

The disadvantages:

Offline wallet become dangerous because there may be chance that you created an id that already existed.

Because you're off-line you didn't know that the id was conflicted. Then you ask someone to send NXT to the id you just generated.

Then you no loner be able to access to the NXT because when you enter the passphrase you were told that the id cannot be used because of the conflict.