<p dir="ltr"><br>
We should aim to use perfect forward secrecy between all nodes by default.</p>
<p dir="ltr">This forces the attacker to do a MITM attack that is far more expensive on the large scale.</p>
<p dir="ltr">I don't see why this is seen as so controversial. It is relatively cheap to implement on our side, and has a dramatic increase of cost for any attackers.</p>
<p dir="ltr">Cam.<br></p>
<div class="gmail_quote">On 20/08/2014 5:49 am, "Un Ix" <<a href="mailto:slashdevnull@hotmail.com">slashdevnull@hotmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div dir="ltr" style="font-family:'Calibri','Segoe UI','Meiryo','Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','sans-serif';font-size:12pt"><div>Excuse the ignorance, but there is something I’m not getting in this discussion.</div>
<div><br></div><div>Given it’s a published protocol, with available source code running on an open P2P network, why would any messages between nodes benefit from being encrypted? Surely all the data being processed by the network is known to any persistent client node(s)? </div>
<div><br></div><div>Seems like that solution is orthogonal to the root problem, where attackers could monitor the network and deduce IP addresses by e.g. mapping senders of transactions.</div><div> <br></div><div style="padding-top:5px;border-top-color:rgb(229,229,229);border-top-width:1px;border-top-style:solid">
<div><font face=" 'Calibri', 'Segoe UI', 'Meiryo', 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style="line-height:15pt;letter-spacing:0.02em;font-family:"Calibri","Segoe UI","Meiryo","Microsoft YaHei UI","Microsoft JhengHei UI","Malgun Gothic","sans-serif";font-size:12pt"><b>From:</b> <a href="mailto:pete@petertodd.org" target="_blank">Peter Todd</a><br>
<b>Sent:</b> Wednesday, August 20, 2014 9:28 AM<br><b>To:</b> <a href="mailto:will.yager@gmail.com" target="_blank">William Yager</a>, <a href="mailto:bitcoin-development@lists.sourceforge.net" target="_blank">bitcoin-development@lists.sourceforge.net</a></font></div>
</div><div><br></div><div dir="">
<div>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
<br>
<br>
On 19 August 2014 21:19:43 GMT-04:00, William Yager <<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>> wrote:<br>
>On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>> wrote:<br>
>> In any case, my suggestion of enabling hidden service support by<br>
>default<br>
>> adds both encryption and reasonably good authentication.<br>
><br>
><br>
>Enabling hidden service support by default would introduce an insanely<br>
>huge<br>
>attack surface.<br>
<br>
Hence my suggestion of separating that surface by using the standalone Tor binary, which runs under a different user to the Bitcoin Core binary.<br>
<br>
>And you're conflating two different things; using Tor is valuable to<br>
>Bitcoin because it would provide some anonymity. The encryption aspect<br>
>is<br>
>pretty much useless for us.<br>
<br>
First of all, without encryption we're leaking significant amounts of information to any passive attacker trying to trace the origin of Bitcoin transactions, a significant privacy risk.<br>
<br>
Secondly the upcoming v0.10's fee estimation implementation is quite vulnerable to Sybil attacks. Authentication and encryption are needed to make it secure from ISP-level targeting to ensure that your view of the network is representative. Tor support used in parallel with native connection is ideal here, as neither the Tor network nor your ISP alone can Sybil attack you. It's notable that Bitcoinj has already implemented Tor support for these same reasons.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: APG v1.1.1<br>
<br>
iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf<br>
zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d<br>
kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw<br>
B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS<br>
uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5<br>
t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr<br>
OBQH<br>
=Gy7X<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
------------------------------------------------------------------------------<br>
Slashdot TV. <br>
Video for Nerds. Stuff that matters.<br>
<a href="http://tv.slashdot.org/" target="_blank">http://tv.slashdot.org/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
</div></div>
</div>
<br>------------------------------------------------------------------------------<br>
Slashdot TV.<br>
Video for Nerds. Stuff that matters.<br>
<a href="http://tv.slashdot.org/" target="_blank">http://tv.slashdot.org/</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div>