Bitcoin Forum
November 19, 2024, 01:03:23 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Ukbx -- deterministic private key generator  (Read 2064 times)
Ukigo (OP)
Jr. Member
*
Offline Offline

Activity: 42
Merit: 1000


View Profile
July 13, 2011, 02:09:19 PM
Last edit: December 09, 2018, 07:16:51 AM by Ukigo
 #1

Hi all !
samr7
Full Member
***
Offline Offline

Activity: 140
Merit: 430

Firstbits: 1samr7


View Profile
July 13, 2011, 02:40:50 PM
 #2

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?
samr7
Full Member
***
Offline Offline

Activity: 140
Merit: 430

Firstbits: 1samr7


View Profile
July 14, 2011, 12:07:08 AM
 #3

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 ?

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.
Enochian
Full Member
***
Offline Offline

Activity: 327
Merit: 124



View Profile
July 14, 2011, 03:14:01 AM
 #4

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.

TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1104


View Profile
July 14, 2011, 10:56:55 AM
 #5

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

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!