[tor-talk] Massive Bandwidth Onion Services

[Alec Muffett]

On 19 December 2016 at 15:42, David Goulet <dgoulet at ev0ke.net> wrote:

> Second, same occurs with modifying that RendPostPeriod from the default
> value
> of an hour to a custom time time. It makes you a bit more noticeable
> because
> you have a different behavior then anyone else.
>
> (And possibly some effect of disabling LearnCircuitBuildTimeout).
>
> Those do not lead to an "automatic deanonymization" but lets say they won't
> help. However, in the case of a single onion service (just release stable
> few
> minutes ago :D), this is really great!
>


Hi David!

You've hit basically upon an area of experimentation - with an OnionBalance
setup there are essentially 2x RendPostPeriods - one for the "parent" (or
"service") onion, and one for the "children" (or "ephemeral") onions.

As you already know, the parent "scrapes" the childrens' descriptors, and
"re-bundles" some of the childrens' introduction points as its own.

Anyone who's an astronomer will know about sampling issues in variable star
measurements, and the same applies here: if both the parents AND children
are on a "1 hour" RPP cycle, then a kind of oscillation could be set up
where the parent refreshes its descriptor, then most-or-all of the children
simultaneously (5 minutes later) change their introduction points, thereby
invalidating most-or-all the parent/service descriptor, and be permanently
stuck on this situation.

This is probably a bit of an edge case, and I suspect Tor already contains
some workarounds for it, but until then it seems wise to take a lesson from
cicadas and run the parent and childrens' RPPs on two different cycles,
using prime numbers as multipliers.  Hence 31-and-37 minutes, or something
like that.

Ignoring all "ZOMG THIS WILL MAKE IT OBVIOUS" - assume Single Onion - what
do you reckon?

    -a

-- 
http://dropsafe.crypticide.com/aboutalecm