tracking SURBs

[Brian Warner <warner@lothar.com>]

Howdy all. I've been working on Petmail (http://petmail.lothar.com), which is
a new mail system primarily intended to deal with the spam problem, but which
I also intend to be usable as a mixminion frontend. Petmail uses an agent
that can respond to inter-agent messages on behalf of its user; this makes it
convenient to add certain anonymity features like communicating with a
nymserver.

Petmail decouples the description, addressing, and routing aspects of an
email identity. I added the independent transport (routing) record to make it
easier for users to switch email providers, but it also turns out to make it
simpler to send messages through SURBs. I'm working on defining a server that
feeds SURBs out to interested parties, kind of like a nymserver but without
the actual email traffic: it only deals in SURBs.

To do this correctly, as well as to implement the code to keep an established
correspondent stocked with a reasonable number of SURBs, it would be useful
if I could track individual SURBs. What I need is a programmatic way to do
the following:

 'mixminion generate-surb' should give me a unique ID for each SURB it
 creates. This could simply be the TAG value used to create the SURB (the
 "decoding handle" if I understand the terminology correctly)

 'mixminion decode' should give me the same ID value when used to decrypt a
 message sent through a SURB.

Something like gnupg's --status-fd would be great: lines of machine
parseable status output. Something like

 [MIXMINION:] SURB_HANDLE AB03A40A4..

emitted on both ends would be perfect. It might also be nice to have a
SURB_EXPIRES emitted upon generation: at the moment I just use the same
algorithm as mixminion does (N days after the previous UTC midnight), but it
would be preferable to get the correct value from mixminion itself.


In my application, the agent will generate SURBs for various purposes
(stocking an established correspondent, stocking the pseudonym-SURB-server,
and using as reply blocks in anonymous query messages to other servers). It
needs to track the life-cycle of each SURB to insure the following things:

 Make sure the SURB is used for the right purpose. If I send a SURB to Alice
 and it shows up on a message coming from Bob, then I know they have been
 talking about me. This may be ok or not, depending upon user preferences. If
 I give a SURB to a server for use as a reply, and it shows up on a message
 from Bob, then I know Bob has been snooping my traffic to the server.
 (this is related to the shared-identity-guessing attack)

 Limit the number of outstanding SURBs. I want to keep Alice stocked with a
 reasonable number of SURBs (say 10) so she can talk to me. When I think her
 supply is running low, I'll send her some more. I know when each SURB
 expires, and I know when I receive a message on one of those SURBs, which
 gives me an upper bound on the number of outstanding ones. I want to keep
 that number below some limit to avoid enabling a flood attack. I also want
 to keep track of the number of outstanding SURBs for all purposes, to limit
 the flood attack that could be mounted if all my correspondents collude and
 pool their SURBs.


The current version of mixminion provides the "identity" string (both setting
and retrieving from 'mixminion decode'), but I need something unique to each
SURB. As a hack I could use a random identity for each SURB, but I'm under
the impression a new secret is generated for each distinct identity, which
makes this impractical.

One other question: am I correct in believing that the expiration time on
SURBs is enforced by (at least) the first hop in the recipient-chosen
half-path? It seems that this is required to prevent a flood attack. I
skimmed through the specs but couldn't see anywhere the Use-by-Date was
checked other than the exit node.

thanks,
 -Brian

PS: I'll be presenting Petmail at CodeCon next week, and I look forward to
talking to everyone here about nymservers and frontends and stuff.