Topic: Broadcasting the raw transaction encrypted? (Read 512 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.