It's interesting to look at the scenario "ECDLP is broken (via QC or whatever), how does that affect BIP32".

Basically: any xpub shared is complete and total break of your wallet, realistically. Example: you share xpub of account; whether derivation is hardened (usual for accounts) or not, all child private keys are leaked, i.e. every single future and past private key for your addresses in that account. You don't even need to have spent, first.

Otoh if xpub is never shared, (1/n)

· · Web · 1 · 3 · 3

.. I believe you have defence via HMAC against a break of any more than the obvious (i.e. the key you exposed via signature/spend).

Realistically of course this makes bip32 broken, as used today.

An interesting tidbit is just seeing a *signature* (not even a pubkey) 100% reveals privkey in this ECDLP-easy scenario, which may be relevant for some protocols.

It also makes all NUMS-based constructions fail completely (example: confidential transactions -> invisible inflation). (2/n)

I'm setting aside many other practical considerations that have been discussed ad nauseam elsewhere, just looking a little bit at the crypto. It's quite tempting to study further but it's really a bit silly, *public* key crypto is called that for a reason :) (3/3)

I would like to read more about this. Could you please point me in the right direction? Thanks waxwing

@jdb sure; all the details of BIP32 are in the spec:

It takes a while to get used to the notation, but it's explained at the start. note in particular 'k' for arbitrary secret keys (scalar numbers) and 'point(k)' for elliptic curve points corresponding (so K =kG).

You just have to go through the logic, but change the assumption that it is impossible to extract 'k', given only 'K'.

Sign in to participate in the conversation
unidentified instance

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!