Bitcoin Forum

Can someone here with better knowledge re Cryptography and security than me (or anyone on NXT forum it seems) please answer this:

NXT receiving address is 20 characters long made up of only numbers - therefore 10^20 combinations.

Passwords to open wallets can be many more characters, therefore many many more combinations to open only 10^20 possible wallets.

Secret phrase can be any 100 unicode chars.

SHA256(secret_phrase) gives private key.
Curve25519(private_key) gives public key.
SHA256(public_key) gives account id.
First 64 bits give VISIBLE account id.


Now, if I send coins to one account using their VISIBLE account ID (20 characters long) which is all that is required with NXT, then multiple passwords can open a wallet with the SAME visible account ID.

Apparently, the first account to send those coins on has ownership.

What am I missing here?

An opportunity to make lots of money.

I won't speak on how many hash collisions there are without doing the math myself but one thing I'd like to point out is that NXT addresses can be 18 to 20 digits long (As far as I know that is, the gap could be bigger). This increases the amount of possible addresses significantly.

Isn't it 1-20 digits for account?

Is it? I've never seen NXT addresses shorter than 18 digits but I suppose my sample size isn't exactly huge.

Still, compare the number of possible 'wallets' with the number of possible passwords.

The number of collisions is HUGE.

Screams EXTREMELY badly designed coin to me and backs up what I have thought all along, that this coin is a scam.

U should post here ur math from nextcoin.org. It will make someone's day. :)

Here is 16 digits
http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=5914888228532337

Look at this - http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=648774468

This thing has been a poorly designed cashgrab since day 1.

So how does that affect chances of collision?

I keep seeing posts from you with no real answers. Never answers. The closest you have got is a post saying "wait until the source revealed and all will be clear".

It really is like one of those auctions where a guy tries to sell you a black box that looks like it contains something valuable, without actually telling you what's inside. When you buy it and open it, it's just junk.

I did answer ur questions. Sorry, but my English is not so good to explain something that requires knowledge of statistics or crypto. Any chance u speak Russian?

You spoke good enough english in the thread you argued that BTC was insecure because of a 10^24 chance of collision, whereas it's 10^20 with NXT. How does that figure?

This from the NXT thread:

Did u read my answer on nextcoin.org? I bet no, coz u again compare 10^24 apples with 10^20 oranges.

This is my thought exactly and if the dev wants NXT to grow and stick around, they need to fix this. I was just thinking about this yesterday. Migrating to a new addressing system seems like a tough transition though from my limited knowledge.

Edit: Nevermind, just read the dev's response. Although I must say it is somewhat misleading for those who don't know that part of the address is hidden. I'm guessing the reason for this is that your mapping system isn't alphanumerical, thus to make things easier on the eyes you provide only that.

But what would happen if the first 20 digits of two addresses happen to be the same, and someone sends NXT to that address? That still seems risky of a conflict occurring.

Ok, I'll repeat again. Add some math. What are the odds that u get the same address within a short period of time?

Yes it seems all it takes is the correct passphrase to open any wallet.  

I learned that the hard way, lost just about 30,000 nxt because my password was too easy. I saw in front of my eyes someone send my coins to a new account.  I've triple checked my machine and there is no back door or keylogger (if there was I think they would have gone for my btc first before the nxt anyday).  Someone used the same password as me and therefore they were able to spend all my coins.  

I didn't understand that the password was network wide, I thought it was local to my machine only so it was simple, despite the warning.

No. That requires little changes.

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

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

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.

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.

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

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

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.



See above.



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.



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



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



No. And u failed to give a mathematical proof.

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.

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

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.


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.

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

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.

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 (http://en.wikipedia.org/wiki/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.

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?

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

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

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.

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.

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

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.

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.

So it is all good ?

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.

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.

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

BCNext/CfB: very slick

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!  8)
Or stop spreading bullshit here  >:(

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

Nxt has different types of transactions (http://localhost:7874/nxt?requestType=getConstants). 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.

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

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.

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

yer talking about the secret?

No, about my signature.

can someone who has a reddit account post in the thread http://www.reddit.com/r/CryptoCurrency/comments/1rxtvs/nextcoinorg_new_nxt_forums/cdtuqum (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.

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?

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

I need moooar nxt  ;D

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.

Do u like riddles?

Alias System allows to create memorable addresses for payments, like "johnsmith". In Nxt everything is made on purpose...

I'm not saying the Alias System, but the 20 digits visible ID truncated from the full public key.

I think it shouldn't act like what you say as prevent user from generating conflicted id when the first 20 digital happened to be the same.

But give the user the longer id to distinguish between existing and and new created one.

For example, if there was an existing id 11111111111111111111 with full key 11111111111111111111xxxxxxxx

then you generated a new id with full key 11111111111111111111yyyyyy which conflict in the first 20 digits

the system should give you the id 11111111111111111111y instead of rejecting you from creating new id.

In short, this mechanism should be like an embedded first-bit service that supported in blockchain.info.

OH, I thought I was wrong.

The first-bit mechanism still have to use full key to send coin in the first time.

But for NXT, you can send coin to the short id even if the id was not used.

So it cannot be a mechanism like first-bit.

So...WTF is the purpose of 20 digits visibleID?

First I thought it was first bit mechanism but now I am not so sure.......

Only BCNext knows.

Just say most people will have a 20 number digit for account transfer. as OP pointed out that the possibility of account passphrase comparing to account id is much higher.
I didn't go through every single reply here, so i hope that my explanation hasn't been posted already.

I would say what happens is that when necessary, the account id will + or - a digit to cover all possible collisions of same account with different passphrase, the 20 digit is just a normal number for easier remembering or what ever it is for later on. so with this formulae you don't need to worry about such collisions ever to happen.

And this could be the reason why you don't see quadrillions of total nxt in the blockchain.

So if someone tries to create an account for which the first 64bits collide with an existing account then this account will be rejected?

- did you bother to read this thread?
https://bitcointalk.org/index.php?topic=366105.msg3911357#msg3911357

I finally found it! written by BCNext.

I first thought it would simply extend one extra digit to be visible to label it as a completely different account.
eg. The full 192bit = "123456789”  First account created will be normal with first 64bit showing eg "123456"
and collision account will have few extra bits visible to differentiate from the first account eg. showing "1234567"
But then i don't know anything about programming so this was just my logical guess.

Here is what BCNext said.


From my understanding is that, what this mean if collision ever happened, the 2nd account created will become a mirrored version of the first account. You can see it but you can't touch it. Making it useless. Same meaning as a disabled account, so you can't do anything with it.

Thanks for the clear answer :-)

This is still not clear to me.

Basically, the account number is only 64-bit. The full 256-bit would secure your account if you use that account to send some transaction.

If someone has never used their account for sending transaction but only for receiving money,  brute forcing that account would  be equivalent to brute forcing 64-bit encryption/key.

Wow.

If true, that would be serious security hole. 64-bit is nothing.

A custom built machine can break all these unused accounts with money in it (but have never been used to send transactions) with a week  

Please fix this

a week?   ::)

It is true and it is not bug. It is feature. You are welcome to open account №100000  with 100'000NXT onboard for a week ;)

DES (predeseccor of AES) was 56 bit. In 2008 COPACOBANA reduced the time to break DES to less than one day, using 128 Spartan-3 5000's. Currently SciEngines RIVYERA holds the record in brute-force breaking DES, having utilized 128 Spartan-3 5000 FPGAs. Their 256 Spartan-6 LX150 model has even lowered this time.

64-bit is only 8 times stronger than 56-bit.

64-bit is not secure, especially when  money is involved and off line attack is possible.

Make the accounts at least 80 bit, but 128-bit would be much better.

Break DES in less than a single day
http://www.sciengines.com/company/news-a-events/74-des-in-1-day.html


And that was back in 2009, 5 years ago.

How is weak security a "feature"?

Please explain this to me: If someone has never used their account to send transaction, the atttacker needs to brute only first 64-bit to take over that account.

If the account has been used to send a transaction, then all 256-bit are required to take over the  account.

Is that true? Am I missing something?

If yes, please update the site with a fair warning that  new accounts must send at least one  transaction. Their so-called 30 char password isn't really 30 char. It's only (much smaller) 64-bit (around 11 chars with A-Z letters in caps/small and 0-9 digitis).   

I did not know this before reading this thread.

Someone might just invest a few thousand dollars, never send a transactions, and that account then is open to brute forcing 64-bit

Is there any DES in NXT? Or do you think that all 64bit crypto are the same?

It''s irrelevant whether algorithm is DES or BBC or NBC or ZZZ ... the attack is brute force. Given NXT uses SHA 2 for hashing, and SHA 2 has zillion of custom ASIC  hardware (due to bitcoin mining popularity),  the attacker only needs to brute force first 64-bit of SHA 2 hash.

This is not good for Nxt if there is a large scale successful attack that successfully starts  stealing from unused accounts with money in it.

That will be real real bad publicity and kill the project.


 

It is made on purpose.
True.
True.True. Nothing.
What site? NXT is decentralized, there is no official site for it.
It is good habit to read before asking.
Right.
Have you any math for how fast it can be done? Or are your words a fantasy?
Have anybody stealed 100'000NXT from account №100000? Why not?
BTW, have you studied how many such 64bit protected accounts are now in blockchain? (hint - somebody already did this work for you).
Cry, little girl, cry.

Thank you for your competent opinion.

What you fail to understand is that in order to brute force an unsecured account requires not only SHA asics, but also curve ASICS, which there are none of now.  but like as has been stated many times for you already here, this is intentional; to allow 'mining' of lost NXT in the future.

We are actively trying to educate people of the risk of not having any transaction associated with an account.  LOL yes, in 1 week of cracking you can have that account with 100,000 NXT sitting in it.  its account number is 00000000000000100000 so go for it, you have 1 week if NXT is so unsecure

That's bad design.  It should have been at least 80 bits. That  would have made bruteforce 65 thousand times slower.  



No, there is "official" site where you can download the official software/client. The network is decentralized.



No, it's not a fantasy. 64-bit is 2^64 and that is not a strong enough number in 2014 against brute force -- especially where off line attacks is possible (like wifi password or truecrypt container).  64-bit is good for online accounts (like gmail) where brute force is detectable.


Instead of idiotically defending it, you should demand that Nxt developers increase the security to 128-bits

Really?

How on earth would you know if these are "lost" coins and not someone coins who has been saving them for say his grand kids?

RIF.  Ill repeat it since you didnt get it the first time


so just dont let it sit like that

If you are doing it actively, then good, but I found out about it only in this thread. I have been to official site. Saw nothing about it on main page or in their forum.

Why we have to repeat you simple things? There is no official site.
Sorry, you provided no math, only fantasies.

There is official site where you download the official softwares from the developer.

If you don't understand that  2 ^64  is small number for 2014 security demands,  then you need  more help than I can offer

n/a

It is this site - BTT, but here is not official site, only official thread.
If you cannot prove your words with math then they are bs.

This proves that 2^64 is safe - http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem

Now, prove me wrong.

Show us the math.


256 times.


It is relevant. To estimate the amount of time needed to compute something, you don't simply estimate the number of operations (2^64). You also estimate the time needed per operation. Show us your estimates.

You make a claim, that

The burden of proof of that claim lies with you.

Earlier Jean-Luc posted an estimate of 8000 per second based on his Java van-gen. (Sorry, I don't have the post handy to quote). But that's a bad estimate, an attacker is not going to be generating addresses using Java! In practice, it will be much higher.


A lot of what's in the protocol seems dangerous for casual users. That's how I felt at first too. But as I understand it now, the design philosophy is to keep the protocol clean. Protections are then placed at the client level instead, to prevent people from screwing things up. I've been helping with some of these (e.g. future account numbers will have a different format, with error detection and correction). It's just at the current stage of dev, folks aren't seeing all these client-level protections yet.

Ultimately, the purpose of only 64bit protection for accounts without outgoing transaction is to allow nxt owned by folks who got in early, but don't have any real interest in it (e.g. they just saw it as another free crypto being given out in a giveaway thread) to be recovered in future, rather than forever be inaccessible. There's still plenty of time (imo, even months is plenty of time) for folks to secure their accounts before their nxt is at any real risk.



Yeah, that's an additional risk one would have to accept, if one invested without doing their homework. It used to be clear that this is beta software with a lot of risks, but I think the marketing side has gained a lot of steam lately. But we're not trying to scam people. This is an unfortunate side-effect of our decentralized organization (which again should be clear to anyone who did their homework before buying in).


I've been writing wiki pages on how to verify the SHA256 checksum and how to choose secure password. IMO these are greater priority that 64 bit address collisions, since nxt has been stolen due to spoofed clients and insecure passwords, but I've not heard any report of nxt lost to address collision.

My time and energy are limited (and I haven't received a single nxt for my work so far). Personally, I've found the education about this sufficient (in proportion to the risk). I've also found it to be not a big deal yet. I let my (at the time) ~250 USD worth of nxt sit for many weeks in an unprotected account, with full knowledge of the situation and consequences, before I registered an alias and secured it.

If you feel that this issue needs more attention, you could help us by editing the wiki, or telling the webmasters, increasing awareness of this issue through other means :)

 64-bit is not considered secure.  56 bit DES was broken in 22 hours in 1999. 64-bit would be 256 times stronger but we are in 2014 now

I agree that it depends on how fast curve25519 can be performed. SHA 2 has specialized ASIC hardware due to bitcoin mining popularity so the bottleneck would be curve25519.

If it was just SHA2, this thing

http://www.butterflylabs.com/monarch/

would break every single unused account in database in less than one year

curve25519 part will slow this down, and I don't know how fast curve25519 is on GPUs/CPUs

Ive actually put in a feature request to the NXT devs to print a warning upon opening an acct that doesnt have a public key associated with it.  There are already some other similar operations in the source code that do similar things upon opening an account, so this wont be too complex to get put in.

It's still secure enough for a couple of years. This was the point - to use security that could be broken in foreseeable future.

Eadeqa, you have not answered this:


As you said:


If you want to make the case that unprotected account numbers will be broken soon (sooner than what we think), you should provide estimates of this. i.e. how fast hardware accelerators will reach the market, how fast will they grow fast (pardon the pun). There is currently little economic incentive in this, only a fraction of the total ~70 mil USD worth of nxt is unprotected. Compare that to the huge numbers of people doing bitcoin mining and propping up the SHA256 ASIC manufacturers.

I just got that warning, and eventually found this thread explaining it. It seems to make creating an account more complex. You can't just create it and send a ton of money to it. You have to:

• Create the account.
• Send a small amount of money to it, that you wouldn't mind losing.
• Wait for it to confirm so you can spend it.
• Spend it.
• Send the rest of the money to it, like you wanted to do in the first place.
  

Five steps instead of one, plus it costs you a transaction fee. Is that intentional? Do you not want it to be free to start using NXT securely? If it were free, then clients could register the public key automatically without bothering the user.

Incidentally, one of the nice features of Bitcoin is that sending coins to an address does not reveal that address's public key. Only spending from it does. Where-as with NXT, every account's public key is known. It's a tiny bit less secure; or will be, if anyone ever cracks elliptical curve cryptography (as with the legendary quantum computer). I guess you aren't worried about it, but to me it does seem like a small step backwards.

Brangdon:

First of all, welcome to NXT, mate.

Second, this is Grandmas thread, last post was at the end of Jan and some things have changed since then, particularly now that NXT has 2 really good, much more secure clients available.

Have a look at NXT's new forum:
https://nxtforum.org/index.php

and take a look at the NXT clients section.

You can skip step 2, 3, 4, and add step 6 "create an alias". Cracking a single 64-bit account still takes a long time (300  years with 1 billion searches per second)  so it's not as if your account will be in danger of getting cracked after 1 minute of confirmation wait. 

Creating an alias is what I did in step 4. It charged me a 1 NXT fee, so surely I had to transfer some money in first?

1. Create account
2. Fund it
3. spend anything (atm 1NXT minimum)

done

no need to partially send funds