tock203 [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-27 📝 Original message: Awesome, thanks! I merged ...
📅 Original date posted:2018-11-27
📝 Original message:
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/269089e8/attachment.html>;
📝 Original message:
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/269089e8/attachment.html>;