NXT Coin Security

[Come-from-Beyond]

Again - full disclosure - are you an early adopter, do you have NXT and are you selling NXT?

I'm one of those 73 founders. I own almost 3M and I don't sell them coz I saw the source code of decentralized exchange and know for sure that price will skyrocket.

My bet is yes you have NXT and are selling NXT.

See above.

You're an idiot if you think I am talking about some random fluke where 2 innocent users happen upon the same key. I am talking about brute forcing the system.

U should stop insulting me if u want to continue the discussion. If someone has so much power to brute force Nxt, he will prefer to mine BTC. And Bitcoin difficulty will become 1000 times higher in 2 days.

You create a thread and post about Bitcoin being open to a collision attack with a chance of finding same key 10^24. You, in your own words say it's not a big number and can easily be done with hashing power of BTC.

I was wrong and I stated this in that thread after some guys explained were my logic failed.

Now NXT has 10,000 fewer possibilities that this at 10^20 (though I suppose it's actually 10^20 + 10^19 + 10^18 etc....but this doesn't increase the order of magnitude by that much really).

In current implementation number of usable Nxt accounts is limited to 2^64. 30 lines of code would change this to 2^128 (up to 2^256).

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

No. And u failed to give a mathematical proof.

[1715513778]

1715513778

[1715513778]

1715513778

[1715513778]

1715513778

[1715513778]

1715513778

[1715513778]

1715513778

[laowai80]

I guess the best way to think of NXT is as your brain wallet with a browser interface. That could actually be made into a slogan. Because people are already familiar with the concept of a brain wallet thanx to bitcoin, they should know that the brain wallet password must be very long and hard to guess. So, yeah, NXT is a brain wallet, that's basically it. If you screw up creating a good long password, your funds become someone else's possession.

NXT being a brain wallet ONLY crypto currency has both good and bad sides.

Good sides:

- you don't need to install additional software if you don't want to (you will be able to access public, maybe even official nodes using your brain wallet password in the future), or install it on localhost if you want to feel secure/a bit paranoid. C-f-B will probably say it's best to install it on localhost for security and he's right, all I am saying, if you need to urgently access your funds and you can't install it at that moment, you can access it from anywhere in the world using any public node. I am sure in the future there will be (semi-)official public nodes with easy-to-remember domain names.

- you don't have to worry about someone stealing your wallet.dat, because there is no wallet.dat, keyloggers might still catch your pass phrase, so still have to be careful about them.

- you don't have to worry about backing up your wallet.dat (but you have to back up or remember well your pass phrase). Hint: could make up a pass phrase in such a way, that if you see the first half of the phrase you can easily remember the second half (creates a sort of association in your mind). But the first half should not give any clue to a stranger about the second half. That way, the first half of the phrase can be stored even right next to your computer. A stranger wouldn't know what to associate it with. I don't advocate keeping even half of the pass phrase next to your computer though

- remembering and trying to reproduce in writing your own and someone else's account number to send or accept funds is easier, because it's only numbers in the account number and there are less of them than with bitcoin and other alt-coins.

Someone please come up with legitimate bad sides regarding security, but please something smarter than what user miztaziggy was able to concoct.

[bitme]

I'm not good at statistics and cryptography but for me this system is just secure enough if you choose reasonably strong phrase.

I don' know how many different phrases open the same account but i think that probability of existing even two of them that you would be able to write on roll of toilet paper is neglectable small

I have NXT and I'm buying more

[dtothemt]

I edited my post, but since you replied so quickly I think you didn't see it. Thanks for the clarification.

There is still a certain risk I think. What happens if two addresses happen to share the same first 20 bits and someone sends that address some NXT? Wouldn't it be better to compress the full 256 bits into an alphanumeric string (assuming such a function can be created)?

[Come-from-Beyond]

I edited my post, but since you replied so quickly I think you didn't see it. Thanks for the clarification.

There is still a certain risk I think. What happens if two addresses happen to share the same first 20 bits and someone sends that address some NXT? Wouldn't it be better to compress the full 256 bits into an alphanumeric string (assuming such a function can be created)?

Risk is 1 in a billion. If u happen to be the 2nd user of the same account u have to choose other passphrase.

[miztaziggy]

I edited my post, but since you replied so quickly I think you didn't see it. Thanks for the clarification.

There is still a certain risk I think. What happens if two addresses happen to share the same first 20 bits and someone sends that address some NXT? Wouldn't it be better to compress the full 256 bits into an alphanumeric string (assuming such a function can be created)?

Risk is 1 in a billion. If u happen to be the 2nd user of the same account u have to choose other passphrase.

The problem is if you would create a wallet that happens to have the same first 20 or 19 or 18 characters as someone else.
Say I do that, buy some NXT and leave them there.

Someone else with another password logs in and coincidentally has the same 20/19/18 etc characters to their public wallet. They will see my coins and be able to spend them.

Until the wallet addresses are updated to create more wallets, it is fundamentally flawed and insecure.

- remembering and trying to reproduce in writing your own and someone else's account number to send or accept funds is easier, because it's only numbers in the account number and there are less of them than with bitcoin and other alt-coins.

Someone please come up with legitimate bad sides regarding security, but please something smarter than what user miztaziggy was able to concoct.

This is the bad point. And this is my point. If you don't understand it, please, reread what I am saying.

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

[Come-from-Beyond]

The problem is if you would create a wallet that happens to have the same first 20 or 19 or 18 characters as someone else.
Say I do that, buy some NXT and leave them there.

Someone else with another password logs in and coincidentally has the same 20/19/18 etc characters to their public wallet. They will see my coins and be able to spend them.

Until the wallet addresses are updated to create more wallets, it is fundamentally flawed and insecure.

On nextcoin.org I posted the source code that checks all 256 bits. Have u seen it?

[miztaziggy]

I have now.

Tell me, how is that code used?

Because, and tell me if I am wrong:

I can send NXT from my wallet to any other wallet by inputting ONLY their 18/19/20 digit wallet key.

Anyone that can open their wallet that has that same 18/19/20 digit wallet key has access to those NXT.

Anyone that has access to those coins can move / spend those coins?

[dtothemt]

I have now.

Tell me, how is that code used?

Because, and tell me if I am wrong:

I can send NXT from my wallet to any other wallet by inputting ONLY their 18/19/20 digit wallet key.

Anyone that can open their wallet that has that same 18/19/20 digit wallet key has access to those NXT.

Anyone that has access to those coins can move / spend those coins?

They will not see your balance, because the full 256-bits do not match, if I understand. The only issue is that if two accounts share the same first 20 digits, then at that point, if NXT is sent to that address, which account will it go to? Other than the possibility of transactions that are sent to you being "intercepted" by the other address sharing the 20 digits, your balance can't be spent.

[Come-from-Beyond]

I have now.

Tell me, how is that code used?

Because, and tell me if I am wrong:

I can send NXT from my wallet to any other wallet by inputting ONLY their 18/19/20 digit wallet key.

Anyone that can open their wallet that has that same 18/19/20 digit wallet key has access to those NXT.

Anyone that has access to those coins can move / spend those coins?

Each time a node sees a transaction it checks if it's the first time a public key used. If yes, then soft remembers this key, so next user with the same account id will get all transactions rejected.

As I said everything in Nxt is made on purpose. For example, brainwallet is used to protect users against Key disclosure law. Such strange method of getting an account id is made intentionally to protect ordinary people from government. How it's supposed to work is still waiting to be revealed.

[miztaziggy]

They will not see your balance, because the full 256-bits do not match, if I understand. The only issue is that if two accounts share the same first 20 digits, then at that point, if NXT is sent to that address, which account will it go to? Other than the possibility of transactions that are sent to you being "intercepted" by the other address sharing the 20 digits, your balance can't be spent.

Right, so they won't see my balance.

So tell me, or CfB, you tell me, I send my 1000 NXT to an address say 11111111111111111111.

How does the 'system' know that really I mean to send it to the address with the full key 11111111111111111111999999999999999999999 or the address with the full key 1111111111111111111155555555555555555

Let's say it doesn't and two of us (or more) can log into our own wallets. I have the one ending with the 9s and you have the one ending in the 5s.

How does it know that the coins are mine and not yours? How does it stop you spending those coins?

[opticalcarrier]

DONT GO POSTING THIS ANYWHERE UNTIL FIRM PEER REVIEW

First I will go over total combinations of all entities, then I'll go over the address violation between them.

Definitions:
Passphrase can be any 100 unicode chars
SHA256(passphrase) gives privateKey of 256 bits
Curve25519(privatekey) gives publicKey of 256 bits
SHA256(publickey) gives accountId of 256 bits
First 64 bits of accountId  is 20 digits visibleID (visible in the upper left of the client)

Combinations of different entities:
First, lets talk about passphrases.  Its unicode, but lets round down to the 97 characters available on my keyboard, between  letters  upper and lower, numbers, and symbols.  Actually, lets round that up to 100 for ease of future math.  So thats 100^100  or 1e+200 or
1000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000
different possible passphrases.  In reality this actual number of all possible unicode combinations is vastly vastly vastly larger due to what unicode actually allows, but lets just talk about terms of how we expect the system to be used.  IMO, for this mental exercise, it is very sufficient.

The total number of private keys, or total number of SHA256(passphrase) combinations, is 2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000

Total number of public keys, or number of different Curve25519(privatekey) combinations, is same as total number of private keys:  2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000


Total number of accountIds, or number of SHA256(public_key) combinations, is also same as total number of private keys: 2^256, or 1.15792e+77, I will round that down to 1e+77, or
100000000000000000000000000000000000000000000000000000000000000000000000000000

And total number of visibleIds, 2^64 is 1.84467E+19.  To try to account for rounding the others down I will round this one up to 2e+19, or or 20000000000000000000

Address violations:
First, with 1e+200 possible passphrases and 1e+77 possible private keys, we have 1e+123 passphrases that can each generate the same private key.  For accidental situations, I like these odds, as 1e+77 is waaaaaaaay more than the total number of users to ever use NXT.  For cracking though, its another deal.  Id have to do further math on the capability of current and future-predicted machines and their ability to crack this.

Second, Im not intimately familiar with the inner workings of sha/curve, so I cannot say for sure if each of the unique 1e+77 privatekeys will generate its own unique publickey for a 1 to 1 correspondance between all privatekeys and publickeys, and if each of the 1e+77 publickeys will generate its own unique addressId for a 1 to 1 correspondance between all entities. Id like an expert on sha/curve to comment here on these.

Third is the violation between the accountId and the visibleId. Of all the 1e+77 accountId's, 1e+58 of them have the same visibleId of 64bits.  1e+58 is 10000000000000000000000000000000000000000000000000000000000
Once again, for accidental situations, I like these odds, as 1e+58 is waaaaaaaay more than the total number of users to ever use NXT.  For cracking though, its another deal.  Id have to do further math on the capability of current and future-predicted machines and their ability to crack this.

Obviously, any brute force cracking involved here would be a triple-calculated operation of sha(curve(sha(passphrase))) and be done on all passphrases you wanted to crack on.

I think we all understand how the address space in the 1st case works.  That is straightforward.  The 3rd case though, seems to indicate that when someone sends NXT to a particular visibleID, that those funds are mirrored in the 1e+58 other accounts that share the same accountId and are available to be sent out once again from any of those other accounts.

But then something doesnt make sense to me b/c then if you add up all NXT from all different accounts, the running total sum of all accounts should be way greater than 1000000000!  But maybe the way you examine the blockchain doesn't work that way..

Really waiting on release of the source code (mind you I only completed java 1 and 2 in college, and did no more, so I dont believe Im the guy to review it)


ETA:  ok I see how that second address space violation is prevented in the first place.  See Jean-Luc's write up later on in this thread...

[Come-from-Beyond]

They will not see your balance, because the full 256-bits do not match, if I understand. The only issue is that if two accounts share the same first 20 digits, then at that point, if NXT is sent to that address, which account will it go to? Other than the possibility of transactions that are sent to you being "intercepted" by the other address sharing the 20 digits, your balance can't be spent.

Right, so they won't see my balance.

So tell me, or CfB, you tell me, I send my 1000 NXT to an address say 11111111111111111111.

How does the 'system' know that really I mean to send it to the address with the full key 11111111111111111111999999999999999999999 or the address with the full key 1111111111111111111155555555555555555

Let's say it doesn't and two of us (or more) can log into our own wallets. I have the one ending with the 9s and you have the one ending in the 5s.

How does it know that the coins are mine and not yours? How does it stop you spending those coins?

The system doesn't know that. But other user won't give u 11111111111111111111 as his account id.

[opticalcarrier]

They will not see your balance, because the full 256-bits do not match, if I understand. The only issue is that if two accounts share the same first 20 digits, then at that point, if NXT is sent to that address, which account will it go to? Other than the possibility of transactions that are sent to you being "intercepted" by the other address sharing the 20 digits, your balance can't be spent.

Right, so they won't see my balance.

So tell me, or CfB, you tell me, I send my 1000 NXT to an address say 11111111111111111111.

How does the 'system' know that really I mean to send it to the address with the full key 11111111111111111111999999999999999999999 or the address with the full key 1111111111111111111155555555555555555

Let's say it doesn't and two of us (or more) can log into our own wallets. I have the one ending with the 9s and you have the one ending in the 5s.

How does it know that the coins are mine and not yours? How does it stop you spending those coins?

The system doesn't know that. But other user won't give u 11111111111111111111 as his account id.

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

[Come-from-Beyond]

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.

[opticalcarrier]

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.

there has to be something you arent telling us.  this doesnt seem possible in our realm.

[artiface]

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.

Is this a new feature?

Also are you talking about only if 2 different passphrases accidentally generate the same account.  What about if 2 people use the same passphrase? 

[Come-from-Beyond]

Is this a new feature?

Also are you talking about only if 2 different passphrases accidentally generate the same account.  What about if 2 people use the same passphrase? 

This is not a new feature.

If 2 ppl use the same passphrase, they share the same account.

[opticalcarrier]

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.

Is this a new feature?

Also are you talking about only if 2 different passphrases accidentally generate the same account.  What about if 2 people use the same passphrase? 

no hes not talking about 2 different passphrases generating the same private key (because then they share the same public, account, and visible ID)  in effect those 2 particular passphrases ARE the SAME EXACT accounts, same thing if 2 people use the same passphrase

What we are discussing are results from 2 different sha256(PUBLICKEY) operations where 2 different public keys generate different accountIds but their 1st 64bits are the same

[Jean-Luc]

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.