In the end, it would be an inconvenience for large stakeholders but for nothing.
TF is going ahead the way it was planned regardless so why not take these pointless discussions to a new topic?
He requested information and I tried to give it to him.
Topic: NXT :: descendant of Bitcoin - Updated Information - page 424. (Read 2761638 times)
TF is going ahead the way it was planned regardless so why not take these pointless discussions to a new topic?
He requested information and I tried to give it to him.
Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.
What is his draft exactly? Some of his suggestions wouldn't make sense now.
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?
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?
Yes, and now calculate the combinations and come back with the number
I have not the math skills to do even this.
1600 * 10 = 16,000
ok, I'm lost.
I was just wondering if the security level is the same if you change the brute force method in this way or if it decreases at all.
you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.
Eventually the new clients will go widestream and security will improve.
Guys, KISS (not literally).
And don't force people. Make a big hint and if they still want to choose a short passphrase, then let it be.
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?
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?
Yes, and now calculate the combinations and come back with the number
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?
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 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.
Huh? I never mentioned yubikey. I think that's for 2-factor authentication. It won't even work with Nxt as Nxt is local login to NRS.
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.
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.
you 2 bring basically the same argument. We are in a state a flux right now - the current NRS client has no restrictions, and we have some new clients coming out. I say the new clients should implement the restrictions I listed NOW. Then if the case you bring where the user creates an low-entropy passphrase then sends funds to it somehow, they are using NRS *ANYWAYS*; it doesnt matter that the new clients have restrictions.
Eventually the new clients will go widestream and security will improve.
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!
Quote
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
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
Quote
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?
Any suggestions about Parallel Chains? If not then I'll stick to BCNext's draft.
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?
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 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.
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.
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.
One of the few interesting IT classes I took in uni was human/computer interaction, so here are my thoughts:
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
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
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.
Curve2519 is "only" 128 bit strong (2^128) (10^38)
Even worse. It's 126-bit strong.
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
Quote
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)
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.
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
Quote
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.
Jump to: