Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu <vjudeu@gazeta.pl>
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 20 Mar 2021 21:25:03 +0100
Message-Id: <126710959-a6df04a40ff13ff821cb6c67e5707bfb@pmq3v.m5r2.onet>
Subject: Re: [bitcoin-dev] An alternative to BIP 32?
Precedence: list

How length extension attack is possible here? The input of SHA-256 has cons=
tant 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, b=
ecause even if the second block of SHA-256 is the same all the times, the a=
ttacker still does not know the outcome of SHA-256, so the last round of SH=
A-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 alter=
native without relying on sha3? That should at the very least eliminate len=
gth extension attacks.
> > =

> > Best,
> > Arik
> > =

> > > On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev <bitcoin-d=
ev@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=3D5321992.0
> > >> Could anyone see any flaws in such design or is it safe enough to im=
plement it and use in practice?
> > >> If I understand it correctly, it is just pure ECDSA and SHA-256, not=
hing else:
> > >> =

> > >> masterPublicKey =3D masterPrivateKey * G
> > >> masterChildPublicKey =3D masterPublicKey + ( SHA-256( masterPublicKe=
y || nonce ) mod n ) * G
> > >> masterChildPrivateKey =3D masterPrivateKey + ( SHA-256( masterPublic=
Key || nonce ) mod n )
> > >> =

> > >> Also, it has some nice properties, like all keys starting with 02 pr=
efix and allows potentially unlimited custom derivation path by using 256-b=
it 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
> > =

> > =

> =

> =

> =

> =