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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Re: nym-0.2 released (fwd)]
Date: Mon, 3 Oct 2005 15:57:42 +0200
- Forwarded message from Jason Holt [EMAIL PROTECTED] -
From: Jason Holt [EMAIL PROTECTED]
Date: Sun, 2 Oct 2005 22:23:50 + (UTC)
To: cyphrpunk [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], cryptography@metzdowd.com
Subject: Re: nym-0.2 released (fwd)
Reply-To: [EMAIL PROTECTED]
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.36820http://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]
