š
Original date posted:2015-12-17
š Original message:
On Thu, Dec 17, 2015 at 6:08 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Currently, in our code, node ID's take two forms: either the hash160
> (Bitcoin style) of a node's current pub-key or the raw serialized pub-key
> itself. This is done such that "nodeID at host" locators explicitly provide a
> level of backwards (p2pkh) compatibility for end wallets that are unable to
> establish a connection in a timely manner.
I'm afraid I don't understand how this backwards-compatibility works,
so if it is important that I understand it please point me to docs or
explain it more.
> Within the Sphinx mix-header, I think we should be safely able to truncate
> this (the hash160) to 16-bytes. In the case of a collision, the onion-route
> propagation across the incorrect node will simply fail, as it won't be able
> to properly derive the shared secret.
Do you mind explaining why you think this is safe? I don't understand
how it could be safe, in the case that the attacker knows a private
key that maps to the same 128-bit nodeid as a user's private key does.
> Otherwise, we'd be forced to ditch chacha20+poly3015 for
> AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
> ID's in the routing info.
I don't understand why the use of entire public keys instead of
possibly-truncated hashes of public keys would force a decision about
which cipher and MAC to use.
Sincerely,
Zooko
Zooko Wilcox-OHearn [ARCHIVE] /
npub1z4ā¦684vc
2023-06-09 12:45:27
in reply to nevent1qā¦7smx
Author Public Key
npub1z4nwmaam6z2a4mszqjl2fh0g402xfsnsehcctnxrr62mqa9agc9sv684vcPublished at
2023-06-09 12:45:27Event JSON
{
"id": "3cd2ee5ba1303c0478cea73212ade6827e74910d66a362ea591811822a0e82d5",
"pubkey": "1566edf7bbd095daee0204bea4dde8abd464c270cdf185ccc31e95b074bd460b",
"created_at": 1686314727,
"kind": 1,
"tags": [
[
"e",
"a0eae0709b098880fb92a837f655fe2ac84b7ed07fa439abcde3b595cd8022fc",
"",
"root"
],
[
"e",
"accc4bdfbdc5ae6214b0fb82c50c3b000b09babb95f2d5ee93dd2b300a83c811",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "š
Original date posted:2015-12-17\nš Original message:\nOn Thu, Dec 17, 2015 at 6:08 PM, Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e wrote:\n\u003e\n\u003e Currently, in our code, node ID's take two forms: either the hash160\n\u003e (Bitcoin style) of a node's current pub-key or the raw serialized pub-key\n\u003e itself. This is done such that \"nodeID at host\" locators explicitly provide a\n\u003e level of backwards (p2pkh) compatibility for end wallets that are unable to\n\u003e establish a connection in a timely manner.\n\nI'm afraid I don't understand how this backwards-compatibility works,\nso if it is important that I understand it please point me to docs or\nexplain it more.\n\n\u003e Within the Sphinx mix-header, I think we should be safely able to truncate\n\u003e this (the hash160) to 16-bytes. In the case of a collision, the onion-route\n\u003e propagation across the incorrect node will simply fail, as it won't be able\n\u003e to properly derive the shared secret.\n\nDo you mind explaining why you think this is safe? I don't understand\nhow it could be safe, in the case that the attacker knows a private\nkey that maps to the same 128-bit nodeid as a user's private key does.\n\n\u003e Otherwise, we'd be forced to ditch chacha20+poly3015 for\n\u003e AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node\n\u003e ID's in the routing info.\n\nI don't understand why the use of entire public keys instead of\npossibly-truncated hashes of public keys would force a decision about\nwhich cipher and MAC to use.\n\nSincerely,\n\nZooko",
"sig": "ee141fd1c35c0f72bbe3b0556a9a4ede22e355a35ea2e19cf80de2f10878cd8bebe82ad70e024f379e3c1d1a3094de737b8580bce0d4b22d6da16b91e8b7ab1c"
}