📅 Original date posted:2021-03-21
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tim Ruffing [ARCHIVE] /
npub1cm…dwkls
2023-06-07 18:31:00
in reply to nevent1q…vttr
Author Public Key
npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwklsPublished at
2023-06-07 18:31:00Event JSON
{
"id": "1d6ebe3a0e74e3b0d870fd4ae96dfbd76b0ea04499b905e67767e33caace8df0",
"pubkey": "c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2",
"created_at": 1686162660,
"kind": 1,
"tags": [
[
"e",
"69708790841c33eb579cf900d3977a71d1f4f272db7c13d1670b70f61a12c1cb",
"",
"root"
],
[
"e",
"e091b3834a41be4b9b3157263a24b7d6aee75b82429b67bb5c3938e72086477e",
"",
"reply"
],
[
"p",
"d984ab5821a89fe36a833387a442d06971374de052be63faabd45b7d739f813c"
]
],
"content": "📅 Original date posted:2021-03-21\n📝 Original message:On Sat, 2021-03-20 at 21:25 +0100, vjudeu via bitcoin-dev wrote:\n\u003e So, things have to be complicated to be secure?\n\nNot at all. But we first need to spend some thoughts on what \"secure\"\nmeans before we can tell if something is secure.\n\n\u003e By definition, using some private key, calculating some public key\n\u003e from it and incrementing that key is secure (it is definitely no\n\u003e worse than address reuse). \n\nIf secure means that it does not hurt the unforgeability of ECDSA, then\nI believe you're right.\n\n\u003e The only problem with using \"privKey\", \"(privKey+1) mod n\",\n\u003e \"(privKey+2) mod n\" and so on is that all of those public keys could\n\u003e be easily linked together. If that is the only problem, then by\n\u003e making offset deterministic but less predictable, it should be secure\n\u003e enough, right? So, instead of simple incrementation, we would have\n\u003e \"privKey\" (parent), \"(privKey+firstOffset) mod n\" (first child),\n\u003e \"(privKey+secondOffset) mod n\" (second child) and so on. And as long\n\u003e as this offset is not guessed by the attacker, it is impossible to\n\u003e link all of those keys together, right?\n\nI believe this intuition is also a good first approach. So let's have a\nlook: You say that offset = SHA256(masterPublicKey || nonce). Is this\npredictable by the attacker? \n\nI can't really answer that question because it's not specified how\n\"nonce\" is obtained. Since this is supposed to be a deterministic\nscheme, I see two basic ways: Either the master private key is involved\nin the derivation of \"nonce\" (then \"nonce\" may be unpredictable) or\nit's not (then \"nonce\" is predictable). \n\nAnother fact that may or not be a problem is that it may be possible to\ncompute a parent private key from the a private key. Again, I can't\ntell because I don't know how nonce is obtained. \t\n\nTaking a step back, BIP 32 addresses all of these concerns. I agree it\ncould be simpler but I don't see a practical necessity to invent a new\nscheme. In any application where this proposal could potentially be\nused, BIP 32 could also be used and it's just good enough.\n\nTim \n\n\n\u003e \n\u003e \u003e On 2021-03-20 11:08:30 user Tim Ruffing \u003ccrypto at timruffing.de\u003e\n\u003e \u003e wrote:\n\u003e \u003e \u003e On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:\n\u003e \u003e \u003e \u003e is it safe enough to implement it and use in practice?\n\u003e \u003e \u003e \n\u003e \u003e \u003e This may be harsh but I can assure you that a HD wallet scheme\n\u003e \u003e \u003e that can\n\u003e \u003e \u003e be specified in 3 lines (without even specifying what the\n\u003e \u003e \u003e security\n\u003e \u003e \u003e goals are) should not be assumed safe to implement.\n\u003e \u003e \u003e \n\u003e \u003e \u003e Tim \n\u003e \u003e \u003e \n\u003e \u003e \u003e \n\u003e \u003e \n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "3ada34ee2e3845d9f69092b35f264f359a28e49574765af468c4343803efb5c9c5b62058eca7ba9d282263d0b73932f550013c79cfdf25832bb0192e70f7e2bc"
}