Broadcasting the raw transaction encrypted?

[BlackHatCoiner]

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.

[1714296214]

1714296214

[DireWolfM14]

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.

[ranochigo]

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.

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.

[j2002ba2]

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.

[PrimeNumber7]

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.

[pooya87]

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.

[NotATether]

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.

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.

[ranochigo]

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.

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.

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.

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.

[BlackHatCoiner]

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.

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.

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.

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?

[NotATether]

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.

[ranochigo]

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.

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.

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.

[pooya87]

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]

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.

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.

[gmaxwell]

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.

I really wanted to merit your post but I can't with that blockchair recommendation,  I would take an extremely sizable bet that blockchair was surveilling users -- It's run by a russian "AML specialist" who removed the AML bragging from his twitter immediately before starting a bizarre campaign against taproot. Blockchair gives the opposite of good advice on txn privacy, it rates poor privacy transactions as good and good privacy transactions as bad.

Even using it via tor there are lots of ways to fingerprint tor browser. It's certainly better than *not* using it.  But I wouldn't recommend contacting a party which is almost certainly secretly surveilling users even with it.

Your other advice to use tor, that's good advice and what I was gonna post except you already did.

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

This isn't true, FWIW.

Without encryption monitoring can be completely passive: Extremely cheap and totally undetectable (except by leaking monitored data, of course). It can even be hard for a network operator to know that someone is passively monitoring their links.

With encryption, the attack much be active. This makes is much more expensive-- instead of just scanning and logging data you have to get into the protocol, perform encryption/decryption, it scales much more poorly.  The intercept can't be a passive tap, it has to be in the path.  The active interception is always at risk of discovery, potentially after the fact, and when the monitoring would be *unlawful* or contrary to disclosed public policy, getting caught would be bad news.

For Bitcoin, the proposed opportunistic encryption logs an session ID into each side's logs when they connect (and would display in peer stats).  If there is an active MITM these session IDs will not match.  Even if a tiny percentage of users ever look a wide scale MITM would eventually get caught.

Further than that in Bitcoin I also proposed an authentication protocol where a MITM fundamentally cannot tell if authentication is in use, so he cannot selectively MITM non-authenticating users and avoid MITM-ing authenticating users.  Any MITM attempt then has the risk of immediately alerting the user.  This way a small number of authentication users provides herd resistance for everyone else.

Of course, these measures are not perfect-- but nothing in security is perfect.  These measures are about an improvement.  Even just pushing attackers into doing active interception makes targeted dragnet surveillance considerably more expensive.  Of course, if you have stronger measures available you should still use them, but the inherent of complexity of authentication (e.g. what is an 'identity'??) means that often stronger isn't available.  Unencrypted shouldn't be the default, encryption is cheap and even without authentication it can provide strong protection against some attack models even though it is fundamentally limited.  It's not a replacement for an authenticated channel, but it is by no means useless.

The CA model has its own serious flaws.  For example, nation-state adversaries can just arbitrarily print certificates, ... as well as network attackers, pretty much:  If you can active intercept traffic on the path between and public certificate authority and an IP address that a target domain name resolves to, you can get that CA to issue you a certificate.  So in practice, the HTTPS CA model provides almost zero security form active network attackers who are positioned near the webserver.  The unfortunate fact about the HTTPS CA model is that because you need to get a cert to usefully use HTTPS at all, it has to be extremely easy to get a cert, and unfortunately that also makes it easy for some kinds of attackers to get them too.

[DaveF]

With encryption, the attack much be active. This makes is much more expensive-- instead of just scanning and logging data you have to get into the protocol, perform encryption/decryption, it scales much more poorly.  The intercept can't be a passive tap, it has to be in the path.  The active interception is always at risk of discovery, potentially after the fact, and when the monitoring would be *unlawful* or contrary to disclosed public policy, getting caught would be bad news.

That would really depend on a few factors. Saying it is "much more expensive" is a bit general. For your average person in terms of hardware / time / effort it might be.
For any nation  / state / large business it's irrelevant. There is off the shelf hardware that can do it. In most (all?) major data centers you don't even know where your fiber is going. If I put in a request for a link to Cogent I get a fiber pair that shows up in my cabinet. I have to assume that it goes from my location to a patch panel that goes back to Cogent. If someone put something in that path that could record and / or monitor everything I would never know; and since it's a secure facility I just can't walk into the meat-me fiber / copper room to see where the cables go.

Same with getting caught. If tomorrow it was found out the Apple was monitoring all BTC transactions that happened on iPhones. I would predict the following would happen:

The Android fans would jump up and down screaming "I told you so"
The Apple fans would excuse it.
The uber privacy freaks would still be using an offline wallet to create transactions which were then transmitted thought another way.

And the other 99.99% of people using BTC and crypto would continue without a thought.

-Dave

[PrimeNumber7]

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.

The OP is saying that the transaction will be encrypted when it first broadcasts the transaction. The encryption algorithm will be public, and if you know the encryption algorithm, you know that sending n bytes will result in f(n) bytes. A government adversary could review the logs of data transmitted, and look for the first instance of data being sent via port 8333 that is f(n) bytes, with n being the size of the transaction in bytes.

If a government is running a node, they will know about every valid transaction that is valid. In the OP's scenario, the government will also know all peers of each node because bitcoin uses port 8333 to communicate with other nodes.

[gmaxwell]

For any nation  / state / large business it's irrelevant. There is off the shelf hardware that can do it. In most (all?) major data centers you don't even know where your fiber is going. If I put in a request for a link to Cogent I get a fiber pair that shows up in my cabinet. I have to assume that it goes from my location to a patch panel that goes back to Cogent. If someone put something in that path that could record and / or monitor everything I would never know; and since it's a secure facility I just can't walk into the meat-me fiber / copper room to see where the cables go.

Not sure about your operations, but prior tier-1 networks I've worked with, if it's their equipment on both sides of the link they'll get notified when the packet counters on each side differ too much (indication that the link is silently losing or duplicating packets), which they eventually will if you're actively intercepting traffic.

Similarly, if there is actually active equipment on the line there is a non-trivial chance of noticing that you've still got light up when the other side is powered off.  And if you loop the far end and stick an analyzer or OTDR on the path you're going to immediately notice the active device (though, I can think of only twice I've ever stuck an analyzer on a colo cross connect, it does happen from time to time).

And sure there is commercial hardware available to do interception, but it is less expensive and more scalable to just stick in an optical tap, throw an interface in "half-duplex up" mode, and filter packets off to a collector.  Moreover, we know for a fact that the US's pervasive surveillance infrastructure works exactly that way.

(A passive tap isn't invisible to an OTDR, but it's close to it... you probably wouldn't be able to distinguish it from a crappy mid-span patch)

Though less applicable to Bitcoin alone, if you start trying to do key agreements and decryption for all the traffic e.g. on a 8x100G lag it gets extremely costly (and exits the domain of COTS hardware), while fishing through plaintext traffic for simple matches is cheap and commercially available.

Passive monitoring is essentially undetectable, active isn't. And opportunistic encryption is easily upgraded to fully authenticated just by authenticating the session. What serious reason would you have to oppose adding 0.001% cpu usage in order to upgrade from no resistance to some (even if arguably weak) resistance?

Same with getting caught. If tomorrow it was found out the Apple was monitoring all BTC transactions that happened on iPhones. I would predict the following would happen:

You're missing the point where apple gets sued over it, which I can guarantee would happen.  You also miss the point where this would justify people doing the extra work of adding authenticated links which would happen to some degree, if not as much as we might hope.

But if it's literally impossible to detect, none of that will happen.

The OP is saying that the transaction will be encrypted when it first broadcasts the transaction. The encryption algorithm will be public, and if you know the encryption algorithm, you know that sending n bytes will result in f(n) bytes. A government adversary could review the logs of data transmitted, and look for the first instance of data being sent via port 8333 that is f(n) bytes, with n being the size of the transaction in bytes.

That isn't how link encryption works.

Every participant uses a key agreement protocol to establish a random secret key between themselves and each of their encrypted peers. So the data sent is some F(data, key) and the key is private to each pair of participants.  As a result, even if you know data later, you can't go looking at other traffic for f(data, key) because you don't know the respective keys.  This is how every encrypted network protocol works.

Edit: On re-read it wasn't clear to me if you were actually talking about sizes as a side channel, rather than matching content.  It's not unusual for encrypted protocols to add padding to weaken traffic analysis.  In Bitcoin many transactions are exactly the same size, and the proposed encrypted transport is carefully designed so that it avoids leaking the size of individual transactions (in so much as it can-- e.g. usually multiple txn are relayed at once and the protocol doesn't leak their individual sizes), and it also supports padding.

[PrimeNumber7]

The OP is saying that the transaction will be encrypted when it first broadcasts the transaction. The encryption algorithm will be public, and if you know the encryption algorithm, you know that sending n bytes will result in f(n) bytes. A government adversary could review the logs of data transmitted, and look for the first instance of data being sent via port 8333 that is f(n) bytes, with n being the size of the transaction in bytes.

That isn't how link encryption works.

Every participant uses a key agreement protocol to establish a random secret key between themselves and each of their encrypted peers. So the data sent is some F(data, key) and the key is private to each pair of participants.  As a result, even if you know data later, you can't go looking at other traffic for f(data, key) because you don't know the respective keys.  This is how every encrypted network protocol works.

This is only true if “key” is different for every node pair. If “key” is constant for a node, regardless of who is connecting to it, an attacker can trivially collect all “keys” for nodes, and act accordingly. If “key” changes for every peer a node connects to, it would make a MITM attack impossible to detect. If nodes publish all “key” values for each connection, an attacker could collect this information and act accordingly. Ditto if a nonce is added to key values, as an attacker could run the analysis with many nonce values.

[gmaxwell]

This is only true if “key” is different for every node pair.

It always is, there is no widely used encrypted network protocol that works otherwise.  Even when you authenticate using a static key.

If “key” is constant for a node, regardless of who is connecting to it, an attacker can trivially collect all “keys” for nodes, and act accordingly. If “key” changes for every peer a node connects to, it would make a MITM attack impossible to detect. If nodes publish all “key” values for each connection, an attacker could collect this information and act accordingly. Ditto if a nonce is added to key values, as an attacker could run the analysis with many nonce values.

Nah,  encrypted network protocols work through a mechanism like this:

At connect time, each side picks a new random private key and sends the other side the corresponding public key.  Each side uses their private key and the other side's public key to compute a common shared secret S.

Hash1(S) is used to set the encryption keys for the channel. Hash2(S) is available to the user as a session-id, inside the encrypted transport one party can send Hash3(S||"password")✝ as a simple way to authenticate the session, or they could send a digital signature of Hash3(S) to authenticate the session if pubkey key auth is used.  You can't get back to S from any of the different hashes of it, and both parties contribute randomness to S.

So the encryption key is always distinct, and there is no problem authenticating the connection without breaking confidentiality.

One reason this sort of model is pervasive is because for many popular ciphersuites (any "CTR" mode) the security is obliterated if participants ever reuse a key in separate communications, so the keys need to be random and drawn from a space where reuse will practically never occur.

You'd be right if things worked the way you were thinking, but they don't-- people thought through the problems you're thinking of and solved them a long time ago.

✝ technically they should use more complicated schemes which avoid leaking information that could be used to bruteforce the password, but for this discussion the simple version is a good enough example.

[PrimeNumber7]

For Bitcoin, the proposed opportunistic encryption logs an session ID into each side's logs when they connect (and would display in peer stats).  If there is an active MITM these session IDs will not match.  Even if a tiny percentage of users ever look a wide scale MITM would eventually get caught.

Nah,  encrypted network protocols work through a mechanism like this:

At connect time, each side picks a new random private key and sends the other side the corresponding public key.  Each side uses their private key and the other side's public key to compute a common shared secret S.

Hash1(S) is used to set the encryption keys for the channel. Hash2(S) is available to the user as a session-id, inside the encrypted transport one party can send Hash3(S||"password")✝ as a simple way to authenticate the session, or they could send a digital signature of Hash3(S) to authenticate the session if pubkey key auth is used.  You can't get back to S from any of the different hashes of it, and both parties contribute randomness to S.

Assuming there is no known way to calculate Hash1(S) based on Hash2(S), I would agree with you. I had not considered that multiple hash functions could be used to encrypt data and calculate a truely_public key.

If Hash1 or Hash2 are ever reverse engineered to allow someone to calculate the input based on the output, an attacker would be able to execute a timing attack as I describe, but this would violate your constraints, and is probably not a reasonable concern. Bruteforcing the Hash2 function to calculate an output that is equal to the output of Hash2(S) is also probably not reasonable.

I do see one potential vulnerability to what you describe:
An attacker could execute a "false flag" type operation, in which they intentionally publish incorrect 'session IDs' for a percentage of their peers. This might discredit any actual reports of 'session IDs' not matching what they should be, and could hide actual MITM attacks.