📅 Original date posted:2021-03-20
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
>
>
>
vjudeu [ARCHIVE] /
npub1mx…nqexn
2023-06-07 18:31:00
in reply to nevent1q…2r36
Author Public Key
npub1mxz2kkpp4z07x65rxwr6gsksd9cnwn0q22lx874t63dh6uulsy7qxnqexnPublished at
2023-06-07 18:31:00Event JSON
{
"id": "0e62536407f1f0b040b79f533984edf58597166c31a91b9ff58b28e5e1ec3ec4",
"pubkey": "d984ab5821a89fe36a833387a442d06971374de052be63faabd45b7d739f813c",
"created_at": 1686162660,
"kind": 1,
"tags": [
[
"e",
"69708790841c33eb579cf900d3977a71d1f4f272db7c13d1670b70f61a12c1cb",
"",
"root"
],
[
"e",
"31072343bd41613c36a27b358642f550ebcf9846395a82f56d769aac06d4ff9c",
"",
"reply"
],
[
"p",
"c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2"
]
],
"content": "📅 Original date posted:2021-03-20\n📝 Original message: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.\n\n\u003e On 2021-03-20 03:08:39 user Arik Sosman \u003cme at arik.io\u003e wrote:\n\u003e \u003e Hi Erik,\n\u003e \u003e \n\u003e \u003e 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.\n\u003e \u003e \n\u003e \u003e Best,\n\u003e \u003e Arik\n\u003e \u003e \n\u003e \u003e \u003e On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e \n\u003e \u003e \u003e use sha3-256. sha256 suffers from certain attacks (length extension,\n\u003e \u003e \u003e for example) that could make your scheme vulnerable to leaking info,\n\u003e \u003e \u003e depending on how you concatenate things, etc. better to choose\n\u003e \u003e \u003e something where padding doesn't matter.\n\u003e \u003e \u003e \n\u003e \u003e \u003e On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev\n\u003e \u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e \u003e\u003e \n\u003e \u003e \u003e\u003e I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0\n\u003e \u003e \u003e\u003e Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?\n\u003e \u003e \u003e\u003e If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:\n\u003e \u003e \u003e\u003e \n\u003e \u003e \u003e\u003e masterPublicKey = masterPrivateKey * G\n\u003e \u003e \u003e\u003e masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G\n\u003e \u003e \u003e\u003e masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )\n\u003e \u003e \u003e\u003e \n\u003e \u003e \u003e\u003e 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.\n\u003e \u003e \u003e\u003e _______________________________________________\n\u003e \u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e \n\u003e \u003e \n\u003e \n\u003e \n\u003e \n\u003e",
"sig": "149194f5721cee6fddc62ea13d10138ec439382c8cb12f2953ddd3008c079e85996cea88aa43548c4520973a7c72431fc568e812e575758cf793e7e68b01c197"
}