From: vjudeu <vjudeu@gazeta•pl>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] An alternative to BIP 32?
Date: Sat, 20 Mar 2021 21:25:03 +0100 [thread overview]
Message-ID: <126710959-a6df04a40ff13ff821cb6c67e5707bfb@pmq3v.m5r2.onet> (raw)
How length extension attack is possible here? The input of SHA-256 has constant length of 512 bits in this scheme. And if someone will get some child public key, there is still no way to reverse it to the parent public key, because even if the second block of SHA-256 is the same all the times, the attacker still does not know the outcome of SHA-256, so the last round of SHA-256 is unknown and doing calculations backwards seems to be impossible.
> On 2021-03-20 03:08:39 user Arik Sosman <me@arik•io> wrote:
> > Hi Erik,
> >
> > Would sha256-hmac(nonce, publicKeyPoint) still be a suitable/safe alternative without relying on sha3? That should at the very least eliminate length extension attacks.
> >
> > Best,
> > Arik
> >
> > > On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > >
> > > use sha3-256. sha256 suffers from certain attacks (length extension,
> > > for example) that could make your scheme vulnerable to leaking info,
> > > depending on how you concatenate things, etc. better to choose
> > > something where padding doesn't matter.
> > >
> > > On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev
> > > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > >>
> > >> I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0
> > >> Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?
> > >> If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:
> > >>
> > >> masterPublicKey = masterPrivateKey * G
> > >> masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G
> > >> masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )
> > >>
> > >> Also, it has some nice properties, like all keys starting with 02 prefix and allows potentially unlimited custom derivation path by using 256-bit nonce.
> > >> _______________________________________________
> > >> bitcoin-dev mailing list
> > >> bitcoin-dev@lists•linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists•linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
>
>
>
next reply other threads:[~2021-03-20 20:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 20:25 vjudeu [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-21 21:45 ` Tim Ruffing
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=126710959-a6df04a40ff13ff821cb6c67e5707bfb@pmq3v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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