* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
[not found] <c45a638f1e1640fe84bef01d12cda4c3@hotmail.com>
@ 2014-08-20 3:23 ` Un Ix
2014-08-20 5:40 ` Cameron Garnham
0 siblings, 1 reply; 32+ messages in thread
From: Un Ix @ 2014-08-20 3:23 UTC (permalink / raw)
To: Peter Todd, William Yager, bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3050 bytes --]
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
Sent: Wednesday, August 20, 2014 9:28 AM
To: William Yager, 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
[-- Attachment #2: Type: text/html, Size: 5339 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 3:23 ` [Bitcoin-development] Proposal: Encrypt bitcoin messages Un Ix
@ 2014-08-20 5:40 ` Cameron Garnham
2014-08-20 14:37 ` Mike Hearn
0 siblings, 1 reply; 32+ messages in thread
From: Cameron Garnham @ 2014-08-20 5:40 UTC (permalink / raw)
To: Un Ix; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 5:40 ` Cameron Garnham
@ 2014-08-20 14:37 ` Mike Hearn
2014-08-23 6:39 ` Troy Benjegerdes
0 siblings, 1 reply; 32+ messages in thread
From: Mike Hearn @ 2014-08-20 14:37 UTC (permalink / raw)
To: Cameron Garnham; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
I would be very happy if we upgraded the P2P protocol with MAC keys and a
simple home grown encryption layer, because:
1. It's practically guaranteed that 5-eyes intelligence agencies are
either systematically deanonymising Bitcoin users already (linking
transactions to real world identities) or close to succeeding. Peter is
correct. Given the way their infrastructure works, encrypting link level
traffic would significantly raise the bar to such attacks. Quite possibly
to the level where it's deemed unprofitable to continue.
2. Tor is not a complete solution. The most interesting links to monitor
are those from SPV clients connecting to Core nodes. Whilst Java SPV
clients have the nice option of an easy bundled Tor client (er, once we fix
the last bugs) clients that are not based on bitcoinj would have to use the
full-blown Tor client, which is not only a PITA to bundle as Tor is not at
all library-fied, but is a giant pile of C which is almost certainly
exploitable. Even if it runs in a separate address space, for many
platforms this is insufficient as a compromised Tor client could then go
ahead and compromise your wallet app too.
Implementing a full Tor client is not a reasonable thing to ask of a wallet
developer, but doing HMAC checks and a simple ECDH exchange + AES would be
quite realistic.
[-- Attachment #2: Type: text/html, Size: 1456 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 14:37 ` Mike Hearn
@ 2014-08-23 6:39 ` Troy Benjegerdes
0 siblings, 0 replies; 32+ messages in thread
From: Troy Benjegerdes @ 2014-08-23 6:39 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
I think it's a little disingenuous to talk about encrypting the P2P protocol
as a security improvement, when all the organized crime agencies need to do is
borrow a Fedex/UPS truck and deliver some laptops to Github employees and they
can insert whatever monitoring/0-day they want.
Encryption is complicated stuff to actually **get right**, and the more stuff
you throw crypto around, the more likely it is you'll get a Heartbleed 0-day
If you want to increase security, make it simpler. I'm not even sure it can
be easily simplified... how could you separate the P2P network transport from
the core blockchain functionality?
On Wed, Aug 20, 2014 at 04:37:24PM +0200, Mike Hearn wrote:
> I would be very happy if we upgraded the P2P protocol with MAC keys and a
> simple home grown encryption layer, because:
>
> 1. It's practically guaranteed that 5-eyes intelligence agencies are
> either systematically deanonymising Bitcoin users already (linking
> transactions to real world identities) or close to succeeding. Peter is
> correct. Given the way their infrastructure works, encrypting link level
> traffic would significantly raise the bar to such attacks. Quite possibly
> to the level where it's deemed unprofitable to continue.
>
> 2. Tor is not a complete solution. The most interesting links to monitor
> are those from SPV clients connecting to Core nodes. Whilst Java SPV
> clients have the nice option of an easy bundled Tor client (er, once we fix
> the last bugs) clients that are not based on bitcoinj would have to use the
> full-blown Tor client, which is not only a PITA to bundle as Tor is not at
> all library-fied, but is a giant pile of C which is almost certainly
> exploitable. Even if it runs in a separate address space, for many
> platforms this is insufficient as a compromised Tor client could then go
> ahead and compromise your wallet app too.
>
> Implementing a full Tor client is not a reasonable thing to ask of a wallet
> developer, but doing HMAC checks and a simple ECDH exchange + AES would be
> quite realistic.
> ------------------------------------------------------------------------------
> 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
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed•org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 19:02 ` Luke Dashjr
@ 2014-08-23 22:51 ` Peter Todd
0 siblings, 0 replies; 32+ messages in thread
From: Peter Todd @ 2014-08-23 22:51 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Sat, Aug 23, 2014 at 07:02:55PM +0000, Luke Dashjr wrote:
> On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote:
> > > Not to mention encrypting basically non-sensitive inter-node traffic is
> > > almost completely worthless in providing anonymity anyway...
> >
> > Recall that P2P connections carry Bloom filters too, which are not public
> > information.
>
> As soon as you tell it to an unknown/public peer, it is public information.
Mike is correct here: It *might* be public information, and probably
won't be. We already can give weak assurance that it probably won't be
against many weaker attackers, simply because getting lots of IP
addresses is moderately expensive, and in the future additional methods
will be developed and deployed.
--
'peter'[:-1]@petertodd.org
0000000000000000239344fc532bbad8a679e3fc30e8900772523a10c4720a0c
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 18:44 ` Mike Hearn
@ 2014-08-23 19:02 ` Luke Dashjr
2014-08-23 22:51 ` Peter Todd
0 siblings, 1 reply; 32+ messages in thread
From: Luke Dashjr @ 2014-08-23 19:02 UTC (permalink / raw)
To: bitcoin-development
On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote:
> > Not to mention encrypting basically non-sensitive inter-node traffic is
> > almost completely worthless in providing anonymity anyway...
>
> Recall that P2P connections carry Bloom filters too, which are not public
> information.
As soon as you tell it to an unknown/public peer, it is public information.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 18:22 ` William Yager
@ 2014-08-23 18:44 ` Mike Hearn
2014-08-23 19:02 ` Luke Dashjr
0 siblings, 1 reply; 32+ messages in thread
From: Mike Hearn @ 2014-08-23 18:44 UTC (permalink / raw)
To: William Yager; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
>
> Not to mention encrypting basically non-sensitive inter-node traffic is
> almost completely worthless in providing anonymity anyway...
>
Recall that P2P connections carry Bloom filters too, which are not public
information.
[-- Attachment #2: Type: text/html, Size: 568 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 17:50 ` Troy Benjegerdes
@ 2014-08-23 18:22 ` William Yager
2014-08-23 18:44 ` Mike Hearn
0 siblings, 1 reply; 32+ messages in thread
From: William Yager @ 2014-08-23 18:22 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
On Sat, Aug 23, 2014 at 12:50 PM, Troy Benjegerdes <hozer@hozed•org> wrote:
> they can hire a hacker who will
> find a misplaced (} in your crypto code, and all the work you did to
> encrypt wire protocols becomes silently worthless.
>
Not to mention encrypting basically non-sensitive inter-node traffic is
almost completely worthless in providing anonymity anyway...
Seriously, I have not heard a strong justification for this proposal yet. I
have heard some people talking about Tor-ifying communications, but that is
a completely different issue and should not be confused with just
"encrypting bitcoin messages".
[-- Attachment #2: Type: text/html, Size: 978 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 16:50 ` Justus Ranvier
@ 2014-08-23 17:50 ` Troy Benjegerdes
2014-08-23 18:22 ` William Yager
0 siblings, 1 reply; 32+ messages in thread
From: Troy Benjegerdes @ 2014-08-23 17:50 UTC (permalink / raw)
To: Justus Ranvier; +Cc: bitcoin-development
On Sat, Aug 23, 2014 at 04:50:30PM +0000, Justus Ranvier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 08/23/2014 04:17 PM, xor wrote:
> > On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
> >> Encryption is of little value if you may deduce the same
> >> information by observing packet sizes and timings.
> >
> > Instead of spawning a discussion whether this aspect is a reason to
> > NOT encrypt, you should do the obvious:
> >
> > Fix that as well. X being broken is not a reason for not fixing Y.
> > Pad the then encrypted packets with random bytes. The fact that
> > they are encrypted makes them look like random data already, so the
> > padding will not be distinguishable from the rest. Also, add some
> > random bias to their timing.
>
> The packet size and timing issue will become less of an issue as the
> network grows anyway.
>
> One transaction inserted into a 3 transaction-per-second encrypted
> stream is more obvious than the same transaction inserted into a 100
> or 1000 TPS stream.
The requirement for anonymity and privacy is lawyers and a Bitlicense.
If you want privacy and anonymity, then do high-frequency trading on
a centralized exchange, and if you want to go over-the-top, run some
arbitrage bots as well, and hide in the millions of transactions per
second that go on.
But make sure you get a Bitlicense and have a good securities lawyer.
Trying to solve a legal/legislative/social problem with more crypto is
only going to serve the people who created the legal/legislative/social
problem in the first place, because they can hire a hacker who will
find a misplaced (} in your crypto code, and all the work you did to
encrypt wire protocols becomes silently worthless.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-23 16:17 ` xor
@ 2014-08-23 16:50 ` Justus Ranvier
2014-08-23 17:50 ` Troy Benjegerdes
0 siblings, 1 reply; 32+ messages in thread
From: Justus Ranvier @ 2014-08-23 16:50 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/23/2014 04:17 PM, xor wrote:
> On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
>> Encryption is of little value if you may deduce the same
>> information by observing packet sizes and timings.
>
> Instead of spawning a discussion whether this aspect is a reason to
> NOT encrypt, you should do the obvious:
>
> Fix that as well. X being broken is not a reason for not fixing Y.
> Pad the then encrypted packets with random bytes. The fact that
> they are encrypted makes them look like random data already, so the
> padding will not be distinguishable from the rest. Also, add some
> random bias to their timing.
The packet size and timing issue will become less of an issue as the
network grows anyway.
One transaction inserted into a 3 transaction-per-second encrypted
stream is more obvious than the same transaction inserted into a 100
or 1000 TPS stream.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT+MZWAAoJEMP3uyY4RQ21tDoH/0SPYQcUkYJcuDhTkJCFWdyx
ob3H7ITEcqD0UZ3n3QHdxHfCDlP2srL0EcfjbNceRX5inP47jdoGj7uIkY/NRHQ0
4J2WCIrcu1Bj3ZxXG59PtfUzMjxhMGDMSk5eE+6BjVQILrkxxrqSpVjykfoq5s6Y
EBdT2Pf4djQ5k2fQ2PX1dTt5iCvFh0ufq3McrYsciRzguRwlelw1W34tPBqGSv0n
LScgvqYUTGC7otUdA5K/3WBq6SSo7E13hJxiLKQZMQ4CPpSlsiAhI5fuhl0OBljC
hCtS+eugFmvMICQt0ELds++nnA5WN/Yjx1WIrnLA1EmNiAkS9RSEVMcyab0TtdI=
=0sjO
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14046 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 23:40 ` Jeff Garzik
2014-08-20 0:16 ` Peter Todd
@ 2014-08-23 16:17 ` xor
2014-08-23 16:50 ` Justus Ranvier
1 sibling, 1 reply; 32+ messages in thread
From: xor @ 2014-08-23 16:17 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote:
> Encryption is of little value if you may deduce the same information
> by observing packet sizes and timings.
Instead of spawning a discussion whether this aspect is a reason to NOT
encrypt, you should do the obvious:
Fix that as well. X being broken is not a reason for not fixing Y.
Pad the then encrypted packets with random bytes. The fact that they are
encrypted makes them look like random data already, so the padding will not be
distinguishable from the rest.
Also, add some random bias to their timing.
And besides: It would be nice if everyone could acknowledge that making
Bitcoin as anonymous as possible is a natural desire. People demanding you to
do this is bound to happen over and over again until you do it :) So just get
on with it instead of postponing it due to doubts.
There is Tor, there is Freenet, and there are other anonymous P2P networks,
and they can help you do get it done - the said problems have been well-known
there for quite some time and people have thought about how to solve them.
Greetings,
xor, a developer of https://freenetproject.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 1:19 ` William Yager
@ 2014-08-20 1:27 ` Peter Todd
0 siblings, 0 replies; 32+ messages in thread
From: Peter Todd @ 2014-08-20 1:27 UTC (permalink / raw)
To: William Yager, Bitcoin Dev
-----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-----
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 1:14 ` Peter Todd
@ 2014-08-20 1:19 ` William Yager
2014-08-20 1:27 ` Peter Todd
0 siblings, 1 reply; 32+ messages in thread
From: William Yager @ 2014-08-20 1:19 UTC (permalink / raw)
To: Peter Todd, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd <pete@petertodd•org> wrote:
>
> Don't let perfect be the enemy of good.
>
I'm not. I don't think this proposal is even good.
> You realize that by your own definition even the NSA is mostly a "weak
> passive attacker" They do *not* have the ability to attack more than a
> small, targeted, subset of connection for both technical and political
> reasons. For starters, MITM attacks are easily detected - "Bitcoin network
> attacked by unknown agents! Has your ISP been compromised?" would make for
> great headlines and would soon see the problem fixed both technically and
> politically.
>
>
Again, the NSA might get an absolutely trivial amount of data from
monitoring connections on the Bitcoin network. A bit of publicity is *not*
worth drastically increasing the software complexity of the client.
> 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.
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.
[-- Attachment #2: Type: text/html, Size: 1967 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:59 ` William Yager
@ 2014-08-20 1:14 ` Peter Todd
2014-08-20 1:19 ` William Yager
0 siblings, 1 reply; 32+ messages in thread
From: Peter Todd @ 2014-08-20 1:14 UTC (permalink / raw)
To: William Yager; +Cc: Bitcoin Development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 19 August 2014 20:59:14 GMT-04:00, William Yager <will.yager@gmail•com> wrote:
>What, exactly, do we hope to achieve from having end-to-end encryption?
>
>Even if it worked perfectly, it wouldn't be very useful.
>
>But it won't work perfectly, because we don't have any method of
>authentication.
Don't let perfect be the enemy of good.
> The bitcoin network is trivially MITMable. It's
>designed to
>work even in the face of that, but any encryption we implement will
>just
>get blown away by anyone who cares enough to stand in the middle of two
>nodes.
>
>As far as I can see, we get a microscopic obfuscatory advantage over a
>very
>weak passive attacker, at the cost of hugely increased software
>complexity
>(and possibly increased CPU time).
You realize that by your own definition even the NSA is mostly a "weak passive attacker" They do *not* have the ability to attack more than a small, targeted, subset of connection for both technical and political reasons. For starters, MITM attacks are easily detected - "Bitcoin network attacked by unknown agents! Has your ISP been compromised?" would make for great headlines and would soon see the problem fixed both technically and politically.
In any case, my suggestion of enabling hidden service support by default adds both encryption and reasonably good authentication.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJT8/ZaMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhV5UCAC0wVMyKtCedZuUKXrw
Mg6qvbkDzGyzn7fgASTnMh8hF+p+p5MoOz3K0FGTdLph+ulptz9ITatGmmi+av+u
0Fc8xXYgxiYcIwtMVumNrHR16bjG7NoShnqMujuUZ7a+xigeHxV2/tG0VRb9Km8W
GFYNdY4mOFubFu7qfqymmxGsIgP42rPsN6c41B75wqqaGzSX7BRmlxNsYVSUO3Fi
fwNU7y7hLC9BN+WQCmVK+Rk57XpXcoydfvsz9a/SLhiQKssEdcDbUq4gLtnDHs92
JBsUqzG/wDgcQFiLuAm/A/ZvDAERwPr6jtunt3CCDt+UdLwlGAj5RTnuHgY72PNS
Ma2O
=2qdX
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:41 ` Peter Todd
@ 2014-08-20 0:59 ` William Yager
2014-08-20 1:14 ` Peter Todd
0 siblings, 1 reply; 32+ messages in thread
From: William Yager @ 2014-08-20 0:59 UTC (permalink / raw)
Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
What, exactly, do we hope to achieve from having end-to-end encryption?
Even if it worked perfectly, it wouldn't be very useful.
But it won't work perfectly, because we don't have any method of
authentication. The bitcoin network is trivially MITMable. It's designed to
work even in the face of that, but any encryption we implement will just
get blown away by anyone who cares enough to stand in the middle of two
nodes.
As far as I can see, we get a microscopic obfuscatory advantage over a very
weak passive attacker, at the cost of hugely increased software complexity
(and possibly increased CPU time).
So again; what do we hope to achieve? Why bother? Not a lot of sensitive
information is transmitted in the clear. The little information that might
be considered sensitive is better protected by anonymization (a la Tor),
not encryption.
[-- Attachment #2: Type: text/html, Size: 993 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:49 ` Justus Ranvier
@ 2014-08-20 0:57 ` Peter Todd
0 siblings, 0 replies; 32+ messages in thread
From: Peter Todd @ 2014-08-20 0:57 UTC (permalink / raw)
To: Justus Ranvier, Bitcoin Development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier <justusranvier@riseup•net> wrote:
>On 08/20/2014 12:16 AM, Peter Todd wrote:
>> The easiest way to do this would be to make the Debian/Ubuntu
>> packages depend on Tor, and include a install-time script to setup
>> the hidden service. I've verified with the Tor devs that they would
>> welcome the additional load on the Tor network that Bitcoin would
>> add.
>
>The easiest way for the people who operates nodes would be to compile
>Tor into Bitcoin Core as a library so that it "just works" when turned
>on.
That library doesn't exist yet to my knowledge, and more importantly, would increase the attack surface of Bitcoin Core. (much like using OpenSSL for straight SSL support would)
Also, my proposal of adding Tor support to the Debian packages can be implemented in a relatively short install time script; no code changes required.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJT8/KRMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhauiB/9iEvsRYQGt9lFmrtbW
SBjDt91/v7r3NcI/19aKDNGMaKl61rpzDr1zM3kIBdY3xzFoaYt+LA6O/tZVvaVC
B9zPlZsh+0ZmbU+Ejxd816DvJVDv8aO6Nt+sLuVkkN/TsBa/WCBhvwJ7ixS65/dY
WpFV7awzW+E08RETsV826scP+30lsnY5qcADoHWfuaW7HZQArpCsA+b+Amng8Vf6
mFb5GrxKlvG06w+esLSXMCISS3eMduvfzymfxBxGlgxRAqiYZRbWY3msdRRfWl3e
lISrnqZoB3G529WVGOn4o5DrzDdSJFcb8k2A/Na2J+pIxAD4Cv9vwYM2KCffbeUB
PH6x
=Mw3I
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:16 ` Peter Todd
2014-08-20 0:21 ` Jeff Garzik
@ 2014-08-20 0:49 ` Justus Ranvier
2014-08-20 0:57 ` Peter Todd
1 sibling, 1 reply; 32+ messages in thread
From: Justus Ranvier @ 2014-08-20 0:49 UTC (permalink / raw)
To: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/20/2014 12:16 AM, Peter Todd wrote:
> The easiest way to do this would be to make the Debian/Ubuntu
> packages depend on Tor, and include a install-time script to setup
> the hidden service. I've verified with the Tor devs that they would
> welcome the additional load on the Tor network that Bitcoin would
> add.
The easiest way for the people who operates nodes would be to compile
Tor into Bitcoin Core as a library so that it "just works" when turned on.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT8/B9AAoJEMP3uyY4RQ21YbcH/1golU27alo57cfCqjMei6uD
iJ69NMQ6wO4U9r8VX8Rwkd/8IVK+gP4eJNRj4FlUNU0eXFcXj3zaCpnHnO30OEPV
tdx/dyd/sq/gn5WL3m29MsP5ZVX8pIIH8aQ6jjLWC0SsE6KUJeK6f48o/XST4kMn
a5w1YkUW1Mo/1lLmIlTnmapNrMYq1VppOi0F8AaRgMjTkoX/aGOgu6yIlGJXjAbA
E8zlIvmLBcMq3aGNrlpE5WJBG1UQr84GYxjSQ1evL1PsllkxrSH3MODtESLYTMqB
77ZpGNbm3Ndgxvr03pXhXPGbrug3qX92fbKI42XkSC7n/pWLe5YKUiAukDN4NjU=
=ttua
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14046 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:21 ` Jeff Garzik
@ 2014-08-20 0:41 ` Peter Todd
2014-08-20 0:59 ` William Yager
0 siblings, 1 reply; 32+ messages in thread
From: Peter Todd @ 2014-08-20 0:41 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development, Justus Ranvier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik <jgarzik@bitpay•com> wrote:
>On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd <pete@petertodd•org> wrote:
>> That is simply incorrect. The resources required to do that kind of
>monitoring are very high; even the NSA can't pull it off consistently
>for
>
>Hardly. For example, when a new block arrives on the network, a
>single observer at a single location may obtain a binary "likely|not
>bitcoin protocol" decision from a spike in usage correlated with
>sudden, global network activity after a period of inactivity. I'll
>not detail all such metrics.
Emphasis on "likely", at best. Forcing you adversary to rely on uncertain statistics is a huge improvement over the status quo. Secondly your example is of a new block; the more general concern is determining where a given transaction originated. In the best of circumstances determining the origin of a few hundred bytes of days interspersed in dozens of kB/s of buffered data streams is very difficult and expensive even without padding and/or random delay features.
Again, I've spoken to people like Jacob Applebaum about this who have a solid understanding of what the NSA is actually capable of, and they've confirmed the above. Don't let perfect be the enemy of good.
Of course, that's not to say we shouldn't cost-benefit analysis the implementation; not using straight OpenSSL for this is a wise decision. Hence the suggestion of using the existing and tested Tor support to encrypt by default.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJT8+62MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhZe/CADI+XvuCzK6N0/UUieD
WzrGexWQsqNxX2hYQpzAiYT3Y5k4CCJ3yvett0udYKS3Piqd/ihvj9RfjWe5nO+d
snPGNwFU7jSRJ+hwPdnlHfFW99LCkKOzBX0hgC+qg11SyLKcsBwE3qaiFM47G1hy
r4f1qX3Te2Kt0bUxP65d1M0Js1M0x+qLxXs6e9Gy3scFSpDjeoamgliJ6jBeeX9U
8H0mambip5CZ+diGbaMeCCRJd19XH7Nz0QgcznYScmz/3krQhtIdEJKts7bs87vh
vZyH7M4wVCiIDmDNxAIO2slo3+eopEvbOPgqjT7L72jrQgp3zVUtbJDzpSAgcB+M
vLhB
=AuCe
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-20 0:16 ` Peter Todd
@ 2014-08-20 0:21 ` Jeff Garzik
2014-08-20 0:41 ` Peter Todd
2014-08-20 0:49 ` Justus Ranvier
1 sibling, 1 reply; 32+ messages in thread
From: Jeff Garzik @ 2014-08-20 0:21 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Development, Justus Ranvier
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd <pete@petertodd•org> wrote:
> On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik <jgarzik@bitpay•com> wrote:
>>Encryption is of little value if you may deduce the same information
>>by observing packet sizes and timings.
>
> That is simply incorrect. The resources required to do that kind of monitoring are very high; even the NSA can't pull it off consistently for
Hardly. For example, when a new block arrives on the network, a
single observer at a single location may obtain a binary "likely|not
bitcoin protocol" decision from a spike in usage correlated with
sudden, global network activity after a period of inactivity. I'll
not detail all such metrics.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 23:40 ` Jeff Garzik
@ 2014-08-20 0:16 ` Peter Todd
2014-08-20 0:21 ` Jeff Garzik
2014-08-20 0:49 ` Justus Ranvier
2014-08-23 16:17 ` xor
1 sibling, 2 replies; 32+ messages in thread
From: Peter Todd @ 2014-08-20 0:16 UTC (permalink / raw)
To: Jeff Garzik, J Ross Nicoll; +Cc: Bitcoin Development, Justus Ranvier
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik <jgarzik@bitpay•com> wrote:
>Encryption is of little value if you may deduce the same information
>by observing packet sizes and timings.
That is simply incorrect. The resources required to do that kind of monitoring are very high; even the NSA can't pull it off consistently for non-targetted operations due to limitations on upstream bandwidth and other resources. (remember that many of their taps are non-cooperative ones, obtained by breaking into routers at ISP's) This I've confirmed with direct conversation with Jacob Applebaum and other Tor devs. Every additional bit of encrypted information flowing over the internet increases the work they need to so to deanonymize you. This is not unlike how CoinJoin, while not providing guaranteed anonymity, makes the job of attackers significantly more difficult by creating large amounts of statistical noise. In addition the Bitcoin P2P protocol has natural anti-traffic analysis properties due to its asynchronous nature.
Re: MITM attacks, again, the resources required to conduct them on a large scale instead of passive attacks just don't exist. For instance the NSA has to be relatively selective in using them for fear of being detected; being able to detect attacks is a huge improvement over the status quo anyway.
Having said that using Tor by default in Bitcoin Core is an even easier way of enabling encryption and authentication, and would help protect all Tor users from surveillance. The easiest way to do this would be to make the Debian/Ubuntu packages depend on Tor, and include a install-time script to setup the hidden service. I've verified with the Tor devs that they would welcome the additional load on the Tor network that Bitcoin would add.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJT8+jcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhU2WB/9XE6BFxTkbjIfVn46U
uH7HCV/FSgCeSConO7LbFR2m6hN5eZ4oKcLzIi65SqRUol2eCGWVoJDsl3vuTmwF
c4gOqdieJQ6SOdHAzcolf+b3p+VwIXXUMMsO2vI6UGZvV6gFJXnZ17GASdSo9+f8
x4VxgLSunZD0xRMiMntaqPMFu1MyplomimQadW5MDt3QTa2BrOsDMwNS10NSQIAL
8ywHSKh8UddVL8ZeinE/Bhf3T1OnDVBIUCVHhhEYnKLqCnwmyY3NXH4lzXpPvo+e
LhzF7HzB5tE22vIQNb/3RimoN5FV7p4FEvgsGwT/kjjUAxgg6/LpNY5WQG6FL8nJ
/8F3
=t4/7
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 23:39 ` Justus Ranvier
@ 2014-08-19 23:54 ` Gregory Maxwell
0 siblings, 0 replies; 32+ messages in thread
From: Gregory Maxwell @ 2014-08-19 23:54 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Dev
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
<justusranvier@riseup•net> wrote:
> While the rest of the 'net is busy deprecating HTTP and all other
> unencrypted transport methods, why is it(*) even a debate?
I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it in the past)— but all of engineering is
tradeoffs... and the ones involved here don't make it a high priority
in my book, esp when people should be using Bitcoin over tor in any
case, which provides better privacy and also covers encrypt + auth.
In general I think authentication is more important than encryption,
since authentication is table stakes required for a number of
anti-partitioning-attack measures. My past thinking on opportunistic
encryption is that once you're authenticating also encrypting would be
fairly little work, but it should be auth that drives that kind of
effort.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 23:38 ` J Ross Nicoll
2014-08-19 23:39 ` Justus Ranvier
@ 2014-08-19 23:40 ` Jeff Garzik
2014-08-20 0:16 ` Peter Todd
2014-08-23 16:17 ` xor
1 sibling, 2 replies; 32+ messages in thread
From: Jeff Garzik @ 2014-08-19 23:40 UTC (permalink / raw)
To: J Ross Nicoll; +Cc: Bitcoin Development, Justus Ranvier
Encryption is of little value if you may deduce the same information
by observing packet sizes and timings.
On Tue, Aug 19, 2014 at 7:38 PM, J Ross Nicoll <jrn@jrn•me.uk> wrote:
> The concern is that if you can monitor traffic in and out of a single node,
> you can determine which transactions originate from it vs those which it
> relays. That's not great, certainly, but how many nodes actually require
> that level of security, and surely they can use Tor or VPN services if so?
>
> Further, unless the remote nodes are in some way trusted, you're changing
> the attack from read-only to requiring the ability to perform a man in the
> middle attack - that doesn't seem much harder to me.
>
> As Gregory states, there's been at least two recent serious if not
> catastrophic OpenSSL bugs, and the consequences of Heartbleed if the Bitcoin
> network had been vulnerable are the stuff of nightmares.
>
> Very difficult to see the risk/reward payoff being worthwhile.
>
> Ross
>
>
> On 19/08/2014 18:35, Johnathan Corgan wrote:
>
> On 08/19/2014 09:38 AM, Gregory Maxwell wrote:
>
> We've dodged several emergency scale vulnerabilities by not having TLS.
>
> I'm still trying to understand the original premise that we want
> encrypted communications between nodes.
>
> I can certainly see the value of having *authenticated* traffic with
> specific nodes, using an HMAC for the protocol messages in place of the
> current checksum.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> 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
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 23:38 ` J Ross Nicoll
@ 2014-08-19 23:39 ` Justus Ranvier
2014-08-19 23:54 ` Gregory Maxwell
2014-08-19 23:40 ` Jeff Garzik
1 sibling, 1 reply; 32+ messages in thread
From: Justus Ranvier @ 2014-08-19 23:39 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/19/2014 11:38 PM, J Ross Nicoll wrote:
> That's not great, certainly, but how many nodes actually require
> that level of security
All of them.
While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods, why is it(*) even a debate?
Security should be on by default. Make users who don't want it jump
through hoops to turn it off instead of the other way around.
(*) where "it" is the desirability of blocking passive surveillance,
not the particular algorithm to use.
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT8+AdAAoJEMP3uyY4RQ21kv8IANDkveCGJX5b5c+waXTHcEf0
MgrGlkUZgZaP+fNNME32MEeQMywkyHohZly1KKYyqf+Qi2YkZ7rFiZj5e16EtGVK
zBQCrvOyMZVv/tWPfRxrZV+jC5dUBPryaCV3XwyK3w8u5WpDhpC1be6uBjY6qtTB
58MzdMBEEwceUwDezAIpGxsr5fKw+by4WyL23HQybSgUSHWh9S9hSp4dY1L8sDdr
atdFOvjiwY7zQe9V4mrtSv2pwmWIfOJE3RBhwSdPBtsMqO0PAnUEmxKYANQjh8qV
W147aQT97DYkWb3TucY+gVbsfKSzvNoiXwvWMpmXT1Kz8wia0vX7MoPBtO6+uOk=
=6tJk
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14046 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 17:35 ` Johnathan Corgan
@ 2014-08-19 23:38 ` J Ross Nicoll
2014-08-19 23:39 ` Justus Ranvier
2014-08-19 23:40 ` Jeff Garzik
0 siblings, 2 replies; 32+ messages in thread
From: J Ross Nicoll @ 2014-08-19 23:38 UTC (permalink / raw)
To: Johnathan Corgan, Gregory Maxwell, Justus Ranvier; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]
The concern is that if you can monitor traffic in and out of a single
node, you can determine which transactions originate from it vs those
which it relays. That's not great, certainly, but how many nodes
actually require that level of security, and surely they can use Tor or
VPN services if so?
Further, unless the remote nodes are in some way trusted, you're
changing the attack from read-only to requiring the ability to perform
a man in the middle attack - that doesn't seem much harder to me.
As Gregory states, there's been at least two recent serious if not
catastrophic OpenSSL bugs, and the consequences of Heartbleed if the
Bitcoin network had been vulnerable are the stuff of nightmares.
Very difficult to see the risk/reward payoff being worthwhile.
Ross
On 19/08/2014 18:35, Johnathan Corgan wrote:
> On 08/19/2014 09:38 AM, Gregory Maxwell wrote:
>
>> We've dodged several emergency scale vulnerabilities by not having TLS.
> I'm still trying to understand the original premise that we want
> encrypted communications between nodes.
>
> I can certainly see the value of having *authenticated* traffic with
> specific nodes, using an HMAC for the protocol messages in place of the
> current checksum.
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2471 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 16:38 ` Gregory Maxwell
2014-08-19 16:58 ` Angel Leon
@ 2014-08-19 17:35 ` Johnathan Corgan
2014-08-19 23:38 ` J Ross Nicoll
1 sibling, 1 reply; 32+ messages in thread
From: Johnathan Corgan @ 2014-08-19 17:35 UTC (permalink / raw)
To: Gregory Maxwell, Justus Ranvier; +Cc: Bitcoin Development
[-- Attachment #1.1: Type: text/plain, Size: 502 bytes --]
On 08/19/2014 09:38 AM, Gregory Maxwell wrote:
> We've dodged several emergency scale vulnerabilities by not having TLS.
I'm still trying to understand the original premise that we want
encrypted communications between nodes.
I can certainly see the value of having *authenticated* traffic with
specific nodes, using an HMAC for the protocol messages in place of the
current checksum.
--
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Development Services
http://corganlabs.com
[-- Attachment #1.2: johnathan.vcf --]
[-- Type: text/x-vcard, Size: 274 bytes --]
begin:vcard
fn:Johnathan Corgan
n:Corgan;Johnathan
org:Corgan Labs
adr:Suite 70-111;;6081 Meridian Ave.;San Jose;CA;95120;US
email;internet:johnathan@corganlabs•com
title:Managing Partner
tel;work:+1 408 463 6614
url:http://corganlabs.com
version:2.1
end:vcard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 16:58 ` Angel Leon
@ 2014-08-19 17:19 ` Christophe Biocca
0 siblings, 0 replies; 32+ messages in thread
From: Christophe Biocca @ 2014-08-19 17:19 UTC (permalink / raw)
To: Bitcoin Development
If your threat model is passive listeners, it seems to me that simply
establishing a symmetric key for each connection at handshake time
using diffie-hellman is all you need. No public private crypto needed
at all.
The whole thing seems like a bit of security theater unfortunately.
The kind of attacker that can pull off widespread passive listening is
probably able and willing to do active MITM. It's not a huge
incremental cost.
Instead, those users that do have a need for security should probably
connect to the network using Tor or I2P, which can give much better
security guarantees than anything being discussed here.
On Tue, Aug 19, 2014 at 12:58 PM, Angel Leon <gubatron@gmail•com> wrote:
> "
> I suggest that Bitcoin Core should generate a public/private key pair and
> share the public one with peers."
>
> I've not read the p2p protocol of Bitcoin core, but I suppose the initial
> handshake between 2 peers would be the ideal place to exchange a public
> keys.
>
> would it make sense to generate a new random pair of keys per each peer you
> connect to?
> then each subsequent message to every peer gets encrypted differently,
> keeping each conversation isolated from each other encryption-speaking.
>
> These keys would have nothing to do with your wallet, they're just to
> encrypt any further communication between peers post-handshake. Would that
> be of any use to "This could provide privacy and integrity but not
> autentication."?
>
> http://twitter.com/gubatron
>
>
> On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell@gmail•com>
> wrote:
>>
>> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
>> <justusranvier@riseup•net> wrote:
>> > If that's not acceptable, even using TLS with self-signed certificates
>> > would be an improvement.
>>
>> TLS is a huge complex attack surface, any use of it requires an
>> additional dependency with a large amount of difficult to audit code.
>> TLS is trivially DOS attacked and every major/widely used TLS
>> implementation has had multiple memory disclosure or remote execution
>> vulnerabilities even in just the last several years.
>>
>> We've dodged several emergency scale vulnerabilities by not having TLS.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 16:38 ` Gregory Maxwell
@ 2014-08-19 16:58 ` Angel Leon
2014-08-19 17:19 ` Christophe Biocca
2014-08-19 17:35 ` Johnathan Corgan
1 sibling, 1 reply; 32+ messages in thread
From: Angel Leon @ 2014-08-19 16:58 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development, Justus Ranvier
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
"I suggest that Bitcoin Core should generate a public/private key pair and
share the public one with peers."
I've not read the p2p protocol of Bitcoin core, but I suppose the initial
handshake between 2 peers would be the ideal place to exchange a public
keys.
would it make sense to generate a new random pair of keys per each peer you
connect to?
then each subsequent message to every peer gets encrypted differently,
keeping each conversation isolated from each other encryption-speaking.
These keys would have nothing to do with your wallet, they're just to
encrypt any further communication between peers post-handshake. Would that
be of any use to "This could provide privacy and integrity but not
autentication."?
http://twitter.com/gubatron
On Tue, Aug 19, 2014 at 12:38 PM, Gregory Maxwell <gmaxwell@gmail•com>
wrote:
> On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
> <justusranvier@riseup•net> wrote:
> > If that's not acceptable, even using TLS with self-signed certificates
> > would be an improvement.
>
> TLS is a huge complex attack surface, any use of it requires an
> additional dependency with a large amount of difficult to audit code.
> TLS is trivially DOS attacked and every major/widely used TLS
> implementation has had multiple memory disclosure or remote execution
> vulnerabilities even in just the last several years.
>
> We've dodged several emergency scale vulnerabilities by not having TLS.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 2704 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 16:07 ` Justus Ranvier
@ 2014-08-19 16:38 ` Gregory Maxwell
2014-08-19 16:58 ` Angel Leon
2014-08-19 17:35 ` Johnathan Corgan
0 siblings, 2 replies; 32+ messages in thread
From: Gregory Maxwell @ 2014-08-19 16:38 UTC (permalink / raw)
To: Justus Ranvier; +Cc: Bitcoin Development
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
<justusranvier@riseup•net> wrote:
> If that's not acceptable, even using TLS with self-signed certificates
> would be an improvement.
TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult to audit code.
TLS is trivially DOS attacked and every major/widely used TLS
implementation has had multiple memory disclosure or remote execution
vulnerabilities even in just the last several years.
We've dodged several emergency scale vulnerabilities by not having TLS.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 15:30 ` Richard Moore
@ 2014-08-19 16:07 ` Justus Ranvier
2014-08-19 16:38 ` Gregory Maxwell
0 siblings, 1 reply; 32+ messages in thread
From: Justus Ranvier @ 2014-08-19 16:07 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 08/19/2014 03:30 PM, Richard Moore wrote:
> Oh, I see. I misread, thinking you wanted the dev team to have a
> private key and share the public key, similar to alerts. But each
> peer would have a public/private key pair and use something akin to
> ECDH for a symmetric key and transport using a block cipher?
>
> How would you share the public key? If I were a man-in-the-middle,
> I could intercept the public key, generate my own and pass that
> along and then decouple the pipe when the other side shares their
> public key.
>
> Also, you should not ignore your SSH fingerprint, as you exactly
> open yourself to mitm attacks.
http://curvecp.org
If that's not acceptable, even using TLS with self-signed certificates
would be an improvement.
- --
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJT83Y1AAoJEMP3uyY4RQ21aqUH/3rGvgz3J6UYY2Qb2qzNoucB
QqIj4fByZncX7Fhx5YK6fc6QoLr4Oqxd+zgbJ3ghrLtAJ7dm61iLmmib8MuDz2K1
kQj8xmZhWuUFI26bjK54RlKoWg46XFKNKcaVub6JmVg9dH8mX86mF746KnR5ZqdX
BuehWoEqcHlY3JkrTgOGpHjT/EGScZQxzJHzsBOfUJuX12lFtzcWzBTZyo5K8fD+
6eub3i6Fc4qn/c788UVFsmHeWV+NCeB1/y94V1+peIPWYhrZO+FVm+xEflG4U81Q
MRejqNjFT8ztT5vRHx1qJsmIgnzT0SXfh+FRt0hdqJizjlmyntMmCXjFmtnIeT8=
=9qWl
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14046 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
2014-08-19 15:11 ` Raúl Martínez
@ 2014-08-19 15:30 ` Richard Moore
2014-08-19 16:07 ` Justus Ranvier
0 siblings, 1 reply; 32+ messages in thread
From: Richard Moore @ 2014-08-19 15:30 UTC (permalink / raw)
To: Raúl Martínez; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
Oh, I see. I misread, thinking you wanted the dev team to have a private key and share the public key, similar to alerts. But each peer would have a public/private key pair and use something akin to ECDH for a symmetric key and transport using a block cipher?
How would you share the public key? If I were a man-in-the-middle, I could intercept the public key, generate my own and pass that along and then decouple the pipe when the other side shares their public key.
Also, you should not ignore your SSH fingerprint, as you exactly open yourself to mitm attacks.
On Aug 19, 2014, at 11:11 AM, Raúl Martínez <rme@i-rme•es> wrote:
> Only messages between peers are encrypted, only during transit.
>
> Before sending a transaction to Node B you use his public key, so Node B has the key
>
> El 19/08/2014 17:05, "Richard Moore" <me@ricmoo•com> escribió:
> If you encrypt all messages with an asymmetric cipher, how would each node make use of the blockchain in an encrypted form? Each node would be able to encrypt the data, but only the Bitcoin Core Dev could decrypt it?
>
>
> On Aug 19, 2014, at 5:49 AM, Raúl Martínez <rme@i-rme•es> wrote:
>
>> Hi,
>> I believe that all comunications should be encrypted by default, no matter that is public information (tx info), the only exception I would make would be block packets (to avoid increasing propagation time).
>>
>> I suggest that Bitcoin Core should generate a public/private key pair and share the public one with peers.
>>
>> This could provide privacy and integrity but not autentication.
>>
>> This way you can impersonate a bitcoin node (active mitm) but you cant just be passive and record all transactions send or recieved by an IP address.
>>
>> Today you can just watch for incoming/outgoing transactions to determine what tx are created in the Node, when you find one you can see the Bitcoin address inputs and outputs and track that person's bitcoins.
>> As an example, SSH provides this kind of encryption, althogh Bitcoin Core should ignore fingerprint changes (caused due to reinstalls).
>>
>> Please feel free to disqus why this is not needed or why you like this idea.
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo@geneticmistakes•com
> www: http://GeneticMistakes.com
>
.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes•com
www: http://GeneticMistakes.com
[-- Attachment #2: Type: text/html, Size: 5094 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
[not found] ` <0C0EF7F9-DBBA-4872-897D-63CFA3853726@ricmoo.com>
@ 2014-08-19 15:11 ` Raúl Martínez
2014-08-19 15:30 ` Richard Moore
0 siblings, 1 reply; 32+ messages in thread
From: Raúl Martínez @ 2014-08-19 15:11 UTC (permalink / raw)
To: Richard Moore, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
Only messages between peers are encrypted, only during transit.
Before sending a transaction to Node B you use his public key, so Node B
has the key
El 19/08/2014 17:05, "Richard Moore" <me@ricmoo•com> escribió:
> If you encrypt all messages with an asymmetric cipher, how would each node
> make use of the blockchain in an encrypted form? Each node would be able to
> encrypt the data, but only the Bitcoin Core Dev could decrypt it?
>
>
> On Aug 19, 2014, at 5:49 AM, Raúl Martínez <rme@i-rme•es> wrote:
>
> Hi,
> I believe that all comunications should be encrypted by default, no matter
> that is public information (tx info), the only exception I would make would
> be block packets (to avoid increasing propagation time).
>
> I suggest that Bitcoin Core should generate a public/private key pair and
> share the public one with peers.
>
> This could provide privacy and integrity but not autentication.
>
> This way you can impersonate a bitcoin node (active mitm) but you cant
> just be passive and record all transactions send or recieved by an IP
> address.
>
> Today you can just watch for incoming/outgoing transactions to determine
> what tx are created in the Node, when you find one you can see the Bitcoin
> address inputs and outputs and track that person's bitcoins.
>
> As an example, SSH provides this kind of encryption, althogh Bitcoin Core
> should ignore fingerprint changes (caused due to reinstalls).
>
> Please feel free to disqus why this is not needed or why you like this
> idea.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo@geneticmistakes•com
> www: http://GeneticMistakes.com
>
>
[-- Attachment #2: Type: text/html, Size: 3169 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* [Bitcoin-development] Proposal: Encrypt bitcoin messages
[not found] <CA+8=xuJ+YDTNjyDW7DvP8KPN_nrFWpE68HvLw6EokFa-B-QGKw@mail.gmail.com>
@ 2014-08-19 9:49 ` Raúl Martínez
[not found] ` <0C0EF7F9-DBBA-4872-897D-63CFA3853726@ricmoo.com>
0 siblings, 1 reply; 32+ messages in thread
From: Raúl Martínez @ 2014-08-19 9:49 UTC (permalink / raw)
Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
Hi,
I believe that all comunications should be encrypted by default, no matter
that is public information (tx info), the only exception I would make would
be block packets (to avoid increasing propagation time).
I suggest that Bitcoin Core should generate a public/private key pair and
share the public one with peers.
This could provide privacy and integrity but not autentication.
This way you can impersonate a bitcoin node (active mitm) but you cant just
be passive and record all transactions send or recieved by an IP address.
Today you can just watch for incoming/outgoing transactions to determine
what tx are created in the Node, when you find one you can see the Bitcoin
address inputs and outputs and track that person's bitcoins.
As an example, SSH provides this kind of encryption, althogh Bitcoin Core
should ignore fingerprint changes (caused due to reinstalls).
Please feel free to disqus why this is not needed or why you like this idea.
[-- Attachment #2: Type: text/html, Size: 1087 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2014-08-23 22:52 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <c45a638f1e1640fe84bef01d12cda4c3@hotmail.com>
2014-08-20 3:23 ` [Bitcoin-development] Proposal: Encrypt bitcoin messages Un Ix
2014-08-20 5:40 ` Cameron Garnham
2014-08-20 14:37 ` Mike Hearn
2014-08-23 6:39 ` Troy Benjegerdes
[not found] <CA+8=xuJ+YDTNjyDW7DvP8KPN_nrFWpE68HvLw6EokFa-B-QGKw@mail.gmail.com>
2014-08-19 9:49 ` Raúl Martínez
[not found] ` <0C0EF7F9-DBBA-4872-897D-63CFA3853726@ricmoo.com>
2014-08-19 15:11 ` Raúl Martínez
2014-08-19 15:30 ` Richard Moore
2014-08-19 16:07 ` Justus Ranvier
2014-08-19 16:38 ` Gregory Maxwell
2014-08-19 16:58 ` Angel Leon
2014-08-19 17:19 ` Christophe Biocca
2014-08-19 17:35 ` Johnathan Corgan
2014-08-19 23:38 ` J Ross Nicoll
2014-08-19 23:39 ` Justus Ranvier
2014-08-19 23:54 ` Gregory Maxwell
2014-08-19 23:40 ` Jeff Garzik
2014-08-20 0:16 ` Peter Todd
2014-08-20 0:21 ` Jeff Garzik
2014-08-20 0:41 ` Peter Todd
2014-08-20 0:59 ` William Yager
2014-08-20 1:14 ` Peter Todd
2014-08-20 1:19 ` William Yager
2014-08-20 1:27 ` Peter Todd
2014-08-20 0:49 ` Justus Ranvier
2014-08-20 0:57 ` Peter Todd
2014-08-23 16:17 ` xor
2014-08-23 16:50 ` Justus Ranvier
2014-08-23 17:50 ` Troy Benjegerdes
2014-08-23 18:22 ` William Yager
2014-08-23 18:44 ` Mike Hearn
2014-08-23 19:02 ` Luke Dashjr
2014-08-23 22:51 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox