tock203 [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-07 📝 Original message: We implemented the latter ...
📅 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>;
📝 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>;