Q:Is there a deterministic private-public keypair generator w/o the BIP32 issue?

gmaxwell

staff

Activity: 4172

Merit: 8419

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

Quote from: arnuschky on July 30, 2015, 09:13:31 AM

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

arnuschky

hero member

Activity: 517

Merit: 501

Quote from: Carlton Banks on July 31, 2015, 08:44:07 AM

Quote from: brianddk on July 31, 2015, 06:49:11 AM

Quote from: Carlton Banks on July 30, 2015, 08:02:45 PM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3071

Quote from: brianddk on July 31, 2015, 06:49:11 AM

Quote from: Carlton Banks on July 30, 2015, 08:02:45 PM

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

brianddk

jr. member

Activity: 47

Merit: 16

Quote from: Carlton Banks on July 30, 2015, 08:02:45 PM

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

Activity: 3430

Merit: 3071

Quote from: arnuschky on July 30, 2015, 09:13:31 AM

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 ?

Abdussamad

legendary

Activity: 3612

Merit: 1564

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

https://bitcointalksearch.org/topic/fastest-least-likely-to-be-subtly-broken-way-to-make-lots-of-addresses-offline-912337

posts 8 and 9 have what you need.

arnuschky

hero member

Activity: 517

Merit: 501

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.

stick

sr. member

Activity: 441

Merit: 266

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

stick

sr. member

Activity: 441

Merit: 266

Quote from: someone42 on July 30, 2015, 04:17:18 AM

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

sr. member

Activity: 441

Merit: 266

Quote from: brianddk on July 29, 2015, 07:46:08 PM

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

Yes. I need to publish private keys.

someone42

member

Activity: 78

Merit: 10

Chris Chua

Quote from: stick on July 29, 2015, 01:44:57 PM

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://bitcointalksearch.org/topic/new-hd-wallet-that-tolerates-leakage-of-some-child-private-keys-916441
The scheme described by Gus Gutoski will protect a parent private key from the release of a specific number of its child private keys.

brianddk

jr. member

Activity: 47

Merit: 16

Quote from: stick on July 29, 2015, 01:44:57 PM

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.

stick

sr. member

Activity: 441

Merit: 266

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)

Topic: Q:Is there a deterministic private-public keypair generator w/o the BIP32 issue? (Read 1682 times)