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
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.
-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
On Sat, Aug 23, 2014 at 04:50:30PM +, 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
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.
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
On Sat, Aug 23, 2014 at 07:02:55PM +, 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
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
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 m...@ricmoo.com escribió:
If you encrypt all messages with an asymmetric cipher, how would each node
make use
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
-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
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
justusranv...@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
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
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
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?
-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,
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 j...@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
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
justusranv...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@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
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik jgar...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd p...@petertodd.org wrote:
That is simply incorrect. The resources required to do that kind of
monitoring are very high; even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier justusranv...@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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:59:14 GMT-04:00, William Yager will.ya...@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,
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 21:19:43 GMT-04:00, William Yager will.ya...@gmail.com
wrote:
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd p...@petertodd.org wrote:
In any case, my suggestion of enabling hidden service support by
default
adds both encryption
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
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
28 matches
Mail list logo
