public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tim Ruffing <crypto@timruffing.de>
To: vjudeu <vjudeu@gazeta.pl>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative to BIP 32?
Date: Sun, 21 Mar 2021 22:45:19 +0100	[thread overview]
Message-ID: <616d3364b01dd392c86b7dbd1b6b6f5786bc7d67.camel@timruffing.de> (raw)
In-Reply-To: <126113469-4f8fddbc2594365c5558c0e75fa55917@pmq5v.m5r2.onet>

On Sat, 2021-03-20 at 21:25 +0100, vjudeu via bitcoin-dev wrote:
> So, things have to be complicated to be secure?

Not at all. But we first need to spend some thoughts on what "secure"
means before we can tell if something is secure.

>  By definition, using some private key, calculating some public key
> from it and incrementing that key is secure (it is definitely no
> worse than address reuse). 

If secure means that it does not hurt the unforgeability of ECDSA, then
I believe you're right.

> The only problem with using "privKey", "(privKey+1) mod n",
> "(privKey+2) mod n" and so on is that all of those public keys could
> be easily linked together. If that is the only problem, then by
> making offset deterministic but less predictable, it should be secure
> enough, right? So, instead of simple incrementation, we would have
> "privKey" (parent), "(privKey+firstOffset) mod n" (first child),
> "(privKey+secondOffset) mod n" (second child) and so on. And as long
> as this offset is not guessed by the attacker, it is impossible to
> link all of those keys together, right?

I believe this intuition is also a good first approach. So let's have a
look:  You say that offset = SHA256(masterPublicKey || nonce). Is this
predictable by the attacker? 

I can't really answer that question because it's not specified how
"nonce" is obtained.  Since this is supposed to be a deterministic
scheme, I see two basic ways: Either the master private key is involved
in the derivation of "nonce" (then "nonce" may be unpredictable) or
it's not (then "nonce" is predictable).  

Another fact that may or not be a problem is that it may be possible to
compute a parent private key from the a private key. Again, I can't
tell because I don't know how nonce is obtained. 	

Taking a step back, BIP 32 addresses all of these concerns. I agree it
could be simpler but I don't see a practical necessity to invent a new
scheme. In any application where this proposal could potentially be
used, BIP 32 could also be used and it's just good enough.

Tim 


> 
> > On 2021-03-20 11:08:30 user Tim Ruffing <crypto@timruffing.de>
> > wrote:
> > > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> > > > is it safe enough to implement it and use in practice?
> > > 
> > > This may be harsh but I can assure you that a HD wallet scheme
> > > that can
> > > be specified in 3 lines (without even specifying what the
> > > security
> > > goals are) should not be assumed safe to implement.
> > > 
> > > Tim 
> > > 
> > > 
> > 
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




  reply	other threads:[~2021-03-21 21:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 20:25 [bitcoin-dev] An alternative to BIP 32? vjudeu
2021-03-21 21:45 ` Tim Ruffing [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-03-22  7:51 vjudeu
2021-03-20 20:25 vjudeu
2021-03-19 19:46 vjudeu
2021-03-20  1:32 ` Erik Aronesty
2021-03-20  2:08   ` Arik Sosman
2021-03-22 12:05     ` Erik Aronesty
2021-03-20 10:08 ` Tim Ruffing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=616d3364b01dd392c86b7dbd1b6b6f5786bc7d67.camel@timruffing.de \
    --to=crypto@timruffing.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vjudeu@gazeta.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox