<div dir="ltr">It seems that every message must be signed (the protocols lacks MACs). This can be very resource consuming in terms of CPU and bandwidth since most p2p messages are small.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote:<br>
&gt; Hi<br>
&gt;<br>
&gt; I have just PRed a draft version of two BIPs I recently wrote.<br>
&gt; <a href="https://github.com/bitcoin/bips/pull/362" rel="noreferrer" target="_blank">https://github.com/bitcoin/bips/pull/362</a><br>
<br>
</span>I suggest running a spellchecker ;)<br>
<br>
Some questions;<br>
<br>
* why would you not allow encryption on non-pre-approved connections?<br>
* we just removed (ssl) encryption from the JSON interface, how do you suggest<br>
this encryption to be implemented without openSSL?<br>
* What is the reason for using the p2p code to connect a wallet to a node?<br>
I suggest using one of the other connection methods to connect to the node.<br>
This avoids a change in the bitcoin protocol for a very specific usecase.<br>
* Why do you want to do a per-message encryption (wrapping the original)?<br>
Smaller messages that contain predictable content and are able to be matched<br>
to the unencrypted versions on the wire send to other nodes will open this<br>
scheme up to various old statistical attacks.<br>
<br>
&gt; Responding peers must ignore (banning would lead to fingerprinting) the<br>
requesting peer after 5 unsuccessfully authentication tries to avoid resource<br>
attacks.<br>
<br>
Any implementation of that kind would itself again be open to resource<br>
attacks.<br>
Why 5? Do you want to allow a node to make a typo?<br>
<br>
<br>
&gt; To ensure that no message was dropped or blocked, the complete communication<br>
must be hashed (sha256). Both peers keep the SHA256 context of the encryption<br>
session. The complete &lt;code&gt;enc&lt;/code&gt; message (leaving out the hash itself)<br>
must be added to the hash-context by both parties. Before sending a<br>
&lt;code&gt;enc&lt;/code&gt; command, the sha256 context will be copied and finalized.<br>
<br>
You write &quot;the complete communication must be hashed&quot; and every message has a<br>
hash of the state until it is at that point.<br>
I think you need to explain how that works specifically.<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>