Bitcoin Forum
March 28, 2024, 12:16:33 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Q:Is there a deterministic private-public keypair generator w/o the BIP32 issue?  (Read 1678 times)
stick (OP)
Sr. Member
****
Offline Offline

Activity: 441
Merit: 266



View Profile
July 29, 2015, 05:44:57 PM
 #1

HD Wallets have a flaw that revealing a private key and its parent master public key will reveal its parent master private key. (Described here[1] and here[2]).

Isn't there a similar concept with master public key and master private key that does not suffer from this issue. (Does not have to be ECDSA. I just want a deterministic private-public keypair generator that can publish its master public key).

[1] https://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/

[2] https://eprint.iacr.org/2014/998.pdf (chapter 3)

"If you don't want people to know you're a scumbag then don't be a scumbag." -- margaritahuyan
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
brianddk
Jr. Member
*
Offline Offline

Activity: 47
Merit: 16


View Profile WWW
July 29, 2015, 11:46:08 PM
 #2

HD Wallets have a flaw that revealing a private key and its parent master public key will reveal its parent master private key. (Described here[1] and here[2]).

Isn't there a similar concept with master public key and master private key that does not suffer from this issue. (Does not have to be ECDSA. I just want a deterministic private-public keypair generator that can publish its master public key).

[1] https://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/

[2] https://eprint.iacr.org/2014/998.pdf (chapter 3)
Does the use case that you are working on really require sharing private keys?  I understand that some saw BIP32 as a way to insulate some private keys from other private keys, but it seems like as long as you keep all private keys private, that there is no BIP32 risk exposure.
someone42
Member
**
Offline Offline

Activity: 78
Merit: 10

Chris Chua


View Profile
July 30, 2015, 08:17:18 AM
 #3


HD Wallets have a flaw that revealing a private key and its parent master public key will reveal its parent master private key. (Described here[1] and here[2]).

Isn't there a similar concept with master public key and master private key that does not suffer from this issue. (Does not have to be ECDSA. I just want a deterministic private-public keypair generator that can publish its master public key).
Depending on what your use case is, this might be useful: https://bitcointalk.org/index.php?topic=916441.0
The scheme described by Gus Gutoski will protect a parent private key from the release of a specific number of its child private keys.
stick (OP)
Sr. Member
****
Offline Offline

Activity: 441
Merit: 266



View Profile
July 30, 2015, 10:08:55 AM
 #4

Does the use case that you are working on really require sharing private keys?

Yes. I need to publish private keys.

stick (OP)
Sr. Member
****
Offline Offline

Activity: 441
Merit: 266



View Profile
July 30, 2015, 10:09:36 AM
 #5

The scheme described by Gus Gutoski will protect a parent private key from the release of a specific number of its child private keys.

That is exactly the paper I linked in the original post. My usecase needs to publish lots of private keys, so this is not usable.

stick (OP)
Sr. Member
****
Offline Offline

Activity: 441
Merit: 266



View Profile
July 30, 2015, 10:10:13 AM
 #6

I was pointed that ID-based cryptography might do the trick.

arnuschky
Hero Member
*****
Offline Offline

Activity: 517
Merit: 501


View Profile
July 30, 2015, 01:13:31 PM
 #7

Isn't that what hardened keys are for? From BIP32:

Quote
One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.
Abdussamad
Legendary
*
Offline Offline

Activity: 3584
Merit: 1560



View Profile
July 30, 2015, 09:28:05 PM
 #8

arnuschky is right. See this thread for a detailed discussion:

https://bitcointalk.org/index.php?topic=912337.0

posts 8 and 9 have what you need.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3068



View Profile
July 31, 2015, 12:02:45 AM
 #9

Isn't that what hardened keys are for? From BIP32:

Quote
One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

Does this mean that knowledge of a Trezor account private key + pertaining xpub = xpriv ?

Vires in numeris
brianddk
Jr. Member
*
Offline Offline

Activity: 47
Merit: 16


View Profile WWW
July 31, 2015, 10:49:11 AM
 #10

Does this mean that knowledge of a Trezor account private key + pertaining xpub = xpriv ?
I didn't think that it was possible to obtain knowledge of a Trezor priv key.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3068



View Profile
July 31, 2015, 12:44:07 PM
 #11

Does this mean that knowledge of a Trezor account private key + pertaining xpub = xpriv ?
I didn't think that it was possible to obtain knowledge of a Trezor priv key.

assuming that at least one private key is leaked

Vires in numeris
arnuschky
Hero Member
*****
Offline Offline

Activity: 517
Merit: 501


View Profile
July 31, 2015, 02:56:25 PM
 #12

Does this mean that knowledge of a Trezor account private key + pertaining xpub = xpriv ?
I didn't think that it was possible to obtain knowledge of a Trezor priv key.

assuming that at least one private key is leaked

Trezor uses a BIP44-style wallet layout (they proposed BIP44, actually).
That means, your Trezor stores a HD wallet structure as follows:

Code:
m / purpose' / coin_type' / account' / change / address_index

The ' means a hardened. The maximum level that you can trace back to is therefore "change",
under which all addresses are generated that your Trezor uses for the given account.
Thus,  if you leak a private key of one of your addresses, you'd endanger all keys of
that account but not the master/root key.

Note that Trezor doesn't let you export the private leaf keys.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4158
Merit: 8343



View Profile WWW
July 31, 2015, 06:17:29 PM
 #13

I responded to this here: https://www.reddit.com/r/Bitcoin/comments/3f1y35/q_is_there_a_deterministic_privatepublic_keypair/ctkj4ff

But this is not currently compatible with Bitcoin (and due to the high verification costs for BLS signatures I dunno if I'd rank it pretty highly).

Isn't that what hardened keys are for? From BIP32:

Quote
One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

This isn't compatible with the question's requirement "can publish its master public key".
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!