tock203 [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-07 to 2018-11-27
💬 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:15

- reply

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

2023-06-09 12:52:14

- reply

📅 Original date posted:2018-11-07
📝 Original message:
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181107/3b15ea1d/attachment.html>

2023-06-09 12:52:14

- reply