📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 10:25 AM, Timo Hanke wrote:
> Since you mention to use this in conjunction with the payment protocol,
> note the following subtlety. Suppose the payer has to paid this address
> called "destination":
>> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
>> checksum)
> Also suppose the payee has spent the output, i.e. the pubkey
> corresponding to "destination", which is PubKeyParent * Multiplier[i],
> is publicly known. Then anybody can (in retrospect) create arbitrary
> many pairs {PublicKeyParent, Multiplier} (in particular different
> PublicKeyParent) that lead to the same "destination".
>
> Depending on what you have in mind that the transaction should "prove"
> regarding its actual receiver or regarding the receiver's PubKeyParent,
> this could be an unwanted feature (or it could be just fine). If it is
> unwanted then I suggest replacing
> PubKeyParent * Multiplier[i] by
> PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
> which eliminates from the destination all ambiguity about PubKeyParent.
>
> This modification would not be directly compatible with BIP32 anymore
> (unfortunately), but seems to be better suited for use in conjunction
> with a payment protocol.
>
> Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to "prove" [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:03:30
in reply to nevent1q…kq3d
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:03:30Event JSON
{
"id": "c3fa3b91bc00a8f7793da4f3e05be26109f278f90ead1c9c6d2b6b0df55d0b42",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150210,
"kind": 1,
"tags": [
[
"e",
"60c63b2d935c09c2d6c618c7776de45a3225391d6d5c2bbb728d2b54da18fc56",
"",
"root"
],
[
"e",
"5a1a97f02d01a0f1a4d73f524832bd1f32e34a86b24ef76e69a42939975bf0da",
"",
"reply"
],
[
"p",
"6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f"
]
],
"content": "📅 Original date posted:2013-06-19\n📝 Original message:On 06/19/2013 10:25 AM, Timo Hanke wrote:\n\u003e Since you mention to use this in conjunction with the payment protocol,\n\u003e note the following subtlety. Suppose the payer has to paid this address\n\u003e called \"destination\": \n\u003e\u003e Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||\n\u003e\u003e checksum)\n\u003e Also suppose the payee has spent the output, i.e. the pubkey\n\u003e corresponding to \"destination\", which is PubKeyParent * Multiplier[i],\n\u003e is publicly known. Then anybody can (in retrospect) create arbitrary\n\u003e many pairs {PublicKeyParent, Multiplier} (in particular different\n\u003e PublicKeyParent) that lead to the same \"destination\".\n\u003e\n\u003e Depending on what you have in mind that the transaction should \"prove\"\n\u003e regarding its actual receiver or regarding the receiver's PubKeyParent,\n\u003e this could be an unwanted feature (or it could be just fine). If it is\n\u003e unwanted then I suggest replacing\n\u003e PubKeyParent * Multiplier[i] by \n\u003e PubKeyParent * HMAC(Multiplier[i],PubKeyParent)\n\u003e which eliminates from the destination all ambiguity about PubKeyParent.\n\u003e\n\u003e This modification would not be directly compatible with BIP32 anymore\n\u003e (unfortunately), but seems to be better suited for use in conjunction\n\u003e with a payment protocol. \n\u003e\n\u003e Timo\n\nIt's an interesting observation, but it looks like the most-obvious\nattack vector is discrete log problem: spoofing a relationship between\na target public key and one that you control. For instance, if you see\n{PubA, Mult} produces PubB and you have PubC already in your control\nthat you want to \"prove\" [maliciously] is related to PubB, then you have\nto find the multiplier, M that solves: M*PubC = PubB. That's a\ndiscrete logarithm problem.\n\nI'm not as familiar as you are, with the available operations on\nelliptic curves, but it sounds like you can produce essentially-random\npairs of {PubX, Mult} pairs that give the same PubB, but you won't have\nthe private key associated with those public keys. It's an interesting\npoint, and there may be a reason to be concerned about it. Though, I\ndon't see it yet.\n\n-Alan",
"sig": "c4141cc2d732b79e67a639ec1c56556d3f10e8742515cc938f7a848c967bd733ff2a5eb5923c4e1289ef758da4c64f14373e02351d024cee6239f41c0da49771"
}