Topic: Broadcasting the raw transaction encrypted? (Read 575 times)

Thanks for sharing!

True, but usually people wouldn't go somewhere too far from their house (usually on same / nearby city).


Just don't forget public WiFi have some security risks which might affect your privacy.

Additionally some website protect itself against DDoS using provider such as CloudFlare which use JavaScript to check whether you're human or actually use browser.

Not even close.
Was not even in NY when I grabbed the IP.
Which was the point of why I said it. Heck even the PTR part of the address points back to the fact that it is coming from an NYC pool of addresses.
pool-72-68-219-28.nycmny.east.verizon.net
I know that most of the geo databases are becoming more and more inaccurate as time goes on. With, for lack of a better term, "long term DHCP reservations" for devices becoming more common. Here in NY Fios and cable modem / routers will grab an IP for weeks or even months. Then for whatever reason, they change. But there is a long lag for the geodatabases to update. AND here is the fun part with larger and larger networks all pulling back to one central point the pools of IP addresses are becoming more spread out.


Probably, unless you are making a deliberate decision to go far away.

Years ago also some hotel chains also had their free Wi-Fi (possibly other areas) all go thought corporate. So no matter where you were, when you connected it came through an IP that looked like it was in Chicago. So while the hotel chain would know were you were, nobody else could really.

-Dave

According to https://whatismyipaddress.com/ip/72.68.219.28 the IP address 72.68.219.28 is associated with a location in Garden City, New York.

I do agree that using public WiFi does give most users plenty of privacy. One thing that I might point out about using public WiFi at a coffee shop, or small pizza joint, or similar is that it will not be obvious to most that you are not using your home internet. You are almost hiding in plain view. If someone sets up many nodes to monitor the IP addresses that transactions originate from, it will be obvious when a transaction originates from tor. Also, if too few people use tor to maximize their privacy, the use of tor might be a fingerprint of its own when someone is looking at transactions trying to break or reduce privacy.

Depends on where you are doing it.
Once again, I can say that where I am if I use the local pizza shops Wi-Fi it's going to get you as far as the provider (Optimum / Altice) they will know where you are. The rest of the world can just see that you are in their ip range. And their very general geographic footprint. https://search.arin.net/rdap/?query=69.124.219.35 is where I got dinner last night.

Verizon Fios is even worse: https://search.arin.net/rdap/?query=72.68.219.28 Tell me what coffee shop that came from. Heck, tell me what state.


If you are just grabbing your day to day laptop and using the same web browser you use all the time to broadcast it, then yes.
If you are just grabbing your day to day laptop and using a different browser in private mode then sort of.
If you are using your day to day laptop but booted with a live CD then it's another story.

Just depends on how far you want to go for privacy.....

-Dave

Won't work. The site restricts connections from Tor exit nodes or through its onion address, no matter what UA it is using. It would be quite bad for the site if they're restricting you based on your UA instead of your IP. API calls don't consume more bandwidth or resources to pose a problem.

Have you tried filling the user agent with a bogus browser value like the ones for Google Chrome or Firefox, in order to trick the hidden service into not giving you a captcha by making it think that your connection is not from a command-line fetcher, but from one of those browsers?

The point of doing something like this is to eliminate the browser, what you send here is exactly what you want opening a connection to the remote server and sending a single POST request whereas using a browser you keep the connection open and the remote server can communicate a lot more with you exploiting many things to de-anonymized, such as exploiting WebRTC, finger-printing, abusing the persistent data stored in the browser in previous visits, ...

If you are using one of these services, just going to a random open Wi-Fi and using one of them would probably be just as anonymous as using TOR.
Every place I go to now has some form of "free wi-fi"  opening a web page and copy / pasting a TX and nothing else is just about as anonymous as you can get.
Windows / MAC / Linux all allow you to use a custom MAC address for your Wi-Fi so you can even alter that.

Once again from the I'm in the US and have a ton of options for this.

-Dave

Here is a list of some transaction broadcasting services: https://en.bitcoin.it/wiki/Transaction_broadcasting

Since gmaxwell mentioned that TorBrowser might leak identifying information, here are some ways of submitting the transaction from command line, after firing up TorBrowser or Tor service. These are the ones, which were working at the time I tested.

rawtransaction is the usual hex-encoded one. For windows+torbrowser use port 9150.

blockstream.info:

blockchair.com: (connection to the onion service is blocked by captcha)

blockchain.info:

Unfortunately many people have no idea how close to a total privacy loss using most any light/mobile wallets is (even over tor)... it doesn't help that they've been actively misinformed.  But in general, people seem to have a hard time reasoning about privacy--  they want it, but seem to forget they want it, and give it up easily.  The harms are just too vague and distant sounding much of the time.

It must have been a while since you have done it. Now, if Cogent wants to talk to Hurricane Electric at most DCs Cogent has their equipment on their side, Hurricane has on their side and the fiber is provided by the facility. Obviously if either provider owns the DC is different, but most these days are carrier neutral facilities.

This is in the US, I really don't know how it is in other parts of the world.


Over time, yes they would get sued and yes people would add authenticated links. I was talking about the what happens tomorrow part of it.
If Apple was doing it and Google was not. How many users would switch from IOS to Android when they found out they were being monitored was more my point. Sorry, did not express it properly.


None, I think it's good. I was just pointing out that there are so many other places for 'bad things' to happen.

---

A bit OT but, with most people using light / mobile wallets it makes you wonder if anyone outside of a very very small group really cares.
If you are using a node / service that is not under your control to transmit your transactions you have already given up a bunch of privacy.

-Dave

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.

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


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.

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.

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?

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.

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.

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

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.

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.

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

It isn't designated as a BIP yet in the main repository.
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.

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.

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.


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.

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.

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.

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.

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

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.

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

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.

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.

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

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

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


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.

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.

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.

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.

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.
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.

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.

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.