From tomokio203 at gmail.com Tue Nov 27 21:31:53 2018 From: tomokio203 at gmail.com (tock203) Date: Wed, 28 Nov 2018 06:31:53 +0900 Subject: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol In-Reply-To: References: Message-ID: Awesome, thanks! I merged it. https://github.com/nayutaco/lightning-dissector My understanding is that ~/.lightning/keys.log will contain the last sk only. Is it correct? If so, lightning-dissector can't decrypt .pcap which contains both messages before key rotation and messages after key rotation. To support decrypting such .pcap, ~/.lightning/keys.log should contain a few of recent sk. I recommend you to follow this key log format. https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file By following this, you can reuse KeyLogSecretFactory instead of to implement ClightningSecretFactory. 2018?11?27?(?) 20:12 daniel : > c-lighting-dissector work now: > https://github.com/arowser/lightning/tree/dissector > https://github.com/arowser/lightning-dissector > ./configure --enable-dissector && make -j > > > On Thu, Nov 8, 2018 at 10:39 AM Christian Decker < > decker.christian at gmail.com> wrote: > >> Would it be possible to query a command line program or a JSON-RPC call >> to get the secret? In that case we could add it to the `listpeers` output. >> >> On Wed, Nov 7, 2018 at 6:43 AM tock203 wrote: >> >>> We implemented the latter scheme. lightning-dissector already supports >>> key rotation. >>> FYI, here's the key log file format lightning-dissector currently >>> implements. >>> https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file >>> >>> Whenever key rotation happens(nonce==0), lightning node software write >>> 16byteMAC & key of "first BOLT packet". >>> When you read .pcap starts with a message whose nonce is not 0, the >>> messages can not be decrypted until the next key rotation. >>> >>> The current design is as described above. Because it is a provisional >>> specification, any opinion is welcome. >>> >>> 2018?11?6?(?) 16:08 Olaoluwa Osuntokun : >>> >>>> Hi tomokio, >>>> >>>> This is so dope! We've long discussed creating canned protocol >>>> transcripts for >>>> other implementations to assert their responses again, and I think this >>>> is a >>>> great first step towards that. >>>> >>>> > Our proposal: >>>> > Every implementation has compile option which enable output key >>>> information >>>> > file. >>>> >>>> So is this request to add an option which will write out the _plaintext_ >>>> messages to disk, or an option that writes out the final derived >>>> read/write >>>> secrets to disk? For the latter path, it the tools that read these >>>> transcripts >>>> would need to be aware of key rotations, so they'd be able to continue >>>> to >>>> decrypt the transact pt post rotation. >>>> >>>> -- Laolu >>>> >>>> >>>> On Sat, Oct 27, 2018 at 2:37 AM wrote: >>>> >>>>> Hello lightning network developers. >>>>> Nayuta team is developing Wireshark plug-in for Lightning >>>>> Network(BOLT) protocol. >>>>> https://github.com/nayutaco/lightning-dissector >>>>> >>>>> It?s alpha version, but it can decode some BOLT message. >>>>> Currently, this software works for Nayuta?s implementation(ptarmigan) >>>>> and ?clair. >>>>> When ptarmigan is compiled with some option, it write out key >>>>> information file. This Wireshark plug-in decode packet using that file. >>>>> When you use ?clair, this software parse log file. >>>>> >>>>> Through our development experience, interoperability test is time >>>>> consuming task. >>>>> If people can see communication log of BOLT message on same format >>>>> (.pcap), it will be useful for interoperability test. >>>>> >>>>> Our proposal: >>>>> Every implementation has compile option which enable output key >>>>> information file. >>>>> >>>>> We are glad if this project is useful for lightning network eco-system. >>>>> >>>> _______________________________________________ >>>>> Lightning-dev mailing list >>>>> Lightning-dev at lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>>> >>>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: