📅 Original date posted:2021-03-20
📝 Original message:So, things have to be complicated to be 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). 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?
> 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
> >
> >
>
vjudeu [ARCHIVE] /
npub1mx…nqexn
2023-06-07 18:31:00
in reply to nevent1q…g2ya
Author Public Key
npub1mxz2kkpp4z07x65rxwr6gsksd9cnwn0q22lx874t63dh6uulsy7qxnqexnPublished at
2023-06-07 18:31:00Event JSON
{
"id": "e091b3834a41be4b9b3157263a24b7d6aee75b82429b67bb5c3938e72086477e",
"pubkey": "d984ab5821a89fe36a833387a442d06971374de052be63faabd45b7d739f813c",
"created_at": 1686162660,
"kind": 1,
"tags": [
[
"e",
"69708790841c33eb579cf900d3977a71d1f4f272db7c13d1670b70f61a12c1cb",
"",
"root"
],
[
"e",
"0e62536407f1f0b040b79f533984edf58597166c31a91b9ff58b28e5e1ec3ec4",
"",
"reply"
],
[
"p",
"d984ab5821a89fe36a833387a442d06971374de052be63faabd45b7d739f813c"
]
],
"content": "📅 Original date posted:2021-03-20\n📝 Original message:So, things have to be complicated to be 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). 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?\n\n\u003e On 2021-03-20 11:08:30 user Tim Ruffing \u003ccrypto at timruffing.de\u003e wrote:\n\u003e \u003e On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:\n\u003e \u003e \u003e is it safe enough to implement it and use in practice?\n\u003e \u003e \n\u003e \u003e This may be harsh but I can assure you that a HD wallet scheme that can\n\u003e \u003e be specified in 3 lines (without even specifying what the security\n\u003e \u003e goals are) should not be assumed safe to implement.\n\u003e \u003e \n\u003e \u003e Tim \n\u003e \u003e \n\u003e \u003e \n\u003e",
"sig": "068238149caaa8355d4adf49c8f30333a1e9043ea2d64948cc79a514b15e01e04abc7c79abfe2f60bb33a3f727e54329272d0835934b71e7acf80c87c30d12e6"
}