<![CDATA[Spear - General]]>

Code:

Lokinet operates at Layer 3. That's the fundamental architectural distinction and it changes everything downstream. Tor and I2P both operate at Layer 4 (Tor is TCP-only stream-muxed through 512-byte cells; I2P uses garlic routing with its own transport protocols like NTCP2 and SSU2). Lokinet creates a genuine virtual network interface—lokiN or whatever you name it—and routes actual IP packets through onion-routed tunnels using Oxen Service Nodes.



What this means practically for C2: your implant, your beacon, your RAT—whatever you've deployed—doesn't know it's on an overlay. It sees a network interface. You can run UDP. You can run ICMP. You can run raw sockets if you want to be theatrical about it. Tor cannot do this. Tor will never do this. Tor is a SOCKS proxy that thinks TCP is the entire universe.



Session Stability Under Sustained Load



Here's where it gets ugly



Tor under bulk exfiltration:

Throughput typically floors around 200-500 KB/s on a good day with a clean circuit. The problem isn't just bandwidth—it's cell multiplexing overhead and congestion control. Tor's older window-based flow control meant a single congested relay in your three-hop circuit throttled everything. Newer Tor (with congestion control from thePROP-324 work, merged into recent tor releases) improved this significantly using a flow control algorithm that's more BBR-adjacent. But the fundamental issue remains: if your C2 channel and your exfil channel share a circuit, the interactive traffic (beaconing, command responses) gets absolutely starved. You'd need separate circuits with stream isolation, which means multiple SOCKS connections and circuit management logic in your implant. Doable. Annoying.



Circuit rotation is the silent killer. Tor rotates circuits every 10 minutes by default for new TLS connections. For a sustained RDP session or a large file transfer that takes 45 minutes, you're going to eat reconnection events. Your C2 framework either handles this transparently (reconnect logic, session resumption) or you lose the session. Most do not handle it gracefully.



I2P under bulk exfiltration:

I2P's garlic routing and packet-switched design should theoretically handle this better, and in some ways it does. The SSU2 transport (replacing the older SSU) uses UDP, which means you're not fighting TCP-over-TCP meltdown when your C2 traffic is itself TCP-based. That's a genuine advantage.



But I2P's tunnel rotation is aggressive—default tunnel lifetime is 10 minutes, and tunnels are rebuilt proactively, but the rebuild process can still cause momentary drops. For a file transfer, you need your C2 to handle tunnel rebinding. For RDP, you need session persistence across tunnel changes, which RDP can do with autoreconnect but the latency spike during rebinding is noticeable—2-5 seconds of frozen screen.



I2P's bigger problem is network size. Fewer routers means less available bandwidth and fewer path options. You're looking at maybe 100-200 KB/s realistic throughput on most I2P tunnels, sometimes worse. The internal I2P services (eepsites) are fast-ish because traffic stays within the network. Using an I2P outproxy (exit) is rare and usually bottlenecked.



Lokinet under bulk exfiltration:

This is the interesting one. Lokinet's L3 tunneling means you're pushing IP packets through a network of Oxen Service Nodes. The SNs are staked (currently 3750 OXEN per node, I think—don't quote me on current economics), which means they're typically running on dedicated hardware with real bandwidth. Not hobbyist Raspberry Pi relays like a chunk of Tor's network.



Throughput: I've seen reports and testing data suggesting 1-5 MB/s is achievable on good paths, which is substantially better than Tor or I2P. The lack of cell-multiplexing overhead is the primary reason—there's no 512-byte cell framing tax on every packet.



Session stability is where Lokinet's design shines in theory but struggles in practice. The Lokinet address is identity-based (derived from your Ed25519 keys), so in principle, path changes between SNs shouldn't kill your session the way Tor circuit rotation does. The addressing layer is decoupled from the routing layer. If a SN in your path goes down, Lokinet can re-route through different SNs while maintaining the same endpoint identity.



In practice, the Lokinet client has historically been... let's say developmentally energetic. Memory leaks on long-running sessions, occasional panics in the wireguard-style edge tunnel handling, and the Oxen blockchain dependency means that if chain consensus hiccups (forks, reorgs, SN deregistration events), routing can degrade. The SN set is also smaller than Tor's relay set—roughly 1000-1500 active SNs versus Tor's ~6000-7000 relays—so path diversity is lower.



For large-file exfiltration specifically, Lokinet's L3 interface means you can use standard tools without SOCKS wrapping. Rsync over Lokinet works. SCP works. You could even run a SMB share over it if you hate yourself. The throughput advantage means a 2GB exfil that would take 60-90 minutes over Tor might complete in 10-15 minutes over Lokinet.



Remote Desktop — The Decisive Factor



RDP/VNC over Tor is miserable. The latency floor is high (200-400ms minimum due to three-hop circuit), TCP-only means any packet loss compounds through TCP retransmits on top of the overlay's own reliability, and circuit rotation disconnects your session. I've seen operators use Tor for initial access beaconing and then pivot to a direct connection or alternative channel for any interactive work because Tor just can't sustain RDP.



I2P is slightly better because of UDP transport, but the small network and tunnel rotation still produce a jittery experience. Maybe 150-250ms latency with periodic 2-5 second freezes during tunnel rebuilds.



Lokinet should be the clear winner here. UDP works natively, latency is typically 80-150ms (two-hop through SNs, no exit needed if your C2 is hosted as a Lokinet SNApp), and the identity-based addressing means path rerouting doesn't necessarily kill the session. RDP over Lokinet, with a SNApp-hosted C2 endpoint, is the closest thing to a "normal" remote desktop experience you'll get on an overlay network. You'll still feel the latency—this isn't a direct connection—but it's usable for sustained interactive work in a way Tor simply is not.



The Honest Tradeoffs



Lokinet's weaknesses:



Maturity. Tor has 20+ years of hardening, academic scrutiny, and active adversarial testing. I2P has nearly as long. Lokinet is younger, fewer security audits, fewer people trying to break it (which means fewer people finding and fixing breaks). The codebase has improved significantly but it's not battle-tested the way Tor is.

OPSEC footprint. Running a Lokinet client on a target machine leaves a different signature than Tor. Tor is detected by everything—EDR, network monitoring, the janitor. Lokinet is less commonly flagged but its traffic patterns and the Oxen SN discovery protocol are fingerprintable if someone's looking. The SN polling traffic and Lokinet's handshake characteristics are distinctive.

Exit node exposure. If your C2 architecture requires exit traffic (connecting to a clearnet C2 server rather than a SNApp), Lokinet exits are staked and identifiable. An exit operator is a known entity in the Oxen network. Tor exit relays are also identifiable, but there are thousands of them and the operator base is diffuse. Lokinet has fewer exits and they're more tightly coupled to the Oxen staking economy.

Blockchain dependency. If Oxen chain has consensus issues, SN set changes, or economic attacks, routing stability is affected. Tor and I2P don't have this dependency—relay operators just run software.

                               ! recommendation !



If you're building C2 infrastructure for sustained interactive access with large-file exfil requirements, the layered approach is what actually works in practice:



Initial beaconing / fallback: Tor. It's noisy but it's reliable and has the largest pool of potential exits. Use it for low-bandwidth command channels and as a backup.

Interactive sessions (RDP, shell): Lokinet, hosting the C2 as a SNApp so you never need exit traffic. The latency and UDP support make it the only overlay where RDP is genuinely usable for prolonged sessions.

Bulk exfiltration: Dedicated circuit. Either Lokinet (if throughput is the priority) or a separate Tor circuit with stream isolation (if OPSEC redundancy is the priority). Don't mix exfil traffic with interactive traffic on any overlay—congestion will degrade your interactive session.

Code:

Lokinet operates at Layer 3. That's the fundamental architectural distinction and it changes everything downstream. Tor and I2P both operate at Layer 4 (Tor is TCP-only stream-muxed through 512-byte cells; I2P uses garlic routing with its own transport protocols like NTCP2 and SSU2). Lokinet creates a genuine virtual network interface—lokiN or whatever you name it—and routes actual IP packets through onion-routed tunnels using Oxen Service Nodes.



What this means practically for C2: your implant, your beacon, your RAT—whatever you've deployed—doesn't know it's on an overlay. It sees a network interface. You can run UDP. You can run ICMP. You can run raw sockets if you want to be theatrical about it. Tor cannot do this. Tor will never do this. Tor is a SOCKS proxy that thinks TCP is the entire universe.



Session Stability Under Sustained Load



Here's where it gets ugly



Tor under bulk exfiltration:

Throughput typically floors around 200-500 KB/s on a good day with a clean circuit. The problem isn't just bandwidth—it's cell multiplexing overhead and congestion control. Tor's older window-based flow control meant a single congested relay in your three-hop circuit throttled everything. Newer Tor (with congestion control from thePROP-324 work, merged into recent tor releases) improved this significantly using a flow control algorithm that's more BBR-adjacent. But the fundamental issue remains: if your C2 channel and your exfil channel share a circuit, the interactive traffic (beaconing, command responses) gets absolutely starved. You'd need separate circuits with stream isolation, which means multiple SOCKS connections and circuit management logic in your implant. Doable. Annoying.



Circuit rotation is the silent killer. Tor rotates circuits every 10 minutes by default for new TLS connections. For a sustained RDP session or a large file transfer that takes 45 minutes, you're going to eat reconnection events. Your C2 framework either handles this transparently (reconnect logic, session resumption) or you lose the session. Most do not handle it gracefully.



I2P under bulk exfiltration:

I2P's garlic routing and packet-switched design should theoretically handle this better, and in some ways it does. The SSU2 transport (replacing the older SSU) uses UDP, which means you're not fighting TCP-over-TCP meltdown when your C2 traffic is itself TCP-based. That's a genuine advantage.



But I2P's tunnel rotation is aggressive—default tunnel lifetime is 10 minutes, and tunnels are rebuilt proactively, but the rebuild process can still cause momentary drops. For a file transfer, you need your C2 to handle tunnel rebinding. For RDP, you need session persistence across tunnel changes, which RDP can do with autoreconnect but the latency spike during rebinding is noticeable—2-5 seconds of frozen screen.



I2P's bigger problem is network size. Fewer routers means less available bandwidth and fewer path options. You're looking at maybe 100-200 KB/s realistic throughput on most I2P tunnels, sometimes worse. The internal I2P services (eepsites) are fast-ish because traffic stays within the network. Using an I2P outproxy (exit) is rare and usually bottlenecked.



Lokinet under bulk exfiltration:

This is the interesting one. Lokinet's L3 tunneling means you're pushing IP packets through a network of Oxen Service Nodes. The SNs are staked (currently 3750 OXEN per node, I think—don't quote me on current economics), which means they're typically running on dedicated hardware with real bandwidth. Not hobbyist Raspberry Pi relays like a chunk of Tor's network.



Throughput: I've seen reports and testing data suggesting 1-5 MB/s is achievable on good paths, which is substantially better than Tor or I2P. The lack of cell-multiplexing overhead is the primary reason—there's no 512-byte cell framing tax on every packet.



Session stability is where Lokinet's design shines in theory but struggles in practice. The Lokinet address is identity-based (derived from your Ed25519 keys), so in principle, path changes between SNs shouldn't kill your session the way Tor circuit rotation does. The addressing layer is decoupled from the routing layer. If a SN in your path goes down, Lokinet can re-route through different SNs while maintaining the same endpoint identity.



In practice, the Lokinet client has historically been... let's say developmentally energetic. Memory leaks on long-running sessions, occasional panics in the wireguard-style edge tunnel handling, and the Oxen blockchain dependency means that if chain consensus hiccups (forks, reorgs, SN deregistration events), routing can degrade. The SN set is also smaller than Tor's relay set—roughly 1000-1500 active SNs versus Tor's ~6000-7000 relays—so path diversity is lower.



For large-file exfiltration specifically, Lokinet's L3 interface means you can use standard tools without SOCKS wrapping. Rsync over Lokinet works. SCP works. You could even run a SMB share over it if you hate yourself. The throughput advantage means a 2GB exfil that would take 60-90 minutes over Tor might complete in 10-15 minutes over Lokinet.



Remote Desktop — The Decisive Factor



RDP/VNC over Tor is miserable. The latency floor is high (200-400ms minimum due to three-hop circuit), TCP-only means any packet loss compounds through TCP retransmits on top of the overlay's own reliability, and circuit rotation disconnects your session. I've seen operators use Tor for initial access beaconing and then pivot to a direct connection or alternative channel for any interactive work because Tor just can't sustain RDP.



I2P is slightly better because of UDP transport, but the small network and tunnel rotation still produce a jittery experience. Maybe 150-250ms latency with periodic 2-5 second freezes during tunnel rebuilds.



Lokinet should be the clear winner here. UDP works natively, latency is typically 80-150ms (two-hop through SNs, no exit needed if your C2 is hosted as a Lokinet SNApp), and the identity-based addressing means path rerouting doesn't necessarily kill the session. RDP over Lokinet, with a SNApp-hosted C2 endpoint, is the closest thing to a "normal" remote desktop experience you'll get on an overlay network. You'll still feel the latency—this isn't a direct connection—but it's usable for sustained interactive work in a way Tor simply is not.



The Honest Tradeoffs



Lokinet's weaknesses:



Maturity. Tor has 20+ years of hardening, academic scrutiny, and active adversarial testing. I2P has nearly as long. Lokinet is younger, fewer security audits, fewer people trying to break it (which means fewer people finding and fixing breaks). The codebase has improved significantly but it's not battle-tested the way Tor is.

OPSEC footprint. Running a Lokinet client on a target machine leaves a different signature than Tor. Tor is detected by everything—EDR, network monitoring, the janitor. Lokinet is less commonly flagged but its traffic patterns and the Oxen SN discovery protocol are fingerprintable if someone's looking. The SN polling traffic and Lokinet's handshake characteristics are distinctive.

Exit node exposure. If your C2 architecture requires exit traffic (connecting to a clearnet C2 server rather than a SNApp), Lokinet exits are staked and identifiable. An exit operator is a known entity in the Oxen network. Tor exit relays are also identifiable, but there are thousands of them and the operator base is diffuse. Lokinet has fewer exits and they're more tightly coupled to the Oxen staking economy.

Blockchain dependency. If Oxen chain has consensus issues, SN set changes, or economic attacks, routing stability is affected. Tor and I2P don't have this dependency—relay operators just run software.

                               ! recommendation !



If you're building C2 infrastructure for sustained interactive access with large-file exfil requirements, the layered approach is what actually works in practice:



Initial beaconing / fallback: Tor. It's noisy but it's reliable and has the largest pool of potential exits. Use it for low-bandwidth command channels and as a backup.

Interactive sessions (RDP, shell): Lokinet, hosting the C2 as a SNApp so you never need exit traffic. The latency and UDP support make it the only overlay where RDP is genuinely usable for prolonged sessions.

Bulk exfiltration: Dedicated circuit. Either Lokinet (if throughput is the priority) or a separate Tor circuit with stream isolation (if OPSEC redundancy is the priority). Don't mix exfil traffic with interactive traffic on any overlay—congestion will degrade your interactive session.