[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: tracking SURBs (expiration date)

Peter Palfrader <mixminion-dev=seul.org@lists.palfrader.org> writes:
> The expiration date is not in the SURB itself.  It is a by-product of
> servers' key rotation.  If you ask mixminion to generate a SURB that
> is valid until at least <date>, then it will only pick servers which
> have keys that are valid in the selected timeframe.  Depending on which
> servers it chose it may very well be the case that the SURB is good for
> a few days more.

Ah, so the expired SURBs could still be used to mount a flood attack up to
the first server that has rotated a key. Looking at the current directory
info, it appears that the typical key rotation interval is between 1 and 3
weeks. So worst case you could have an extra two weeks of supposedly
"expired" SURBs gathered together and used to try to locate the exit node
with a flood attack.

Hm. I don't know whether to try and deal with this or not. There are two
points at which a SURB expires: the first is when it ceases to be capable of
getting a message to the desired recipient (which is equal to the use-by
date, because the recipient discards messages that arrived on stale SURBs).
The second is when it is no longer capable of contributing to a flood attack,
which occurs when the first hop of the recipient-chosen half-path rotates its
key. (actually it becomes gradually less useful over time as the various hops
key-rotate, but it doesn't become completely safe until that first hop

To give an accurate measure of the number of SURBs outstanding (alive in the
second sense), I'd have to extract the first hop and look up their key
expiration date.

or beg for mixminion to do this for me, something like:

 [MIXMINION:] SURB_HANDLE <surbid> 1076546948 1077546948

where the first number is the Use-By date (after which I know my
correspondent can no longer use it, so I need to consider sending them a
replacement), and the second is the Outstanding-Until or Safe-By date (after
which I know the flood-attacker cannot use it, so it is safe to generate

My instinct is to implement this kind of precise-checking, so I can put a
preferences item into Petmail that asks "What is the maximum number of SURBs
you're willing to let be outstanding at any one time?" and have it actually
mean something. However, I could probably be convinced that it isn't worth
the effort.