Delivery-Date: Fri, 31 Oct 2014 08:55:02 -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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	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 ED82F1E0080;
	Fri, 31 Oct 2014 08:55:00 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 80B3931897;
	Fri, 31 Oct 2014 12:54:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 4ED9A234B9
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 12:54:31 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 rS-1gsyukCGI for <tor-talk@lists.torproject.org>;
 Fri, 31 Oct 2014 12:54:31 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 30C8F2268E
 for <tor-talk@lists.torproject.org>; Fri, 31 Oct 2014 12:54:31 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 766A41E0269; Fri, 31 Oct 2014 08:54:27 -0400 (EDT)
Date: Fri, 31 Oct 2014 08:54:27 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20141031125427.GQ35778@moria.seul.org>
References: <20141031122302.GA5554@glue.grepular.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20141031122302.GA5554@glue.grepular.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Facebook brute forcing hidden services
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>

On Fri, Oct 31, 2014 at 12:23:02PM +0000, Mike Cardwell wrote:
> https://www.facebook.com/notes/protect-the-graph/making-connections-to-facebook-more-secure/1526085754298237
> 
> So Facebook have managed to brute force a hidden service key for:
> 
> http://facebookcorewwwi.onion/ 
> 
> If they have the resources to do that, what's to stop them brute
> forcing a key for any other existing hidden service?

I talked to them about this. The short answer is that they did the vanity
name thing for the first half of it ("facebook"), which is only 40 bits
so it's possible to generate keys over and over until you get some keys
whose first 40 bits of the hash match the string you want.

Then they had some keys whose name started with "facebook", and they
looked at the second half of each of them to decide which one they thought
would be most memorable for the second half of the name as well. This
one looked best to them -- meaning they could come up with a story about
why that's a reasonable name for Facebook to use -- so they went with it.

So to be clear, they would not be able to produce exactly this name
again if they wanted to. They could produce other hashes that started
with "facebook", but that's not brute forcing all of the hidden
service name (all 80 bits).

For those who want to explore the math more, read about the "birthday
attack":
https://en.wikipedia.org/wiki/Birthday_attack

And for those who want to learn more (please help!) about the improvements
we'd like to make for hidden services, including stronger keys and
stronger names see,
https://blog.torproject.org/blog/hidden-services-need-some-love

--Roger

-- 
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

