Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

[Cameron Garnham <da2ce7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4023 bytes --]

We should aim to use perfect forward secrecy between all nodes by default.

This forces the attacker to do a MITM attack that is far more expensive on
the large scale.

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.

Cam.
On 20/08/2014 5:49 am, "Un Ix" <slashdevnull@hotmail.com> wrote:

>  Excuse the ignorance, but there is something I’m not getting in this
> discussion.
>
> 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)?
>
> 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.
>
> *From:* Peter Todd <pete@petertodd.org>
> *Sent:* ‎Wednesday‎, ‎August‎ ‎20‎, ‎2014 ‎9‎:‎28‎ ‎AM
> *To:* William Yager <will.yager@gmail.com>,
> bitcoin-development@lists.sourceforge.net
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 19 August 2014 21:19:43 GMT-04:00, William Yager <will.yager@gmail.com>
> wrote:
> >On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <pete@petertodd.org> wrote:
> >> In any case, my suggestion of enabling hidden service support by
> >default
> >> adds both encryption and reasonably good authentication.
> >
> >
> >Enabling hidden service support by default would introduce an insanely
> >huge
> >attack surface.
>
> Hence my suggestion of separating that surface by using the standalone Tor
> binary, which runs under a different user to the Bitcoin Core binary.
>
> >And you're conflating two different things; using Tor is valuable to
> >Bitcoin because it would provide some anonymity. The encryption aspect
> >is
> >pretty much useless for us.
>
> 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.
>
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJT8/mSMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRZjCAC4PSpQ68qgtFMR77xf
> zXZLr/iMKX6yyJwXRj+vGi+0Ng/sv9NlYjYnDeflom37WlpGo/sCOFcVWImhnS2d
> kUFoUH92iXwRuEt/SN/LrHghkLWOxtVu9wa49eS/piGZFF3JWllk82MgdBZ6vjNw
> B6WuInEIurK+h8rUbAi2HjFkxVN0K0SsrFt/P0tHj10ABcMealBRoJh2Jx7fLNdS
> uTKddqeLyThEpLGNti3k+lhwQ2dA5RUBq6q3GUS/hWvTHRnU+viGMJSYv62LXRN5
> t87BXRY/R9UBpnudf3TIlPtOuIWcv2LhlXVjvbDDQqwJkvB3Qf4ejE3RZ28S5IUr
> OBQH
> =Gy7X
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6127 bytes --]