NXT :: descendant of Bitcoin - Updated Information

[wesleyh]

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Start page:

Can we get only "Login" and "Register" links here without the field  to enter any random password as first option?

After clicking "Login" then the user will be able to enter the old password.

Also, I think if the user chooses his own password, 35 is way too long.  Maybe drop that to 25

35 is what is shown in the current NRS client, I just took the same number.

I'm not a fan of only showing login and register links.

I could add a localStorage field that checks whether or not it's the first time you access the page and then and only then hide it? (Second time you get the field immediately)

[1714778385]

1714778385

[1714778385]

1714778385

[1714778385]

1714778385

[1714778385]

1714778385

[redsn0w]

The method ''diceware'' is the best method .

[NxtMinnow]

Wesleyh, Good work on the nxtra.org client.  I would like to be able to use my yubikey with a random static password that I append to a phrase.  If the random number generator is required that may not be possible.  Thoughts?

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Start page:

Can we get only "Login" and "Register" links here without the field  to enter any random password as first option?

[bitcoinpaul]

Ok, wesleyh. Great work! This is exactly what we need.

- we should clarify the security of this
- change the wording to "create" (instead of "register") and "passphrase of existing account" (instead of "passphrase") maybe

[gs02xzz]

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

what will happen if the user has already sent a fund to this less-than-15-chars-passphrase account but the fund has not been conformed and shown up in the balance yet? Should not allow to create a less than 35 chars pass phrase in the first place.

[pinarello]

WARNING !!!!!

I have stopped looking at NXT and you should consider the same.
It seems to be possible to generate NXT out of thin air  

Take a look at this account: http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=1739068987193023818
He sends around millions of NXT that he does not have. No problem doing this, because his account balance is able to become negative without any restriction.

If I would hold NXT i would feel betrayed.

Thank you for looking at the GENESIS BLOCK!

Just give him the password

[bitcoinpaul]

Just give him the password

This would blow his mind.

[Eadeqa]

electrum database. (1626 words)

Perfect.

hm, I'm not sure if that is perfect...
35 random characters (let's say from 50 different characters, numbers and signs) gives 10^59 possibilities.
12 words (or characters) out of 1626 are "only" 10^38 possibilites...

What do you mean "only" 10^59". That's more than 128-bits

Curve2519 is "only" 128 bit strong (2^128) (10^38)

There is no point in using a stronger password than 128 bits. If the attacker can crack 128-bit, they might just as well crack Curve2519 than cracking the password (your public key is available on the blockchain)

128-bit cannot be brute forced

http://en.wikipedia.org/wiki/Brute-force_attack

There is a physical argument that a 128-bit symmetric key is computationally secure against brute-force attack. The so-called Landauer limit implied by the laws of physics sets a lower limit on the energy required to perform a computation of kT  · ln 2 per bit erased in a computation, where T is the temperature of the computing device in kelvins, k is the Boltzmann constant, and the natural logarithm of 2 is about 0.693. No irreversible computing device can use less energy than this, even in principle.[2] Thus, in order to simply flip through the possible values for a 128-bit symmetric key (ignoring doing the actual computing to check it) would theoretically require 2128 − 1 bit flips on a conventional processor. If it is assumed that the calculation occurs near room temperature (~300 K) the Von Neumann-Landauer Limit can be applied to estimate the energy required as ~1018 joules, which is equivalent to consuming 30 gigawatts of power for one year. This is equal to 30×109 W×365×24×3600 s = 9.46×1017 J or 262.7 TWh (more than 1/100th of the world energy production).[citation needed] The full actual computation – checking each key to see if you have found a solution – would consume many times this amount. Furthermore, this is simply the energy requirement for cycling through the key space; the actual time it takes to flip each bit is not considered, which is certainly greater than 0.

[marcus03]

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

The first transaction of an account is always an incoming transaction and the secret for the recipient account is not needed for this first transaction. Thus, everytime NRS or a client would need a secret for an account and be able to reject it, it already does have at least one transaction.

[redsn0w]

What do you mean "only" 10^59". That's more than 128-bits

Curve2519 is "only" 128 bit strong (2^128) (10^38)

There is no point in using a stronger password than 128 bits. If the attacker can crack 128-bit, they might just as well crack Curve2519 then cracking the password

128-bit cannot be brute forced

http://en.wikipedia.org/wiki/Brute-force_attack

There is a physical argument that a 128-bit symmetric key is computationally secure against brute-force attack. The so-called Landauer limit implied by the laws of physics sets a lower limit on the energy required to perform a computation of kT  · ln 2 per bit erased in a computation, where T is the temperature of the computing device in kelvins, k is the Boltzmann constant, and the natural logarithm of 2 is about 0.693. No irreversible computing device can use less energy than this, even in principle.[2] Thus, in order to simply flip through the possible values for a 128-bit symmetric key (ignoring doing the actual computing to check it) would theoretically require 2128 − 1 bit flips on a conventional processor. If it is assumed that the calculation occurs near room temperature (~300 K) the Von Neumann-Landauer Limit can be applied to estimate the energy required as ~1018 joules, which is equivalent to consuming 30 gigawatts of power for one year. This is equal to 30×109 W×365×24×3600 s = 9.46×1017 J or 262.7 TWh (more than 1/100th of the world energy production).[citation needed] The full actual computation – checking each key to see if you have found a solution – would consume many times this amount. Furthermore, this is simply the energy requirement for cycling through the key space; the actual time it takes to flip each bit is not considered, which is certainly greater than 0.

In the future will able to bruteforce the password (most computers are strong, they will do many calculations)

[Come-from-Beyond]

Curve2519 is "only" 128 bit strong (2^128) (10^38)

Even worse. It's 126-bit strong.

[Eadeqa]

In the future will able to bruteforce the password (most computers are strong, they will do many calculations)

If in future computers can crack 128-bit passwords (highly unlikely), they might just as well attack curve25519 (much easier to crack) than random passwords.

[opticalcarrier]

One of the few interesting IT classes I took in uni was human/computer interaction, so here are my thoughts:

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Start page:

At the very least move the "not registered" link on top of the text box, not under it and make sure the program starts with the textbox NOT having focus. 

But my REAL suggestion is for the textbox to go away completely upon running of the program: to by default implement a wallet.dat type of wallet be implemented, with autogenerated if possible by browser (not keyboard/mouse movement input) 256bits of entropy stored on local file nxtwallet.dat as the key. Then on each boot, look for this file and if its not there, create a passphrase and store it.  Dont even show the passphrase to the user.  Then make access to manual brainwallet passphrase entry require a bit of work to get to, with warnings along the way.  And then reject any brainwallet passphrase under 15 characters unless that account already has a published public key.  If brainwallet is used, then just create a null nxtbrainwallet.dat file and upon boot, if your program detects a null nxtbrainwallet.dat file, then skip the part where you look for nxtwallet.dat, and autoprompt for a passphrase.

also, provide ability for user to convert back from brainwallet to using any previously-saved nxtwallet.dat file in case they do have some NXT in there.

also, provide ability for user to encrypt nxtwallet.dat file, just like the BTC wallet does.  But make it apparent that this encryption key is NOT in any way associated with brainwallet.

I wish some big whale would offer a nice bounty for someone to open source a client with all my listed requirements - this is really what NXT does need.  In a big way.  You would only get bounty after successful source audit.

Would also need some way to audit updates.

Whales???

ETA: by just hiding the passphrase from user in wallet.dat you can use 25 words in the dictionary. Or whatever is required to obtain max usable entropy

[marcus03]

electrum database. (1626 words)

Perfect.

hm, I'm not sure if that is perfect...
35 random characters (let's say from 50 different characters, numbers and signs) gives 10^59 possibilities.
12 words (or characters) out of 1626 are "only" 10^38 possibilites...

Each word from the electrum dictionary adds ln(1626)/ln(2) = 10.66 bits of entropy, so 12 words give you 128 bits of entropy.

[Eadeqa]

Curve2519 is "only" 128 bit strong (2^128) (10^38)

Even worse. It's 126-bit strong.

Even more reasons not to force users to use stronger passwords than required. 12 words from 1626 dictionary is 128-bit strength. No one is cracking it anytime soon -- if at all, as long as the random number generated is secure and working fine.

[wesleyh]

Wesleyh, Good work on the nxtra.org client.  I would like to be able to use my yubikey with a random static password that I append to a phrase.  If the random number generator is required that may not be possible.  Thoughts?

I bring forward a motion for Jean-Luc to modify the NRS client to check string length of the passphrase and reject it if less than 15 characters AND it has zero transactions. (dont want to lock out any people that do have NXT with a 15 char password)

Here's my new logic for my client http://nxtra.org/nxt-client (to be available later today, not yet uploaded)

Start page:

Can we get only "Login" and "Register" links here without the field  to enter any random password as first option?

I have no idea how a yubikey works, sorry.

[Come-from-Beyond]

Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.

[BrianNowhere]

electrum database. (1626 words)

Perfect.

hm, I'm not sure if that is perfect...
35 random characters (let's say from 50 different characters, numbers and signs) gives 10^59 possibilities.
12 words (or characters) out of 1626 are "only" 10^38 possibilites...

What do you mean "only" 10^59". That's more than 128-bits

Curve2519 is "only" 128 bit strong (2^128) (10^38)

There is no point in using a stronger password than 128 bits. If the attacker can crack 128-bit, they might just as well crack Curve2519 than cracking the password (your public key is available on the blockchain)

128-bit cannot be brute forced

http://en.wikipedia.org/wiki/Brute-force_attack

There is a physical argument that a 128-bit symmetric key is computationally secure against brute-force attack. The so-called Landauer limit implied by the laws of physics sets a lower limit on the energy required to perform a computation of kT  · ln 2 per bit erased in a computation, where T is the temperature of the computing device in kelvins, k is the Boltzmann constant, and the natural logarithm of 2 is about 0.693. No irreversible computing device can use less energy than this, even in principle.[2] Thus, in order to simply flip through the possible values for a 128-bit symmetric key (ignoring doing the actual computing to check it) would theoretically require 2128 − 1 bit flips on a conventional processor. If it is assumed that the calculation occurs near room temperature (~300 K) the Von Neumann-Landauer Limit can be applied to estimate the energy required as ~1018 joules, which is equivalent to consuming 30 gigawatts of power for one year. This is equal to 30×109 W×365×24×3600 s = 9.46×1017 J or 262.7 TWh (more than 1/100th of the world energy production).[citation needed] The full actual computation – checking each key to see if you have found a solution – would consume many times this amount. Furthermore, this is simply the energy requirement for cycling through the key space; the actual time it takes to flip each bit is not considered, which is certainly greater than 0.

I have a question about this.

If the password cracker knows what dictionary you are using, couldn't they just make a database of these words and cycle through every possible combination of said words instead of cycling through letter by letter?  

In this way, each word would be the same as one letter is when brute forcing the normal way, making a ten word brain wallet effectively as insecure as a ten letter password using a 1600 letter alphabet.

In short, the hacker could take a shortcut by not cycling though letter by letter, instead cycling through word by word.

If effect:  dog water lipstick tiger monkey phone hat seven ornery plastic

would be looked for by starting with

1. aardvark aardvark aardvark aardvark aardvark aardvark aardvark aardvark aardvark aardvark
2. aardvark aardvark aardvark aardvark aardvark aardvark aardvark aardvark aardvark abbot

and so on....

if someone brute forces using "word chunks" instead of singles letters does this change the level of security? Especially if they know what database you are using and that the program uses ten words?

[bidji29]

A newcomer need to pass through 5 steps before having access to an account number.

- Launch the client
- Click on "Not registered? Click here!"
- Move his mouse arround
- Land on a complicated message. Then, copy a set of of 12 word (That's the worst step. Not user-friendly at all )
- Then recopy those word to finally have an account number



This solution is an improvment of course but I think a wallet.dat is really needed if we want to touch a wider audience.

With a wallet.dat. There is only ONE step :

-Launch the client

WE NEED THIS

Wesley i'm ready to donate another 40k NXT to you if you implement it

[bitcoinpaul]

At the very least move the "not registered" link on top of the text box, not under it and make sure the program starts with the textbox NOT having focus. 

+1

- change the wording to "create" (instead of "register") and "passphrase of existing account" (instead of "passphrase") maybe

In the future, there should be an option for a wallet file. But this is great for now!