Delivery-Date: Wed, 24 Feb 2016 19:35:13 -0500
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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 5D3BB1E04D7;
	Wed, 24 Feb 2016 19:35:11 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 8EA6939A42;
	Thu, 25 Feb 2016 00:35:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7467B39A2F
 for <tor-talk@lists.torproject.org>; Thu, 25 Feb 2016 00:35:00 +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 GFMR65Jr9MF4 for <tor-talk@lists.torproject.org>;
 Thu, 25 Feb 2016 00:35:00 +0000 (UTC)
Received: from outbound1a.ore.mailhop.org (outbound1a.ore.mailhop.org
 [54.213.22.21])
 (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 292E2399E2
 for <tor-talk@lists.torproject.org>; Thu, 25 Feb 2016 00:35:00 +0000 (UTC)
X-Greylist: delayed 966 seconds by postgrey-1.34 at eugeni;
 Thu, 25 Feb 2016 00:35:00 UTC
X-MHO-User: 6aef5313-db55-11e5-8dfb-c75234cc769e
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 74.98.178.100
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from io (unknown [74.98.178.100])
 by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA
 for <tor-talk@lists.torproject.org>; Thu, 25 Feb 2016 00:19:21 +0000 (UTC)
Received: from io.lakedaemon.net (localhost [127.0.0.1])
 by io (Postfix) with ESMTP id 8736E80105
 for <tor-talk@lists.torproject.org>; Thu, 25 Feb 2016 00:18:47 +0000 (UTC)
X-DKIM: OpenDKIM Filter v2.6.8 io 8736E80105
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lakedaemon.net;
 s=mail; t=1456359527;
 bh=ZwW8HMMD76BK7EbrJ1TQwPNlQSwCcBIuolfKjMhLIic=;
 h=Date:From:To:Subject:References:In-Reply-To;
 b=kLlin2qmJCAHMiu07nEHiDH99IkxcMwU0I/DrzMwP9RQWp5aATIn7vvKy6akP21iY
 LKMoQNZuz4IbEoPHkLNTYltXWLyRgeq0wcEKxny7vVX0LydrXm25qvCbEQDFNOLmO5
 NKK0mKDBm/aai08/6nFgtipti4+hmNgnp7ZE1/V7WIfYFfpYfZ8I7Tiv89lFBLpSw8
 kj9hh/g0HyWnE9PMa0PXe4EXPOH4tIZVA4Rp238X7J+t2J2gZJBykohw7qe0Wfqumx
 wO+eHXinUJvYR5JpkvJoQU0SV/Zv1GbZcQpLUhsfMMbANyhH4SwIUVxbiy1/3DmMD7
 GI6T5/pnaxTQw==
Date: Thu, 25 Feb 2016 00:18:47 +0000
From: Jason Cooper <tor@lakedaemon.net>
To: tor-talk@lists.torproject.org
Message-ID: <20160225001847.GA7219@io.lakedaemon.net>
References: <1456260413.11002.18.camel@pentium.freedom.box>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1456260413.11002.18.camel@pentium.freedom.box>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [tor-talk] Thoughts on Tor router hardware
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Hi Rob,

On Tue, Feb 23, 2016 at 09:46:53PM +0100, Rob van der Hoeven wrote:
> The last month I have been playing with cheap Tor router hardware. This
> turned out to be quite a nice experience and it got me thinking about
> the benefits of running Tor on the router. 

There are many benefits, but see below...

> My conclusions are that running Tor on the router can enhance both
> security and usability.

I agree, with caveats.  Usability, yes.  Security is a bit more
complicated.

While there are definite, obvious improvements in security posture, such
as ease of configuration, isolation, and leak prevention; there are a
few landmines about.

The first problem is a good source of random numbers.  See some
discussion on the cryptography mailinglist, here [1].  Embedded systems
don't have RDRAND or RDSEED like x86 does.  Additionally, most lack
high-resolution timers.  Which are essential for extracting entropy from
interrupt timings and such.

Newer hardware has hwrngs, but their robustness leaves something to be
desired.  Additionally, Tor users tend to be a paranoid lot, and are
prone to avoid hwrngs that are opaque and unverifiable.  :-)

While mixing seeds from multiple sources doesn't academically solve the
entropy starvation problem, it does make it orders of magnitude more
difficult for an attacker to guess the inputs in order to predict the
output of Linux's prng.  This is most likely where a practical solution
lies.

Any embedded Tor router is going to need to address the above problem in
order to avoid weak ephemeral keying.  Personally, I pre-load my
firmware images with /var/lib/misc/random-seed.  It's the result of
pulling seeds from multiple x86 boxes with long uptimes and then xor'd
together.  *Then*, I turn the box on for the first time.  But that
doesn't scale for a product.

The second concern is a lot less critical.  arch/arm/ doesn't support
KASLR yet, and even if it did, you have the above-mentioned entropy
problem.

Last is updates.  A critical piece of any successful security product is
a secure, and hopefully automated update process.  I've not checked the
current status of OpenWRT, if they don't offer it, it would need to be
added.  Users rarely, if ever, update systems.  It's even worse for
printers, routers and other embedded devices.

> It further opens new possibilities for expanding the Tor-network and
> can provide a stable source of income for the Tor-project.

I certainly agree, especially if the default configuration includes "Is
your bandwidth capped?"  If not, it's configured and a low-prio relay.

I definitely think the project is worth pursuing.  But the quality of
randomness, especially at first boot, needs to be addressed before
releasing the first version.  Auto-update, ideally should also be in the
first version, or shortly after.  Before reaching critical mass.

Just some thoughts.

thx,

Jason.

[1] http://article.gmane.org/gmane.comp.encryption.general/26020/match=trng+related+review+rngd+dev+random
     Top of thread:
    http://article.gmane.org/gmane.comp.encryption.general/26012/match=trng+related+review+rngd+dev+random

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

