Published on: 2015-12-20T19:31:38+00:00
In a conversation between Olaoluwa Osuntokun and Rusty, they discussed the possibility of using cha cha encryption for their protocol. Olaoluwa suggested that packet lengths should be encrypted with a separate key in a similar way to the openssh's chacha20-poly3015 specification to keep the packet length and payload confidential. Rusty agreed and noted that timing and packet boundary measurement can still determine sizes. They also talked about handling limited re-transmission due to nodes going down, as the protocol assumes nodes store things persistently but packet loss and connection issues can occur. As the protocol is command/response-based, retransmission should be responded to by retransmitting the response.The discussion revolves around the concept of backwards-compatibility in edge wallets. The scenario starts with an edge wallet wanting to send funds over lightning to a particular address but is unable to connect directly. So, the wallet falls back on regular on-chain Bitcoin transactions. This mechanism provides a graceful fallback to on-chain transactions. The safety of this mechanism is discussed, where collisions of public-key hashes can occur. The network is viewed in two namespaces - global and local. In practice, it is safe as a global node ID conflict with the local mix-net ID doesn't undermine the propagation of an HTLC. A scenario is illustrated where Alice wishes to send funds to Dave, and her channel sub-graph has nodes Bob, Carol, and Estelle. A collision occurs between the 16-byte ID of Estelle's public key and Carol's ID. Bob gets the mix-header and processes it normally but realizes there's a collision in the local namespace. He sends the mix-header to Estelle first, who rejects it, resulting in Bob forwarding it to Carol, who accepts it, and everything continues as normal.Lastly, it is explained that Sphinx requires that the mix-net node IDs be of the same size as the MAC in the mix-header. If node IDs were 32-bytes, then poly3015 couldn't be used since its tag size is 16-bytes.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.The conversation revolves around the security and efficiency of using ChaCha20+poly1305 over AES-CTR+HMAC-SHA-256 in routing information for Sphinx mix-header. The debate also includes the safety of 128-bit and 192-bit node IDs, with the latter being suggested as a safer option based on certain musings. The current implementation of node IDs takes two forms: hash160 or raw serialized pub-key. Within the Sphinx mix-header, truncating the hash160 to 16 bytes is suggested, while ditching ChaCha20+poly3015 for AES-CTR+SHA-256-HMAC may be necessary if serialized pub-keys are used for node IDs in the routing info. It is also proposed to upgrade the crypto later by appending a key for a different system. The conversation ends on a positive note with everyone having fun.Zooko expresses his happiness for the direction of re-using prior work-SPHINX rather than inventing a new one. He also mentions about two options-AES-CTR + HMAC-SHA-256 and ChaCha20+poly1035 and prefers the latter. Regarding node ids, he is not sure how costly long node ids are in this context as well as how many node ids will exist in the long run. He suggests 192-bit nodeids based on some links he shared. He feels confident that 192-bit nodeids are safe enough.
Updated on: 2023-07-31T18:43:44.633572+00:00