Zooko Wilcox-OHearn [ARCHIVE] on Nostr: š Original date posted:2015-12-17 š Original message: On Thu, Dec 17, 2015 at ...
š
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
š 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