Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
Thank you, I have update the code follow you suggesstion and send a new pr to https://github.com/nayutaco/lightning-dissector. On Wed, Nov 28, 2018 at 5:32 AM tock203 wrote: > 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.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 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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
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.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 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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
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 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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
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@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
Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol
Nice work, thank you! On Fri, 26 Oct 2018 at 17:37, 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] Wireshark plug-in for Lightning Network(BOLT) protocol
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
