Timo Hanke [ARCHIVE] on Nostr: 📅 Original date posted:2013-06-19 📝 Original message:On Wed, Jun 19, 2013 at ...
📅 Original date posted:2013-06-19
📝 Original message:On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
> 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.
Correct, for a given PubC in advance you can't create such a "malicious"
relation to PubB. You can only "reversely" construct new PubC from given
PubB.
> 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.
Depends on who is "you". The arbitrary person who produces {PubX, Mult}
won't have the private key, but the person who knows the private key for
PubA will have it (assuming that PubB was computed from {PubA, Mult} in
the first place).
In the end, it all depends on your application. What proves enough for
one party doing repeated transactions with another may not suffice for a
third party doing auditing. On the other hand, ambiguity about PubA may
just as well be a wanted feature for deniability reasons.
Timo
--
Timo Hanke
PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
Published at
2023-06-07 15:03:34Event JSON
{
"id": "5c096b3d7c30bae809b1f3f6440f265b7bf3c7029e15a23b1a9daf9e5468eb4a",
"pubkey": "6b41dfcce682764d40c00fd6580a99614b6bbe8a8332085dea07afbc47ba9e8f",
"created_at": 1686150214,
"kind": 1,
"tags": [
[
"e",
"60c63b2d935c09c2d6c618c7776de45a3225391d6d5c2bbb728d2b54da18fc56",
"",
"root"
],
[
"e",
"b462e1ff6aa4b37a5c6aba8afdc0a2e6bfea900349545f9794b61798ce6c727e",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2013-06-19\n📝 Original message:On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:\n\u003e On 06/19/2013 10:25 AM, Timo Hanke wrote:\n\u003e \u003e Since you mention to use this in conjunction with the payment protocol,\n\u003e \u003e note the following subtlety. Suppose the payer has to paid this address\n\u003e \u003e called \"destination\": \n\u003e \u003e\u003e Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||\n\u003e \u003e\u003e checksum)\n\u003e \u003e Also suppose the payee has spent the output, i.e. the pubkey\n\u003e \u003e corresponding to \"destination\", which is PubKeyParent * Multiplier[i],\n\u003e \u003e is publicly known. Then anybody can (in retrospect) create arbitrary\n\u003e \u003e many pairs {PublicKeyParent, Multiplier} (in particular different\n\u003e \u003e PublicKeyParent) that lead to the same \"destination\".\n\u003e \u003e\n\u003e \u003e Depending on what you have in mind that the transaction should \"prove\"\n\u003e \u003e regarding its actual receiver or regarding the receiver's PubKeyParent,\n\u003e \u003e this could be an unwanted feature (or it could be just fine). If it is\n\u003e \u003e unwanted then I suggest replacing\n\u003e \u003e PubKeyParent * Multiplier[i] by \n\u003e \u003e PubKeyParent * HMAC(Multiplier[i],PubKeyParent)\n\u003e \u003e which eliminates from the destination all ambiguity about PubKeyParent.\n\u003e \u003e\n\u003e \u003e This modification would not be directly compatible with BIP32 anymore\n\u003e \u003e (unfortunately), but seems to be better suited for use in conjunction\n\u003e \u003e with a payment protocol. \n\u003e \u003e\n\u003e \u003e Timo\n\u003e \n\u003e It's an interesting observation, but it looks like the most-obvious\n\u003e attack vector is discrete log problem: spoofing a relationship between\n\u003e a target public key and one that you control. For instance, if you see\n\u003e {PubA, Mult} produces PubB and you have PubC already in your control\n\u003e that you want to \"prove\" [maliciously] is related to PubB, then you have\n\u003e to find the multiplier, M that solves: M*PubC = PubB. That's a\n\u003e discrete logarithm problem.\n\nCorrect, for a given PubC in advance you can't create such a \"malicious\"\nrelation to PubB. You can only \"reversely\" construct new PubC from given\nPubB.\n\n\u003e I'm not as familiar as you are, with the available operations on\n\u003e elliptic curves, but it sounds like you can produce essentially-random\n\u003e pairs of {PubX, Mult} pairs that give the same PubB, but you won't have\n\u003e the private key associated with those public keys. \n\nDepends on who is \"you\". The arbitrary person who produces {PubX, Mult}\nwon't have the private key, but the person who knows the private key for\nPubA will have it (assuming that PubB was computed from {PubA, Mult} in\nthe first place).\n\nIn the end, it all depends on your application. What proves enough for\none party doing repeated transactions with another may not suffice for a\nthird party doing auditing. On the other hand, ambiguity about PubA may\njust as well be a wanted feature for deniability reasons.\n\nTimo\n\n-- \nTimo Hanke\nPGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8",
"sig": "1fba61227618a16aebac1f6dbea9cf28d6819f36ff358362fb742823a6fde0c9391a43a475b9ea1b34feeb0bf5dbcd2b51f144b283eea7c46361320015a7722d"
}