Author: Rusty Russell 2015-09-22 10:38:08
Published on: 2015-09-22T10:38:08+00:00
Zooko Wilcox-OHearn requested for notes about requirements/desiderata which Rusty provided. The network is a source routing network where the sender details the payment path, since fees vary with path and the sender pays. To minimize knowledge of any part of the network for financial privacy reasons, an onion routing-style setup where each node only knows prev and next seems most sensible. Rusty is currently working on test code which works like so: there are one node hop and full route description in the onion structure. The receive on a node works by using ECDH on onion→hop[0]→pubkey and my privkey to extract the secret key, then deriving enckey (SHA256(seckey || 0)), hmackey (SHA256(seckey || 1)), iv (SHA256(seckey || 2)) and pad_iv (SHA256(seckey || 3)). After checking HMAC of every part of struct onion after hmac (including pubkey) and decrypting (AES 256 CTR mode, using enckey and iv above) struct onion from pubkey onwards, first struct hop is for us and to forward, remove first hop, and append padding (thus keeping total length the same). Finally, padding is generated by AES-256-CTR encrypting all-zeroes with enckey and pad_iv, resulting in even final node having no idea of path length. However, generating this onion correctly is a bit tricky, but it is perfectly possible. Unused hops are filled with random garbage.
Updated on: 2023-05-23T20:11:36.959294+00:00