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 connecti
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 so
>
> 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 Sat, Aug 23, 2014 at 12:50 PM, Troy Benjegerdes 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
almos
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 b
-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 wh
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.
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 c
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 identit
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 o
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 k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 21:19:43 GMT-04:00, William Yager
wrote:
>On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd wrote:
>> In any case, my suggestion of enabling hidden service support by
>default
>> adds both encryption and reasonably good authenticatio
On Tue, Aug 19, 2014 at 8:14 PM, Peter Todd 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:59:14 GMT-04:00, William Yager
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
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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:49:01 GMT-04:00, Justus Ranvier
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 h
-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
> wel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 20:21:35 GMT-04:00, Jeff Garzik wrote:
>On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd 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 consiste
On Tue, Aug 19, 2014 at 8:16 PM, Peter Todd wrote:
> On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik 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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19 August 2014 19:40:39 GMT-04:00, Jeff Garzik 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
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
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
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 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
-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, w
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?
F
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
s
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 att
"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 ne
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
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 t
-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
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?
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" escribió:
> If you encrypt all messages with an asymmetric cipher, how would each node
> make use of the block
31 matches
Mail list logo