Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-08 📝 Original message: Would it be possible to ...
📅 Original date posted:2018-11-08
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181108/d7736bc9/attachment.html>;
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181108/d7736bc9/attachment.html>;