Delivery-Date: Sun, 12 Jun 2016 16:27:26 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [138.201.14.202])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id C25911E00E0;
	Sun, 12 Jun 2016 16:27:23 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id EA276E16CB;
	Sun, 12 Jun 2016 20:27:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3CEBDE166A
 for <tor-talk@lists.torproject.org>; Sun, 12 Jun 2016 20:27:09 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id W4FB6WQxK0wO for <tor-talk@lists.torproject.org>;
 Sun, 12 Jun 2016 20:27:09 +0000 (UTC)
X-Greylist: delayed 573 seconds by postgrey-1.35 at eugeni;
 Sun, 12 Jun 2016 20:27:08 UTC
Received: from len.romanrm.net (len.romanrm.net [IPv6:2001:bc8:3829:400::1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id EBC24E1627
 for <tor-talk@lists.torproject.org>; Sun, 12 Jun 2016 20:27:08 +0000 (UTC)
Received: from natsu (unknown [IPv6:fd39::e9:9eff:fe8f:1bcf])
 by len.romanrm.net (Postfix) with SMTP id 9F9F76BA2D;
 Sun, 12 Jun 2016 20:17:17 +0000 (UTC)
Date: Mon, 13 Jun 2016 01:17:08 +0500
From: Roman Mamedov <rm@romanrm.net>
To: gdfg dfgf <torrio888@net.hr>
Message-ID: <20160613011708.17b2f696@natsu>
In-Reply-To: <20160612215634.682F2381@net.hr>
References: <20160612215634.682F2381@net.hr>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] 2 hop mode for people that only want to use Tor for
 censorship circumvention to conserve bandwidth and decrease latency?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Reply-To: tor-talk@lists.torproject.org
Content-Type: multipart/mixed; boundary="===============8632040621935611805=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

--===============8632040621935611805==
Content-Type: multipart/signed; micalg=pgp-sha1;
 boundary="Sig_/ceva29eFM+_l/kBd5gPOlBq"; protocol="application/pgp-signature"

--Sig_/ceva29eFM+_l/kBd5gPOlBq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 12 Jun 2016 21:56:34 +0200
gdfg dfgf <torrio888@net.hr> wrote:

> I have read the proposal for non hidden .onion services for sites that do=
n't need anonymity but want to use Tor's end to end encryption and authenti=
cation, for=C2=A0 example Facebook.=20
>=20
> Could the same be done for people that are more interested in censorship =
circumvention then in anonymity to decrease latency and conserve bandwidth=
=C2=A0 so=C2=A0 instead of building 3 hop circuits they could build 2 hop c=
ircuits?=20
> =C2=A0
> entry node---> exit node ---> website

You don't even need 2 hops in this case. Why not propose 1-hop?
But I don't think any hop reduction like this has chances to be implemented,
due to such scenario not being within the scope of Tor, or something along
those lines.

> =C2=A0=C2=A0=C2=A0=C2=A0 bridge- --> exit node ---> website

(Here 2-hop makes sense, as exit node can't be also a bridge)

--=20
With respect,
Roman

--Sig_/ceva29eFM+_l/kBd5gPOlBq
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlddw0cACgkQTLKSvz+PZwh1FgCfZCyTF4WOv2rx7wWWfF8qCWuG
zDAAoI2x0+oY5WLSoNX4s8iYaAfDBKps
=bYh/
-----END PGP SIGNATURE-----

--Sig_/ceva29eFM+_l/kBd5gPOlBq--

--===============8632040621935611805==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCnRvci10YWxrIG1haWxpbmcgbGlzdCAtIHRvci10YWxrQGxpc3RzLnRvcnByb2plY3Qub3Jn
ClRvIHVuc3Vic2NyaWJlIG9yIGNoYW5nZSBvdGhlciBzZXR0aW5ncyBnbyB0bwpodHRwczovL2xp
c3RzLnRvcnByb2plY3Qub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby90b3ItdGFsawo=

--===============8632040621935611805==--

