From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8BBB2C0001 for ; Sat, 20 Mar 2021 20:30:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 7A0FF60703 for ; Sat, 20 Mar 2021 20:30:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK9Pbfd9ftH0 for ; Sat, 20 Mar 2021 20:30:17 +0000 (UTC) X-Greylist: delayed 00:05:02 by SQLgrey-1.8.0 Received: from smtpo51.poczta.onet.pl (smtpo51.poczta.onet.pl [213.180.142.182]) by smtp3.osuosl.org (Postfix) with ESMTPS id CB46D605FF for ; Sat, 20 Mar 2021 20:30:16 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4F2sh10cbgzllGxJ for ; Sat, 20 Mar 2021 21:25:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1616271905; bh=acOlQw7Il53Pp/qXJ7Y8JV6u7E/iG8Jy65nMUB1NYTk=; h=From:To:Date:Subject:From; b=Vz/1WkKErYnDdrXE9CwHlsxiK8NY0XRQw1DfQXoan3XWCdtd0l1bzA0IFikdv/0CM aJVjMttPFihybjW33K/vJVcuyorcXkr8NbZBuFKaWF1ZMixfkxm9Myk3VScn2UqxP5 6p8q+749W/+eNjrJIwco+rKuzRgmVffotJbl+lyU= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.253.132] by pmq3v.m5r2.onet via HTTP id 202103202124209120010001; Sat, 20 Mar 2021 21:25:05 +0100 From: vjudeu X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Sat, 20 Mar 2021 21:25:03 +0100 Message-Id: <126710959-a6df04a40ff13ff821cb6c67e5707bfb@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.253.132;PL;1 X-Mailman-Approved-At: Sat, 20 Mar 2021 21:00:48 +0000 Subject: Re: [bitcoin-dev] An alternative to BIP 32? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2021 20:30:21 -0000 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 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 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 > > > 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 > > = > > = > = > = > = > =