Published on: 2015-10-06T22:35:01+00:00
In a conversation between Anthony Towns and Rusty Russell regarding the development of the Lightning Network, several updates and changes were made to the code. Russell disabled the use of flip_key() in onion_key.c and made the 02/03 prefix explicit instead. He also modified the "Message for blah..." by serializing the public key before converting it into hex. Additionally, he made tweaks to onion_key to optimize its performance. Russell reworked the test_onion and Makefile test on Github to separate generate and decode. He suggested including the python version as well. The conversation also touched upon the need to document the Lightning protocol and technology decisions through an RFC or wiki.On October 6th, 2015, Russell posted on Github about the changes made to the test_onion and Makefile test. Anthony Towns questioned the use of flip_key() in onion_key.c and its necessity for single-use onion-msg-keys. They also discussed the usage of AES128 and agreed that using both halves of a sha for iv and pad_iv could save computational resources. They considered reducing the message size from the arbitrary 128 bytes to either 96 or 64 bytes.Anthony Towns commented on the code repository of ElementsProject/Lightning, pointing out that a significant portion of the Python lines were only used for determining y given x and ECDH with y as well as x. He also mentioned the lack of implementation of export-friendly encryption mode. However, he submitted a pull request addressing this issue, which was acknowledged and merged into the project by Rusty Russell. The conversation also revolved around the identification of lightning nodes, where they are identified by the full 512 bit or 257 bit public key used for routing. AES128 only utilizes the first half of the calculated enckey, iv, and pad_iv. The libsecp256k1 already performs a sha256 on the ecdh secret, resulting in hmac/enckey/etc being sha256'ed twice. The message size of 128 bytes and the assumption of 20 hops were deemed arbitrary and could potentially be reduced.In an email conversation in October 2015, Anthony Towns discussed his attempt at reimplementing a program in Python, expressing initial frustration but later reporting successful decoding/forwarding using pyelliptic. He provided command line outputs and noted that the Python version required fewer lines of code compared to the C version. He also made a pull request on Github for the updated code.In another email exchange, Richard Kiss and aj discussed a problem with libsec256k1, where openssl only provides the x value, making it difficult to determine the correct secret directly. Richard suggested using his open-source library pycoin to obtain Y from X. Aj implemented ECDH directly by performing a single EC_POINT_mul operation but encountered a bug when checking evenness. To make ECDH more compatible with alternative implementations, aj added a comment to an existing secp256k1 pull request suggesting the use of only the x value when creating secrets.In a separate email thread, Anthony Towns expressed frustration over an implementation issue in Python but successfully implemented the decoding/forwarding process using pyelliptic. He mentioned running the HMAC twice instead of calculating y and shared command lines for testing.The context also mentioned the Lightning Network project's implementation of test onion routing code. The current code is fixed at 3840 bytes but will be switched to a non-fixed size using protobufs. Random EC key pairs are generated for each hop, and the public key for each hop is included in plaintext. ECDH is used to establish a shared secret with each hop, and symmetric AES & HMAC keys are derived based on the secret. Lightning nodes are identified by their full 512-bit or 257-bit public keys used for routing. The code also implements encryption methods such as AES128 counter mode, HMAC using SHA256, and Bitcoin's EC with ECDH.
Updated on: 2023-07-31T18:23:00.080497+00:00