Surreptitious Tor Messages?

[Tyler Durden]

Can anyone suggest a tool for checking to see if my Tor client is performing 
any surreptitious signaling?

Seems to me there's a couple of possibilities for a TLA or someone else to 
monitor Tor users. Tor clients purchased online or whatever could possibly 
signal a monitoring agency for when and possibly where the user is online. 
This would mean that at bootup, some surreptitious packets could be fired 
off.

The problem here is that a clever TLA might be able to hide its POP behind 
the Tor network, so merely checking on IP addresses on outgoing packets 
wouldn't work.

Can anyone recommend a nice little package that can be used to check for 
unusual packets leaving my machine through the tor client?

-TD



>From: Eugen Leitl <eugen at leitl.org>
>To: cypherpunks at jfet.org
>Subject: [jason at lunkwill.org: Re: nym-0.2 released (fwd)]
>Date: Mon, 3 Oct 2005 15:57:42 +0200
>
>----- Forwarded message from Jason Holt <jason at lunkwill.org> -----
>
>From: Jason Holt <jason at lunkwill.org>
>Date: Sun, 2 Oct 2005 22:23:50 +0000 (UTC)
>To: cyphrpunk <cyphrpunk at gmail.com>
>Cc: or-talk at freehaven.net, cryptography at metzdowd.com
>Subject: Re: nym-0.2 released (fwd)
>Reply-To: or-talk at freehaven.net
>
>
>On Sun, 2 Oct 2005, cyphrpunk wrote:
> >1. Limting token requests by IP doesn't work in today's internet. Most
>
>Hopeless negativism.  I limit by IP because that's what Wikipedia is 
>already
>doing.  Sure, hashcash would be easy to add, and I looked into it just last
>night.  Of course, as several have observed, hashcash also leads to
>whack-a-mole problems, and the abuser doesn't even have to be savvy enough
>to change IPs.
>
>Why aren't digital credential systems more widespread? As has been 
>suggested
>here and elsewhere at great length, it takes too much infrastructure. It's
>too easy when writing a security paper to call swaths of CAs into existance
>with the stroke of the pen.  To assume that any moment now, people will
>start carrying around digital driver's licenses and social security cards
>(issued in the researcher's pet format), which they'll be happy to show the
>local library in exchange for a digital library card.
>
>That's why I'm so optimistic about nym. A reasonable number of Tor users, a
>technically inclined group of people on average, want to access a single
>major site. That site isn't selling ICBMs; they mostly want people to have
>access anyway. They have an imperfect rationing system based on IPs. The
>resource is cheap, the policy is simple, and the user needs to conceal a
>single attribute about herself. There's a simple mathematical solution that
>yields certificates which are already supported by existing software. That,
>my friend, is a problem we can solve.
>
>
> >I suggest a proof of work system a la hashcash. You don't have to use
> >that directly, just require the token request to be accompanied by a
> >value whose sha1 hash starts with say 32 bits of zeros (and record
> >those to avoid reuse).
>
>I like the idea of requiring combinations of scarce resources. It's
>definitely on the wishlist for future releases.  Captchas could be
>integrated as well.
>
>
> >2. The token reuse detection in signcert.cgi is flawed. Leading zeros
> >can be added to r which will cause it to miss the saved value in the
> >database, while still producing the same rbinary value and so allowing
> >a token to be reused arbitrarily many times.
>
>Thanks for pointing that out! Shouldn't be hard to fix.
>
>
> >3. signer.cgi attempts to test that the value being signed is > 2^512.
> >This test is ineffective because the client is blinding his values. He
> >can get a signature on, say, the value 2, and you can't stop him.
> >
> >4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only
> >160 bits which could allow a smooth-value attack. This involves
> >getting signatures on all the small primes up to some limit k, then
> >looking for an r such that sha1(r) factors over those small primes
> >(i.e. is k-smooth). For k = 2^14 this requires getting less than 2000
> >signatures on small primes, and then approximately one in 2^40 160-bit
> >values will be smooth. With a few thousand more signatures the work
> >value drops even lower.
>
>Oh, I think I see. The k-smooth sha1(r) values then become "bonus" tokens,
>so we use a large enough h() that the result is too hard to factor (or, I
>suppose we could make the client present properly PKCS padded preimages).
>I'll do some more reading, but I think that makes sense.  Thanks!
>
>						-J
>
>----- End forwarded message -----
>--
>Eugen* Leitl <a href="http://leitl.org">leitl</a>
>______________________________________________________________
>ICBM: 48.07100, 11.36820            http://www.leitl.org
>8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
>
>[demime 1.01d removed an attachment of type application/pgp-signature which 
>had a name of signature.asc]