Author: Zooko Wilcox-OHearn 2015-12-17 19:33:45
Published on: 2015-12-17T19:33:45+00:00
In an email exchange, Olaoluwa Osuntokun and Zooko discussed the current practice of node IDs taking two forms in code: either the hash160 of a node's current pub-key or the raw serialized pub-key itself. This is done to provide backwards compatibility for end wallets that are unable to establish a connection in a timely manner. Zooko requested further explanation on how this backwards-compatibility works and asked for documentation or a more detailed explanation if it is important. Osuntokun proposed that within the Sphinx mix-header, the hash160 should be safely truncated to 16-bytes, and in the case of a collision, the onion-route propagation across the incorrect node will fail as it won't be able to derive the shared secret properly. Zooko questioned the safety of this proposal, particularly in the case that an attacker knows a private key that maps to the same 128-bit nodeid as a user's private key does. Further, Osuntokun noted that if serialized pub-keys are used for node ID's in routing info, they would be forced to ditch chacha20+poly3015 for AES-CTR+SHA-256-HMAC within Sphinx. Zooko expressed confusion over 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.
Updated on: 2023-05-23T21:56:16.977038+00:00