daniel [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-28 📝 Original message: Thank you, I have update ...
📅 Original date posted:2018-11-28
📝 Original message:
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 <tomokio203 at gmail.com> 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 <arowser at 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.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 <tomokio203 at 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 <laolu32 at 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 <tomokio203 at 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 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181128/1049f8c7/attachment-0001.html>;
📝 Original message:
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 <tomokio203 at gmail.com> 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 <arowser at 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.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 <tomokio203 at 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 <laolu32 at 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 <tomokio203 at 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 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181128/1049f8c7/attachment-0001.html>;