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 <arow...@gmail.com>: > 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.christ...@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 <tomokio...@gmail.com> 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 <laol...@gmail.com>: >>> >>>> 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 <tomokio...@gmail.com> 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@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>>>> >>>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
