Broadcasting the raw transaction encrypted? - page 2.

ranochigo

legendary

Activity: 2954

Merit: 4158

Quote from: ?? on ??

By any chance, are you talking about this https://github.com/bitcoin/bips/pull/1024?

This: https://github.com/jonasschnelli/bips/blob/master/bip-0324.mediawiki actually.

It isn't designated as a BIP yet in the main repository.

Quote from: pooya87 on June 04, 2021, 05:44:23 AM

Since the data that is communicated between bitcoin nodes doesn't contain anything that is not already public (ie. blocks, transactions and node addrs) and also since that data (the blocks and transactions) can not be modified by a middle man without invalidating them there is no point in encrypting that data itself.

ISPs can do whatever a sybil attack can do, as they have MITM abilities. That and since they monitor both incoming and outgoing traffic, they will be able to determine the transactions that are related to the user, with a fairly high certainty.

Yes, if you need to hide the fact that you're using Bitcoin, you need Tor.

pooya87

legendary

Activity: 3402

Merit: 10424

Since the data that is communicated between bitcoin nodes doesn't contain anything that is not already public (ie. blocks, transactions and node addrs) and also since that data (the blocks and transactions) can not be modified by a middle man without invalidating them there is no point in encrypting that data itself.

If anyone is trying to hide the fact that they are using bitcoin then encrypting the communication and that data is not going to change anything. The ISP and any MITM can know they are using bitcoin. The only solution for them is to encrypt the entire connection by going through TOR network which is already possible.

ranochigo

legendary

Activity: 2954

Merit: 4158

Quote from: BlackHatCoiner on June 03, 2021, 08:34:16 AM

How's that possible? If I encrypted my transaction separately for each node, none of the ISPs would know which one started it.

Traffic analysis as a deanonymizing attack works best for sybil attacks but not particularly useful for individual transactions.

It is mostly not feasible for mass surveillance as the size of a transaction is so small and there is definitely some delay before it reaches one of their monitoring nodes. Traffic is constantly being used most of the time a 300 byte spike gives little to no indication unless you're specifically being targeted. At which point, traffic analysis would be the least of your worries.

Quote from: BlackHatCoiner on June 03, 2021, 08:34:16 AM

Hadn't thought of this, thanks! Although, I'm not sure if it's legal for an ISP to do that. Besides, whether they intend to perform this or not, wouldn't be better to try at least be more private? I feel that it's better than just throwing the raw transactions into their face.

Legality is not in the question here. The user doesn't have to know.

Without being sure that the connection is authentic with no MITM, an encrypted connection is practically useless.

Quote from: BlackHatCoiner on June 03, 2021, 08:34:16 AM

Can I have a brief explanation of why MITM attacks can't happen with certificates?

MITM attacks can happen and has already happened with certificates, self-signed or not. Self-signed is outright insecure, CA-signed is merely as useful if the ISP/government doesn't have the means to coerce some trusted CA to make one for them. Being sure of the stream being encrypted with no MITM requires the user to specifically verify that the certificate is correct with the owner of the other node, or trust the CA to be certifying them correctly.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: BlackHatCoiner on June 03, 2021, 08:34:16 AM

Quote from: pooya87 on June 02, 2021, 10:44:35 PM

If we start adding certificates and then certificate authorities we first make running a full node harder

Can I have a brief explanation of why MITM attacks can't happen with certificates?

They still can (if you recklessly ignore warnings about changed fingerprints), but since each client's fingerprint is generated from the public key inside the certificate, that means everybody's fingerprint is different. In order for a MITM attack to happen first, they have to somehow close the old connection and then open a new one to them which has their fingerprint, which will not match the fingerprint of the old connection to the original server.

At this point, a sensible person would abort the connection realizing that they are being surveilled.

BlackHatCoiner

legendary

Activity: 1344

Merit: 6415

Farewell, Leo

Quote from: PrimeNumber7 on June 02, 2021, 07:34:04 PM

Your only real option would be to connect to a VPN

I believe that the problem should be tackled directly from its root and not by any other privacy layers like a VPN. Even if you connected to a VPN and exchanged encrypted information, you'd still be exposed if you went through the non-Tor network. The ISP of the VPN could see the what's your node broadcasting.

Quote from: PrimeNumber7 on June 02, 2021, 07:34:04 PM

Even if encryption was used for initial broadcasting of transactions, similar analysis could be used to conclude that your node broadcast the transaction, with more data being looked at.

How's that possible? If I encrypted my transaction separately for each node, none of the ISPs would know which one started it.

Quote from: pooya87 on June 02, 2021, 10:44:35 PM

And how would they exchange this key? It has to be on an unencrypted channel which means the ISP can MITM attack it and hand over their own key to you while still sniffing your packets.

Hadn't thought of this, thanks! Although, I'm not sure if it's legal for an ISP to do that. Besides, whether they intend to perform this or not, wouldn't be better to try at least be more private? I feel that it's better than just throwing the raw transactions into their face.

Quote from: pooya87 on June 02, 2021, 10:44:35 PM

If we start adding certificates and then certificate authorities we first make running a full node harder

Can I have a brief explanation of why MITM attacks can't happen with certificates?

ranochigo

legendary

Activity: 2954

Merit: 4158

Quote from: NotATether on June 03, 2021, 01:42:00 AM

Using Diffie-Hellman handshake. In fact, that's how TLS certificates for web are exchanged on unencrypted connections.

Without authentication, it would still be vulnerable to MITM attacks. As long as you persist your MITM throughout, it won't be detectable without the parties authenticating. I don't think it is possible to authenticate effectively between Bitcoin nodes, especially since there is no way to validate each others identity.

Quote from: NotATether on June 03, 2021, 01:42:00 AM

You're right about the centralized part but as far as price is concerned they could just self-sign one. I would opt not to use a CA since they can make all certificates expire at the same time which would be harmful to the bitcoin network.

Self-signing certificate is as good as not having a certificate at all. The purpose of a CA is to provide assurance that the certificate given is valid. If it is self signed, there is simply no way for them to validate the certificate. Even if you do have a CA, the reason why ISPs would be spying on you probably involves your government as well. CAs can be compromised and issue rogue certificates as well.

Quote from: NotATether on June 03, 2021, 01:42:00 AM

But yeah, if you want your raw transactions to be encrypted then just run your node behind Tor, since each hop will encrypt the rest of your traffic anyway. I doubt that distributing certificates to everybody for cleartext encryption is feasible.

I agree. If you are afraid of your ISP eavesdropping, then you should be running Tor or some VPN in the first place.

Quote from: ?? on ??

Which status is withdrawn, so i doubt it'll be implemented anytime soon.

There is another proposal under another BIP. I don't think it is officially merged into the BIP repo.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: pooya87 on June 02, 2021, 10:44:35 PM

And how would they exchange this key? It has to be on an unencrypted channel which means the ISP can MITM attack it and hand over their own key to you while still sniffing your packets.

Using Diffie-Hellman handshake. In fact, that's how TLS certificates for web are exchanged on unencrypted connections.

Quote from: pooya87 on June 02, 2021, 10:44:35 PM

If we start adding certificates and then certificate authorities we first make running a full node harder (since nodes have to create that certificate and pay for it too) and also we add a centralized layer to an otherwise decentralized system.

You're right about the centralized part but as far as price is concerned they could just self-sign one. I would opt not to use a CA since they can make all certificates expire at the same time which would be harmful to the bitcoin network.

But yeah, if you want your raw transactions to be encrypted then just run your node behind Tor, since each hop will encrypt the rest of your traffic anyway. I doubt that distributing certificates to everybody for cleartext encryption is feasible.

pooya87

legendary

Activity: 3402

Merit: 10424

Quote from: BlackHatCoiner on June 02, 2021, 04:06:23 PM

Preferably, I could think that if each node shared information encrypted by firstly exchanging an ECC key (asymmetrical) then ISPs wouldn't have that power.

And how would they exchange this key? It has to be on an unencrypted channel which means the ISP can MITM attack it and hand over their own key to you while still sniffing your packets.
If we start adding certificates and then certificate authorities we first make running a full node harder (since nodes have to create that certificate and pay for it too) and also we add a centralized layer to an otherwise decentralized system.

PrimeNumber7

copper member

Activity: 1610

Merit: 1898

Amazon Prime Member #7

Your only real option would be to connect to a VPN (or a VPS acting as a VPN) that is located in a place that it is not subjected to these types of surveillance. If all of the world is subject to this kind of surveillance as is every ISP, you will have to use TOR to broadcast your transaction, but with that level of surveillance, you would probably be subjected to a timing attack.

Even if encryption was used for initial broadcasting of transactions, similar analysis could be used to conclude that your node broadcast the transaction, with more data being looked at.

j2002ba2

full member

Activity: 204

Merit: 437

Nodes share transactions in "plain text", nothing is encrypted. If you want to broadcast a transaction without leaving trace, there are two options. Use a node behind TOR, or the broadcast service of certain websites (while using torbrowser of course). The second option might be easier, for example blockchair has an onion address, and has transaction broadcast page.

ranochigo

legendary

Activity: 2954

Merit: 4158

Quote from: BlackHatCoiner on June 02, 2021, 04:06:23 PM

I haven't looked into the source code by myself, but I doubt if there's an encryption method when I firstly broadcast my transaction to node(s) and then, when they share it with each other. This is exclusively for Bitcoin nodes (full nodes) that run the network and not for electrum servers that are sometimes under a secure socket layer (SSL).

We don't. There was a BIP (BIP 151) which was proposed for end-to-end encryption but even that assumes that the certificate was exchanged in a secure manner. You cannot just trust certificates announced by your peers, you need to ensure a secure connection to obtain them. It'll be better for the user to just run it on VPN or Tor. DH exchange would be useful for situations like this.

Quote from: DireWolfM14 on June 02, 2021, 06:00:30 PM

I would guess that most electrum servers have self-signed SSL certs, which does little to prove the trustworthiness of the operator, but it does encrypt the data. That makes sense for electrum because a lot of personal information is transmitted to the server, including master public keys if I'm not mistaken. The privacy concerns for using an unencrypted electrum server are far more severe than sending a single transaction to a node.

Self-signed is not necessarily less secured than CA issued. There were cases where CAs were helping governments to sign certificate to spy on their own citizen. It is nothing out of the realm of possibility for this to happen if the government wants to do so. Electrum stores the certificate of the servers in their own data directory. I'm not sure how the certificate gets obtained but I guess it comes pre-bundled with the installation. I'll check the codes later and modify this if needed.

DireWolfM14

copper member

Activity: 2142

Merit: 4219

Join the world-leading crypto sportsbook NOW!

As far as I know there's no way to add SSL to your node. I haven't seen anything in the commands or options to suggest that Core is compatible with a SSL cert. Honestly I don't know enough to determine if it would be a valuable addition. If it was I imagine it would have been discussed and implemented long before now.

I would guess that most electrum servers have self-signed SSL certs, which does little to prove the trustworthiness of the operator, but it does encrypt the data. That makes sense for electrum because a lot of personal information is transmitted to the server, including master public keys if I'm not mistaken. The privacy concerns for using an unencrypted electrum server are far more severe than sending a single transaction to a node.

The most obvious solution is to run your own full node. Then you wouldn't be transmitting anything through your ISP.

BlackHatCoiner

legendary

Activity: 1344

Merit: 6415

Farewell, Leo

I haven't looked into the source code by myself, but I doubt if there's an encryption method when I firstly broadcast my transaction to node(s) and then, when they share it with each other. This is exclusively for Bitcoin nodes (full nodes) that run the network and not for electrum servers that are sometimes under a secure socket layer (SSL).

If there isn't one and the raw transactions are exposed to ISPs on broadcasting, doesn't that mean privacy ruination? Taking into consideration the anti-terrorist law, every provider is forced to keep the headers of each package. Incredibly huge volume of files and their storage may expose you to the government. Example: If provider A was the first one that sent this raw transaction, then they've already excluded thousands of possible suspects and that's probably the signer.

Preferably, I could think that if each node shared information encrypted by firstly exchanging an ECC key (asymmetrical) then ISPs wouldn't have that power.

Topic: Broadcasting the raw transaction encrypted? - page 2. (Read 512 times)