<div dir="ltr"><div>We implemented the latter scheme. lightning-dissector already supports key rotation.</div><div>FYI, here's the key log file format lightning-dissector currently implements. <a href="https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file">https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file</a></div><div><br></div><div>Whenever key rotation happens(nonce==0), lightning node software write 16byteMAC & key of "first BOLT packet".</div><div>When you read .pcap starts with a message whose nonce is not 0, the messages can not be decrypted until the next key rotation.</div><div><br></div><div>The current design is as described above. Because it is a provisional specification, any opinion is welcome.</div></div><br><div class="gmail_quote"><div dir="ltr">2018年11月6日(火) 16:08 Olaoluwa Osuntokun <<a href="mailto:laolu32@gmail.com">laolu32@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi tomokio, </div><div><br></div><div>This is so dope! We've long discussed creating canned protocol transcripts for</div><div>other implementations to assert their responses again, and I think this is a</div><div>great first step towards that.</div></div><div dir="ltr"><div><br></div><div>> Our proposal:</div><div>> Every implementation has compile option which enable output key information</div><div>> file.</div><div><br></div></div><div dir="ltr"><div>So is this request to add an option which will write out the _plaintext_</div><div>messages to disk, or an option that writes out the final derived read/write</div><div>secrets to disk? For the latter path, it the tools that read these transcripts</div><div>would need to be aware of key rotations, so they'd be able to continue to</div><div>decrypt the transact pt post rotation.</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"></div></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Oct 27, 2018 at 2:37 AM <<a href="mailto:tomokio203@gmail.com" target="_blank">tomokio203@gmail.com</a>> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello lightning network developers.</div><div>Nayuta team is developing Wireshark plug-in for Lightning Network(BOLT) protocol.</div><div><a href="https://github.com/nayutaco/lightning-dissector" target="_blank">https://github.com/nayutaco/lightning-dissector</a></div><div><br></div><div>It’s alpha version, but it can decode some BOLT message.</div><div>Currently, this software works for Nayuta’s implementation(ptarmigan) and Éclair.</div><div>When ptarmigan is compiled with some option, it write out key information file. This Wireshark plug-in decode packet using that file.</div><div>When you use Éclair, this software parse log file.</div><div><br></div><div>Through our development experience, interoperability test is time consuming task.</div><div>If people can see communication log of BOLT message on same format (.pcap), it will be useful for interoperability test.</div><div><br></div><div>Our proposal:</div><div>Every implementation has compile option which enable output key information file.</div><div><br></div><div>We are glad if this project is useful for lightning network eco-system.</div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div></blockquote></div>