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

Re: chaining JAP and Tor

Dear Paul,

Thanks ever so much for spending so much time on your post. I am very new to all this and won't pretend that I understood all of it. But can I just ask you to perhaps put it like this to me:

You see no advantage (increased level of anonymity) in chaining JAP and Tor. Is chaining them neutral (ie. no increased or decreased anonymity) or detrimental (with chaining them there is less anonymity conferred than if using just one or the other)?

Of course anonymity is just one factor - maybe speed would come into it as well. But just focusing on anonymity for now.

Thanks ever so much.
Ben

From: Paul Syverson <syverson@xxxxxxxxxxxxxxxx>
Reply-To: or-talk@xxxxxxxxxxxxx
To: or-talk@xxxxxxxxxxxxx
CC: Paul Syverson <syverson@xxxxxxxxxxxxxxxx>
Subject: Re: chaining JAP and Tor
Date: Thu, 21 Jul 2005 12:57:35 -0400
MIME-Version: 1.0
Received: from belegost.seul.org ([18.244.0.114]) by mc11-f29.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 09:58:50 -0700
Received: by moria.seul.org (Postfix)id DD6A81408209; Thu, 21 Jul 2005 12:58:18 -0400 (EDT)
Received: by moria.seul.org (Postfix, from userid 65534)id DB0A9140820B; Thu, 21 Jul 2005 12:58:18 -0400 (EDT)
Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])by moria.seul.org (Postfix) with ESMTP id A569E1408209for <or-talk@xxxxxxxxxxxxx>; Thu, 21 Jul 2005 12:58:18 -0400 (EDT)
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3])by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id j6LGwEbv020326for <or-talk@xxxxxxxxxxxxx>; Thu, 21 Jul 2005 12:58:18 -0400 (EDT)
Received: from itd.nrl.navy.mil ([132.250.196.100]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.7.33) with SMTP id M2005072112581716503 for <or-talk@xxxxxxxxxxxxx>; Thu, 21 Jul 2005 12:58:17 -0400
Received: from itd.nrl.navy.mil (carnap [10.0.3.30])by itd.nrl.navy.mil (8.9.3p2/8.9.0) with ESMTP id MAA11480;Thu, 21 Jul 2005 12:57:35 -0400 (EDT)
Received: (from syverson@localhost)by itd.nrl.navy.mil (8.12.9/8.12.8/Submit) id j6LGvZnj009816;Thu, 21 Jul 2005 12:57:35 -0400 (EDT)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
Delivered-To: or-talk-outgoing@xxxxxxxx
X-Original-To: or-talk@xxxxxxxxxxxxx
Delivered-To: or-talk@xxxxxxxx
References: <BAY101-F16B20D5C07E57A71E6BE64B5D60@xxxxxxx>
User-Agent: Mutt/1.4.1i
Precedence: list
X-To-Get-Off-This-List: mail majordomo@xxxxxxxx, body unsubscribe or-talk
Return-Path: owner-or-talk-outgoing@xxxxxxxx
X-OriginalArrivalTime: 21 Jul 2005 16:58:50.0670 (UTC) FILETIME=[77E23CE0:01C58E15]

On Thu, Jul 21, 2005 at 03:25:13PM +0000, Ben Clifford wrote:
> Chaining JAP and Tor
>
> Here I outline a methodology for doing this and I would be very interested
> to hear back as to what people think of its validity. It requires you to
> have both JAP and Tor installed on your system. The JAP client is set up as
> to use the mix cascade system (ie. it is set as an HTTP proxy in your
> browser and NOT a Socks proxy).
>

I don't intend to comment about the architecture (other than to say
that it seems probably OK at the level you described it) but rather
to ask what the larger goal is here.

First an aside: I want to respond to a JAP FUD comment that has
already been posted. I do not think that JAP is backdoored right
now. If it were backdoored though (as in the past) I doubt they could
tell us legally. Same is true of Tor by the way, which is why
independent inspection of the source and alertness to sudden
disappearance of the source is recommended. But, even with source code
signed and in hand, you have no direct evidence that the Tor server or
JAP server through which you route is running it; although you can
compile the client yourself. And the source code for JAP is
available. You just have to go to the JAP site to see. It beats idle
speculation.

Back to the main question: what's the point?

We don't have to argue about who has the better/more-realistic/...
system or threat model. You can just take the two threat models
as givens.

Tor's security derives from the adversary not knowing the endpoints of
communication. But if you feed a Tor circuit into a JAP cascade,
anyone can know where it's coming out. Thus, someone who wants to see
where you are connecting can just watch the end of the JAP cascade and
confirm the responder to which you are connecting.

JAP's security derives from persistent clients with similar traffic
profiles (e.g., via padding, although I don't know if that is deployed
currently). Having a bunch of Tor circuits that open and close at
varying times for relatively short intervals with varied
traffic profiles will not satisfy these assumptions and, it should
be relatively easy to bridge the cascade for exiting traffic based
on Tor circuits. So you derive no benefit from sticking a JAP cascade
at the end of your Tor circuit, or put the other way round: you would
ruin the protection of using JAP.

Now, you suggested putting the JAP client before the Tor circuit which
then leads into the cascade. This could govern the sorts of things I
raised in the last paragraph. The problem is that Tor is not designed
to work with this level of traffic padding and regularization. Whether
or not it is practically feasible (of which I am dubious), it seems
likely that it would chase away many of the volunteers that run our
servers.

Also, I don't think it would have reasonable payoff even if feasible.
That's partly because of my views in an ongoing debate between the
free-route and cascade advocates. Fortunately, we can note the
incompatibility of the current systems with their current threat
models without getting into who is right in that debate.

aloha,
Paul