daniel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-11-27 to 2018-11-28
💬 Posted a total of 2 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:52:16

- reply

📅 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>

2023-06-09 12:52:15

- reply

📅 Original date posted:2018-11-27
📝 Original message:
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/20181127/6766df2c/attachment-0001.html>