From Newsgroup: sci.crypt

There have been a lot of discussion and flames lately about extending Tor circuit lengths
beyond the standard 3 hops.
While the theoretical anonymity benefits are
appealing, I think we need a reality check on the serious risks that most people are glossing over.

## Performance Degradation (The Obvious One)

Every additional hop roughly doubles your latency. 3 hops raA 4 hops isn't just 33% slower, it's often 80-100% slower in practice due to:

- Circuit establishment overhead multiplying
- More points where packet loss can occur
- Increased jitter and timing variance
- Buffer bloat accumulation across nodes

For browsing, this makes Tor nearly unusable.

## The Failure Cascade Problem

Standard Tor has ~99.2% circuit success rate. Each additional hop roughly
adds another 0.5-1% failure chance. Sounds small until you realize:

- 3 hops: ~1% circuit failure
- 5 hops: ~3-4% circuit failure
- 7 hops: ~6-8% circuit failure

Your connection becomes unreliable fast. Nothing worse than a circuit
dying mid-session when you're trying to access something important.

## Fingerprinting Risk (The Big One)

This is where extended hops can actually REDUCE your anonymity. If only
0.1% of Tor users are running modified clients with variable hop counts,
you become part of a tiny, easily identifiable subset.

Research showed that behavioral anomalies can be
fingerprinted even through Tor.
Using non-standard circuit lengths is
a massive red flag that screams "this user is running modified software."

Unless EVERYONE adopts this (spoiler: they won't), you're making yourself
more traceable, not less.

## Resource Exhaustion Attack Vector

Extended circuits consume disproportionately more network resources:

- Each relay has to maintain more state
- Memory usage increases linearly per extra hop
- Processing overhead for crypto operations multiplies
- Bandwidth allocation becomes inefficient

A small number of users running 7+ hop circuits could severely degrade
network performance for everyone.
*This is basically a DoS attack* on the
Tor network, even if unintentional.

## The "More Hops = More Compromised Nodes" Paradox

Standard Tor assumes some percentage of nodes are compromised/monitored.
Let's say 10% of exit nodes and 5% of middle nodes are hostile.

3-hop circuit compromise probability: ~10.5%
5-hop circuit compromise probability: ~19.8%
7-hop circuit compromise probability: ~28.7%

You're not just adding hops, you're exponentially increasing your chances
of hitting a compromised node somewhere in the path.

## Implementation Complexity = Security Bugs

Modifying core Tor routing logic introduces new attack surfaces:

- Path selection bugs could leak information
- Memory management errors with dynamic lengths
- Race conditions in circuit building
- Potential for traffic confirmation via timing

The Tor codebase is already complex enough. Adding variable-length routing means more code paths, more edge cases, more opportunities for critical security bugs.

## Timing Analysis Becomes EASIER

Counter-intuitively, variable hop lengths can make certain timing attacks
more effective, not less. Attackers can:

- Measure circuit build times to estimate path length
- Use latency variations to fingerprint your routing patterns
- Correlate path lengths with user behavior patterns
- Exploit timing side-channels in the modified client

Academic research showed that some anonymity systems
actually become LESS secure when you add complexity trying to improve them.

## The Sybil Attack Amplification

With longer circuits, a Sybil attacker running multiple malicious nodes
has better odds of controlling multiple points in your path:

- 3 hops: Low chance of controlling 2+ positions
- 7 hops: Significantly higher chance of controlling 3+ positions

Once an attacker controls multiple hops in your circuit, game over.

## Real-World Testing Reality

I've been running modified Tor clients with extended circuits for research. Reality check:

- 90% of websites timeout on 6+ hop circuits
- Video streaming is completely broken
- Even email becomes frustratingly slow
- Circuit build failures every 10-15 attempts
- Memory usage 3x higher than standard Tor

## The Academic vs. Practical Gap

Most papers discussing extended Tor circuits are purely theoretical or
tested on tiny laboratory networks. Real-world deployment faces:

- Heterogeneous relay performance
- Variable network conditions
- Diverse client hardware capabilities
- ISP-level traffic shaping
- Geographic routing suboptimalities

What works in simulation fails in practice.

## The Non-Real-Time Exception (Sort Of)

Now, to be fair, extended circuits DO become somewhat more tolerable for non-real-time protocols like:

- Email (SMTP/IMAP sessions)
- Usenet posting/reading (NNTP)
- File transfers (when you can wait)
- Async messaging protocols

The performance hit is still there, but users can tolerate 30-second delays for sending an email vs. 30-second delays loading every webpage.

**HOWEVER** - and this is crucial - improved performance tolerance doesn't magically fix any of the other serious security issues:

- You're still fingerprinting yourself as using modified Tor
- Circuit failure rates are still 3-8x higher
- You're still hitting more potentially compromised nodes
- Resource exhaustion on the network still happens
- Implementation bugs still exist
- Timing attacks are still viable
- Sybil attackers still get more opportunities

Don't let "it's usable for email" fool you into thinking extended circuits
are suddenly safe.
The performance problem is just ONE of many serious
issues.

--- Digital Signature --- oF0MnTP+pwPNMAsZSV8EIP352iq5MiNYsRAareEPl5ZSzTjjJsc3IVPd0Ja5njzp1yWpO33/e+41KbObew6VBg==


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.crypt

Gabx <virebent@tcpreset.invalid> wrote:

[ A lot of nonsense snipped ]

Now, to be fair, extended circuits DO become somewhat more tolerable for >non-real-time protocols like:

- Email (SMTP/IMAP sessions)
- Usenet posting/reading (NNTP)
- File transfers (when you can wait)
- Async messaging protocols

The performance hit is still there, but users can tolerate 30-second delays >for sending an email vs. 30-second delays loading every webpage.

**HOWEVER** - and this is crucial - improved performance tolerance doesn't >magically fix any of the other serious security issues:

- You're still fingerprinting yourself as using modified Tor

No, it can't be detected, as you yourself had to admit in <20250603.1748968648.950047.3845@m2usenet.local>.

- Circuit failure rates are still 3-8x higher

Doesn't matter when responsiveness isn't an issue.

- You're still hitting more potentially compromised nodes

Desn't matter as an adversary has to own all relays of a circuit to
compromize the user, which becomes harder with every additional hop.

- Resource exhaustion on the network still happens

Doesn't matter as we transfer only a small amount of remailer data
compared with those who for example stream sensitive video contents.

- Implementation bugs still exist

Only a problem when amateurs like you get active.

- Timing attacks are still viable

For timing attacks you have to correlate traffic at a potential target
with that at the server he uses. More latency with more variation as
provided by longer circuits makes that task much more difficult. And in
case an attacker nevertheless succeeds the then obvious knowledge of a
latency longer than usual as an indicator of an exceptionally long chain implies no additional value.

- Sybil attackers still get more opportunities

That's exactly the Tor problem which can be addressed by using LONGER
circuits, which is why we refuse the standard 3-hop routing.

Don't let "it's usable for email" fool you into thinking extended circuits >are suddenly safe.
The performance problem is just ONE of many serious
issues.

So take advantage of anonymous remailing and use Tor only for less
decisive tasks like the hidden delivery of remailer packets to entry
remailers, which reflects the concept of OmniMix.

Thanks for your attention.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.crypt

Nomen Nescio wrote:

Gabx<virebent@tcpreset.invalid> wrote:

[ A lot of nonsense snipped ]

Ah, I see, you trimmed the nonsense just to make room for your own.

**Generous**!!!

Multiple academic papers demonstrate circuit length fingerprinting through timing analysis:

- https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-kwon.pdf
- https://people.csail.mit.edu/devadas/pubs/circuit_finger.pdf

You CANNOT directly extract hop counts from encrypted packets, but
behavioral fingerprinting during construction is well-documented and
highly effective.

- You're still hitting more potentially compromised nodes

Desn't matter as an adversary has to own all relays of a circuit to compromize the user, which becomes harder with every additional hop.

An adversary controlling just the entry and exit (or even entry and one middle) can perform correlation attacks:

- https://blog.torproject.org/one-cell-enough-break-tors-anonymity/
- https://www-users.cse.umn.edu/~hoppernj/deepcoffea.pdf

The "need all relays" assumption hasn't been valid since ~2004.
Modern attacks work with partial path knowledge.

- Resource exhaustion on the network still happens

Doesn't matter as we transfer only a small amount of remailer data
compared with those who for example stream sensitive video contents.

It's not about total bandwidth, it's about computational overhead per hop.

Each additional hop multiplies,encrypt/decrypt at every relay,memory usage, circuit construction overhead.

A 7-hop remailer message uses ~3x more relay CPU cycles and memory than
a 3-hop video stream, despite transferring less data.
The crypto overhead scales with path length, not payload size.

I don't know with pornohub lol

The "small data volume" argument ignores that Tor's bottleneck is relay processing capacity, not raw bandwidth.
Even 1% of users adopting 7+ hop circuits would significantly impact network performance.

- https://www.researchgate.net/publication/285449449_The_Path_Less_Travelled_Overcoming_Tor's_Bottlenecks_with_Traffic_Splitting

- https://forum.torproject.org/t/when-will-tor-fully-exploit-all-cpu-threads/2198

- Implementation bugs still exist

Only a problem when amateurs like you get active.

I'm never been passive mon cher !!! <3

- Timing attacks are still viable

For timing attacks you have to correlate traffic at a potential target
with that at the server he uses. More latency with more variation as provided by longer circuits makes that task much more difficult. And in
case an attacker nevertheless succeeds the then obvious knowledge of a latency longer than usual as an indicator of an exceptionally long chain implies no additional value.

This demonstrates a fundamental misunderstanding of modern timing attacks. Again, read this i said:

- https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-kwon.pdf

- Sybil attackers still get more opportunities

That's exactly the Tor problem which can be addressed by using LONGER circuits, which is why we refuse the standard 3-hop routing.

This completely inverts the mathematical reality of Sybil attacks. Longer circuits make Sybil attacks MORE effective, not less

- https://www.researchgate.net/publication/229003986_On_the_Optimal_Path_Length_for_Tor

Thanks for your attention.

You should thank me.
For writing this answer it took me two days as if I already had nothing to do. It's free of charge !!!

Gabx

--- Digital Signature --- /dZkdkFUmBijUqxh3q0rHesqp5+QjKGQqI7C0Cmrsy8NDZGsix2PRIjDuN6ZNLeY0IsJ/sq6vfPLLLlj/UZhAg==


--- Synchronet 3.21a-Linux NewsLink 1.2