I have read 3 threads about deterministic wallet - mostly theory was there.
My goal is to build tool for predefined keys, not wallet as a whole.
Those keys after creation will be possible to import in different wallets,
in diff. combinations, even with alternative Bitcoin client.
This will be not so easy with proposed deterministic wallet.
Currently i am working on another PBKDF2 based solution.
Coming soon.
Topic: Ukbx -- deterministic private key generator (Read 2047 times)
Good point
Thanks a lot .
yesterday a have dig out Python stuff for PBKDF2.
Below scheme i consider to implement :
1) User input 4 params : passphrase, hash function (maybe complex one) ,
some input for salt, number of iterations.
2) application generate key from that user input, using hash of 3rd parameter
as long enough pseudorandom salt. (whirlpool or sha512)
3) number of iterations will be between 30000 and 100000.
Probably enough secure.
But this system will create only 1 key, right ?
What if we will pick 1 key say every 1777 iterations , starting from 30000th iteration.
With such approach we can have a lot of keys quite securely created from ONLY
3 parameters.
Any thoughts ?
yesterday a have dig out Python stuff for PBKDF2.
Below scheme i consider to implement :
1) User input 4 params : passphrase, hash function (maybe complex one) ,
some input for salt, number of iterations.
2) application generate key from that user input, using hash of 3rd parameter
as long enough pseudorandom salt. (whirlpool or sha512)
3) number of iterations will be between 30000 and 100000.
Probably enough secure.
But this system will create only 1 key, right ?
What if we will pick 1 key say every 1777 iterations , starting from 30000th iteration.
With such approach we can have a lot of keys quite securely created from ONLY
3 parameters.
Any thoughts ?
There are two threads on "deterministic wallet" and one has a way to allow generation of the public and private part separately.
If you have master public key, you can generate the public key that matches a particular number. However, to spend the money, you need the master private key.
This would allow a wallet that can generate lots of addresses to accept money but not spend it (you would need the private key for that).
If you have master public key, you can generate the public key that matches a particular number. However, to spend the money, you need the master private key.
This would allow a wallet that can generate lots of addresses to accept money but not spend it (you would need the private key for that).
Since your private key can't be recovered from your public key or address, it's safe to generate one private key, which is a 256 bit integer, and just use consecutive integers starting from there as additional private keys.
The starting private key can just be the hash of your passphrase. Anything more complicated than this is overkill, unless you plan to give one of the private keys to someone else.
The starting private key can just be the hash of your passphrase. Anything more complicated than this is overkill, unless you plan to give one of the private keys to someone else.
Quote
It's interesting idea about using PBKDF2 .
I miss this variant.
But given BlackBerry vulnerability and others similar issues how to do it right ?!
Which implementation of PBKDF2 is the best in your opinion ?
Is encfs doing it right way ?
I miss this variant.
But given BlackBerry vulnerability and others similar issues how to do it right ?!
Which implementation of PBKDF2 is the best in your opinion ?
Is encfs doing it right way ?
Implementing PBKDF2 isn't hard, you just have to pick good parameters. There are three:
- Hash function
- Salt
- Iteration count
Example -- WiFi WPA/WPA2 PSK uses SHA1, 4096 iterations, salted with the SSID.
Example -- TrueCrypt uses RIPEMD160 (or others), 1000 or 2000 iterations, and a large random salt.
Example -- Linux LUKS uses SHA1 (or others), a varying number of iterations based on CPU power (>100000), and a large random salt.
BlackBerry screwed up by choosing only a single iteration, making their keys vulnerable to brute forcing.
For this application, since you want the password to convert directly to the private key without any other stored parameters, your options are more limited. Salting will offer little added security because you'll have to choose an empty salt or a constant salt. However, you can opt for a huge number of iterations, and it would be quite secure.
Clever idea!
The shell script doesn't work because I seem to be missing a tool called xxd.
The wrtpm program doesn't seem to do anything that absolutely requires ec_lcl.h. For example, it will directly access eckey->group, but this can be done with the public API EC_KEY_get0_group(). Likewise, pub_key can be accessed using EC_KEY_get0_public_key().
Have you considered using PBKDF2 to produce the private keys?
The shell script doesn't work because I seem to be missing a tool called xxd.
The wrtpm program doesn't seem to do anything that absolutely requires ec_lcl.h. For example, it will directly access eckey->group, but this can be done with the public API EC_KEY_get0_group(). Likewise, pub_key can be accessed using EC_KEY_get0_public_key().
Have you considered using PBKDF2 to produce the private keys?
Hi all !
Jump to: