I would be already happy when a website would offer the signature verification tool. It was a very quick and easy way to copy paste a signature and check it there. Wallets and coinig need 3 times copy past, including carefully chosing the signs to copy.
I would like to have this tool. I don't need anything other that was on brainwallet.org. I guess bringing that tool online would be no risk at the moment right? So hopefully someone does.
Topic: --- (Read 1307 times)
By the way, just saying: https://keybase.io/warp has been around for more than a year and it seems to do a pretty decent job.
Scroll to the bottom of their page and they have a BTC20 wallet with an unsolved passphrase.
By the way, just saying: https://keybase.io/warp has been around for more than a year and it seems to do a pretty decent job.
Instead of this:
I would do:
Or perhaps even:
And make the 216 scrypt iterations depend on PIN as well.
hmac_sha256 is stronger than just plain sha256, and mixing in the original passphrase every iteration (instead of just hashing the previous hash value) could avoid some loss of entropy.
GUI-wise I would initially only show the address, and hide the private key (WIF + QR) with a button "Show Private Key".
Code:
for(n=1;n<=PIN;n++) {passphrase=sha256(passphrase+salt)}
I would do:
Code:
for (n=1; n≤PIN; n++) { passphrase = hmac_sha256(passphrase, PIN+salt) }
Or perhaps even:
Code:
key = '';
for (n=1; n≤PIN; n++) { key = hmac_sha256(key+passphrase, PIN+salt) }
for (n=1; n≤PIN; n++) { key = hmac_sha256(key+passphrase, PIN+salt) }
And make the 216 scrypt iterations depend on PIN as well.
hmac_sha256 is stronger than just plain sha256, and mixing in the original passphrase every iteration (instead of just hashing the previous hash value) could avoid some loss of entropy.
GUI-wise I would initially only show the address, and hide the private key (WIF + QR) with a button "Show Private Key".
To brute force every 2-character alphanumeric passphrase with no salt, you would have to run the scrypt function 38.4 billion times (each with 2^16 iterations). Adding an email address as your salt could make it impractical to brute force.
In my short test, the time-consuming part (at least in the javascript implementation) seems to be the iteration of the PIN. Now by your construction one doesn't have to brute-force this part, since computing this part for PIN=9999999 will also compute this part for all smaller PINs.
Wouldn't it be better to just append the PIN to the salt and instead increase the number of scrypt iterations until the code has roughly the same run-time as before with a seven digit PIN?
Jump to: