pull down to refresh
0 sats \ 1 reply \ @eltordev 3 Apr \ parent \ on: Boltz AMA ⚛️🔁 AMA
For now 😈 Keep an eye peeled on what is brewing in the kitchen https://github.com/el-tor
Hey Lopp,
In regards to timing attacks, it's a pretty well studied topic and a lot of good research is documented here - Thirteen years of Tor Attacks - https://github.com/Attacks-on-Tor/Attacks-on-Tor Much of the timing attacks can be mitigated by incentivizing more independent individuals to run relays. The "High bandwidth" tagline is just simply the idea that more incentivised relay operators can lead to more overall bandwidth for the network. Currently the total aggregate bandwidth of the traditional Tor network is about 800 Gbit/s. My home network has gigabit fiber, so this number can probably be greatly increased and decentralized with a bitcoin incentive.
The Classic Relay Conundrum:
To go into more detail about timing attacks, one of the sneakiest attacks happens when the same person or entity controls both the entry and exit nodes of your Tor circuit. Imagine this: you're sending your data through a tunnel, but both ends of the tunnel are under the same roof. This setup allows for statistical correlation and timing attacks, where attackers can match traffic entering and exiting to de-anonymize users.
Current Mitigation Tactics:
Tor's defense? "Entry Guards." You pick a trusted entry node and stick with it for days, even months, betting on the hope that your entry and exit aren't controlled by the same malicious entity. But here's the catch - with only about 8,000 relays, many managed by NGOs/charities/maybe bad actors, the diversity isn't as robust as we'd like.
A Solution? More Individual Relays, Bigger Anonymity Set:
To beef up security, we could incentivize a broader range of individuals to operate relays. Imagine if running a relay got you paid. Suddenly, you've got a larger, more diverse set of nodes, making attacks harder to pull off. Plus, with more users jumping on Tor due to faster speeds, the anonymity set grows even larger. Adding techniques like data padding and latency padding, as suggested in various research papers, could further fortify Tor against these threats.
Lightning Network: Privacy in the Age of Speed
Switching gears to the Lightning Network, privacy is getting a boost with innovations like BOLT 12 and BOLT 11's blinded paths. These features blind the receiver's identity/path, making it tougher to track transactions. The Lightning Network's adoption is on an upward trajectory, but it's the unannounced channels and blinded paths that keep the growth under wraps, making monitoring and usage stats a challenge (which is good).
User-Friendly Innovations:
Tools like Alby Hub and Phoenixd are making Lightning more accessible. As these platforms evolve, they could significantly expand the user base, enhancing both privacy and usability. Plus users already running Umbrel and Start9 make them a great candidate for earning sats hosting a relay.
Check out the El Tor Specs here https://github.com/el-tor/eltord/tree/master/spec/
El Tor and Tor are two separate networks (for many technical reasons) but we are architecting the El Tor daemon (eltord) and VPN-like apps (eltor-app) to detect what network you are attempting to route thru.
For instance, if you are trying to access your existing start9 that runs on the existing Tor network it will route thru a free circuit (since the introductory and rendezvous nodes are on the original Tor network).
If you are trying to route to a hidden service on El Tor (or even just a clearnet website) it will detect that you configured a wallet and will look up paid relays and their rates via the El Tor Directory Authorities. Then it will build a paid circuit.
The digram above shows much of this logic occurring in the SOCK5 load balancer/proxy in eltord. The goal is to create a modular daemon that could run in Start9, Umbrel, Mobile Apps, etc... and be a drop in replace for Tor.
Cheers! New repo and architecture diagram here https://github.com/el-tor
Flaws
"Nation-states have a higher chance of successfully de-anonymizing users due to their resources."
"Tor’s privacy features become stronger if its nodes are decentralized around the world."
"If the Tor network had an even number of nodes in, say. every country, then it would take a significant amount of cross-border investigative work to get timing analysis done."
Fixes?
El Tor is trying to fix this by incentivizing the relay operators.
https://devpost.com/software/el-tor
14.9k sats \ 1 reply \ @eltordev 17 Jul 2024 \ on: El-Tor: High Bandwidth⚡️Tor Network Release! builders
deep state took the video down. here is a new link https://www.youtube.com/watch?v=smS18ZO9fes
Also available on rumble https://rumble.com/v57bp7h-el-tor.html
https://github.com/Indra-Labs/indra Cool architecture. I read the whitepaper. But it appears very ambitious and possibly abandoned. Tor has existed for over 20 years. Has good funding and a strong community. The codebase is solid and well audited. So simply shimming "lightning" in the code was very low hanging fruit to pragmatically solve the problem. It is not trivial creating low level routing software that can handle high bandwidth from scratch (especially in a well suited programming language like C) . Might as well use what already exists. Bolt12 offers (with blinded paths) was really the catalyst to make this fairly easy to do
Not sure what is meant by "anonymously" but you would be putting your IP address up in the Directory list (thats just how Tor currently works). For example, @C_Otto shared his Tor relays in the post above #609650
A really cool goal to work towards is to popularize more use of "Tor Hidden Services". Right now its hard to visit a
.onion site because the names are not human readable.
For example in "Clearnet" if you goto https://google.com it looks up via DNS the ip address 142.250.114.100.The idea: Gamer Tags (Onion Short names)
It would be cool to build a similar human readable naming system for "short onion addresses". For example mapping stackers news onion address http://snsnsnya6h3ot563f3p566wuhfoklkg5f62hokdlaqzcaub3gf4xlxyd.onion to something like http://crazyhorse69.onion.
There are several ways to do this, but it would be nice to do it in a decentralized way. Bitcoin is decentralized and we all already own sats. So maybe we could create a deterministic list of words (and maybe a few numbers) to create a "gamer tag" like
crazyhorse69.The deterministic list can be an imaginary overlay, ordinally ordered list, that maps each "gamer tag" to a single satoshi (sort of like the original ordinal theory that Casey pitched) but with more human readable names. We would simply just need to mash up enough words (and a few digits) to make 2.1 quadrillion "gamer tags" that map to each individual satoshi. (sort of like we have a standard list of words that go into your BIP-39 seed phrase https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt)
Then anybody who already owns satoshis already has a basket of "gamer tags" they can choose. They they can simply sign a message with that key for the mapping. Really anything can be mapped. Doesn't just have to be onion addresses
yep exit nodes too. an exit node might want to charge a higher rate for this service due to more risk sharing his public IP addresses. Some mitigation could be running OpenDNS on the exit node. The Tor project has few blog posts on best practices running an exit node.
A cool novel idea is to only run the exit node when you are on public shared wifi like a coffee shop (is wardriving still a thing lol). Not sure how this would exactly work but maybe a dedicated app could be built using privacy tools like mac address spoofer, etc..
Thanks! Great point!
It is still early. Just the basic design and code.
Right now the design depends on the client paying the relays out of band for a 10 minute circuit. There is currently no way to guarantee the relays respect this. They could, for example, close the circuit right away and take your precious sats!
In the current design, an easy mitigation could be to pay only half upfront, during the the circuit build step and the other half after 10 minutes, on the circuit destroy step. This would incentivize the relay to keep the circuit open for 10 minutes. You could also keep a black list of unreliable relays and maybe gossip that info on some reputation network.
Another design idea is to use
keysend in the data stream (instead of at the circuit build step).Keysend Goal
Enable clients to pay relays using keysend, ensuring only the intended relay can access the preimage needed to claim the payment after they relay the traffic to the next hop.
Basic Concept
- The client generates a random preimage and its hash.
- The client encrypts the preimage using the public key of the first relay (Relay 1).
- The encrypted preimage and hash are included in the onion-encrypted data passed through the relays.
Steps
1. Client
- Generates a preimage
Pand its hashH. - Encrypts
Pwith Relay 1's public key to createEnc_PK1(P). - Constructs the onion payload including the hash
HandEnc_PK1(P).
2. Relays
- Each relay decrypts its layer to forward the data, hash
H, and encrypted preimageEnc_PK1(P).
3. Recipient Relay (Relay 2)
- Processes the data and sends
Enc_PK1(P)back to Relay 1.
4. Relay 1
- Decrypts
Enc_PK1(P)using its private key to retrieve the preimageP. - Verifies the payment by checking if
hash(P) = H.
Security
- Ensures only Relay 1 can decrypt the preimage using its private key, preventing Relay 2 or others from stealing the funds.
Will it work in practice?
This might be too slow in the real world though, since it would need to occur at the data stream. Also, not sure how many wallets support keysend currently. It might also be a receiver side privacy concern doxxing the nodes public key (do blinded paths and keysends exists?). Also, the client might try to screw over the relay and send fake payments, since the relay must forward the data stream onto the next hop before receiving payment. Not sure if there is a way to mitigate that with fancy cryptography.
But it would be a fun topic of research.
Tor is ran by volunteers around the world. There is a finite amount of bandwidth for everybody to share. A lot of the relays are funded by human rights organizations (which is great) but also there is no real incentive for a Pleb to run one at home (outside of good will). There is also no way to prove if the majority of nodes are from malicious actors (think deep state) trying to correlate traffic (albeit hard to due). Introducing an incentive will spark a free market of relay operators. Further increasing bandwidth and decentralization.
In regards to a "slow" wallet using tor....if you infrequently open a lightning wallet (particularly on mobile) it might seem slow to start because tor has to sync the directory of relays from the Authority relays (since IP addresses change and the network is always changing). After it gets an updated list of relays it need to build a circuit (typically 4-8) relays. This takes a short amount of time. After that, the circuit typically lasts 10 minutes and subsequent payments should seem faster.
Also, some of the recent flakiness may be due to this: https://x.com/lopp/status/1812500211681370484
Great. It was only a matter of time until someone built this. What's the compatibility like to the rest of Tor? Separated networks? Or using regular Tor as "0 sats" nodes?
Probably a fork. Still early days. Code and architecture here https://bitbucket.org/eltordev/eltor/pull-requests/1
GENESIS